PetriP-TNT
Member
The "isArray" module is another funny example: most people would just do "return arr instanceof Array" which is inadequate. Not to mention it's a polyfill for very old browsers to boot.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
Programming |OT| C is better than C++! No, C++ is better than C
- Thread starter Kikarian
- Start date
The "isArray" module is another funny example: most people would just do "return arr instanceof Array" which is inadequate. Not to mention it's a polyfill for very old browsers to boot.
cpp_is_king
Member
I think that advice transcends language boundaries. Unless you know of other languages where it is common to have packages that consist of 1 line of code.
I've always used strong/statically typed languages so I can't even imagine. I would make so many bugs. I would use these one-liner packages to be safe.
I'm not that familiar with Javascript but such functions are common in Smalltalk, which is one of the most elegant and beautiful languages you'll have the pleasure of working with.
Also, one thing that's usually true is that if hackernews is against something then it must be good.
cpp_is_king
Member
I'm not saying there's something wrong with 1 line functions, just 1 line packages. isArray? Seriously? That's worth taking a dependency on? 1 line of code?
Elegance of syntax is nothing if the right semantics aren't in place. Not to mention elegance changes with complexity. If it stops elegantly allowing you to reason about your state then you have a problem. OO has a lot of issues with coupling, encapsulation of state. I find the apparently elegance of OO deceiving.
Shadowlink
Member
.
Don't reinvent the wheel. Or the type check.
cpp_is_king
Member
Also don't take an unnecessary dependency. I'm not saying "reinvent the wheel", I'm saying "don't take a dependency unless it's really important".
Would you take a dependency for a package that incremented a number? It just doesn't make sense.
This is not entirely the fault of the programmers, but the blame lies on the package creators too. You should be making a package that has LOTS of related useful functions, not 1 function that does 1 thing. It's stupid. Do you need separate packages for sine, cosine, tangent, arctan, square, exponent, logarithm, and square root now? Put it in one package and call it math. That's why it's called a "package", literally "collection of things", plural.
Incrementing is supported by the language directly. Apparently, a safe type check isn't, so you want to use a package.
cpp_is_king
Member
Yes, a package that contained lots of functions about type checking for a variety of situations. Not 1 specialized function. If that's the only option, you should be copying the code out of the package, and putting it in a file you own. I mean the proof is in the pudding, we can see the cost of taking unnecessary dependencies jsut by looking at what happened today. Is it worth it when millions of dollars are on the line?
Edit: Look at this shit from the comments on hackernews.
Code:
// is-positive-integer/index.js
var passAll = require('101/pass-all')
var isPositive = require('is-positive')
var isInteger = require('is-integer')
module.exports = passAll(isPositive, isInteger)Anyone who thinks this is good idea should not be working on anything mission critical, or even remotely important for that matter. A minimum of 4 dependencies just to check if something is a positive integer. That's 4 more pieces of code that you have to trust. 4 more points of failure. 4 more things that may or may not have unit tests.
PetriP-TNT
Member
pack·age
ˈpakij/Submit
noun
1. an object or group of objects wrapped in paper or plastic, or packed in a box.
synonyms: parcel, packet, container, box
verb
2. present (someone or something) in a particular way, especially to make them more attractive.
By the pure definition, a "package" can contain one or multitudes of things.
is-positive-integer has been downloaded 150 times, with vast majority due to the Hacker News post. (Further more it now doesn't contain external deps, yay open source!)
When you guys and gals finished your education what was the most complex project that you had done? I'm about to write my thesis now and I feel like none of my side-projects are that impressive. The most complex thing that I've written is arguably a ray tracer in c++. I haven't had a lot of time to do the stuff that I've wanted to, for the past two years I've been working on the side (not in the industry) and I'm starting to worry that I don't really have a lot to show besides the education.
It doesn't matter how strictly you want to hold the idea of code-reuse the core problem is that of trust. Code might not work as expected, packages might change in unexpected ways, worst of all a nefarious hacker could steal credentials and inject code into the package and you're pulling it in willy nilly. The reason you use a package is because of the difficulty of re-implementing it for you use-case. You ideally would like to own all of your code but when that's not feasible or you want to save time getting it right you go to a package. If the savings is low, like it is for some of these, then that is outweighed by needing to trust someone else with your code.
So yeah a one liner package is fine so long as it's one really dense line that's not trivially reimplemented. But also at that granularity it's usually easier to just deal with a text snippet.
Also FWIW Array.isArray is a thing, all projects using that do so because of technical debt (they were made before it was and never updated).
So yeah a one liner package is fine so long as it's one really dense line that's not trivially reimplemented. But also at that granularity it's usually easier to just deal with a text snippet.
Also FWIW Array.isArray is a thing, all projects using that do so because of technical debt (they were made before it was and never updated).
PetriP-TNT
Member
Any code might not work as expected; left-pad for example had 4 tests for 13 LoC to make sure it does. Packages might change in unexpected ways between major versions: that's the whole points of semantic versioning and that's what NPM is based on. Obviously this can put you into a bad place if you expect "npm install foo" to be the same "npm install foo" always. However, "npm install foo@x.y.z will always be what you expected.
And Array.isArray has nothing to do with technical dept: it's a polyfill for very old browsers (as in IE8 (!!) and down), the first commit of the code looks like this as a whole:
And currently it looks like this:
cpp_is_king
Member
It really doesn't matter, because there is a cost associated with committing to using package, as we just saw today. And the cost of writing one trivial line of code, which we can probably measure at somewhere between $20-$50 given an average engineer's salary, is less than the cost of having your software break once every 5 years costing you potentially millions of dollars.
Imagine if Google had gone down today even for 1 minute because of this nonsense. Or even just took some engineer half a day to figure out. Or broke some internal build where now 10,000 engineers lose 2 hours of work. There is money on the line, and you don't use third party code without carefully weighing the cost/benefit ratio. In the case of a 1 line package consisting of a trivial line of code (or even a 10 line package consisting of a trivial function), the benefits simply do not outweigh the costs.
Imagine if Google had gone down today even for 1 minute because of this nonsense. Or even just took some engineer half a day to figure out. Or broke some internal build where now 10,000 engineers lose 2 hours of work. There is money on the line, and you don't use third party code without carefully weighing the cost/benefit ratio. In the case of a 1 line package consisting of a trivial line of code (or even a 10 line package consisting of a trivial function), the benefits simply do not outweigh the costs.
Only true in the expected NPM flow. Packages can also be delisted and I'm not sure NPM enforces devs have unique version numbers either.
Array.isArray is the native ECMAScript method for checking if an object is an array.
http://www.ecma-international.org/ecma-262/5.1/#sec-15.4.3.2 Nobody should be using a package for that.
PetriP-TNT
Member
Once you publish a version you cannot republish it with the same version number ever again*. If you take over a once published version package you must publish with a semver major number (like it would happened with Kik) and you cannot use semver to allow updates between major versions.
*with left-pad they had to resort to a backup. Whether or not this was a right call I don't know.
Array.isArray came to browsers quite recently and everybody who uses it should polyfill it if you plan to cater folks with old browsers (that is mainly IE8):
If your browser supports Array.isArray, then the package is-array will use it like I posted above.
Also like I mentioned above, isArray is something that most likely everyone would write wrong first unless they knew better.
I don't know what you think NPM does, but it doesn't provide packages at random at runtime. 10000 engineers didn't lose 2 hours of work.
Screw IE8, Microsoft isn't supporting it, why should I? I wish I could get away with not supporting IE9 either, but for now I'll keep on "supporting" it
Once you publish a version you cannot republish it with the same version number ever again*. If you take over a once published version package you must publish with a semver major number (like it would happened with Kik) and you cannot use semver to allow updates between major versions.
*with left-pad they had to resort to a backup. Whether or not this was a right call I don't know.
Array.isArray came to browsers quite recently and everybody who uses it should polyfill it if you plan to cater folks with old browsers (that is mainly IE8):
If your browser supports Array.isArray, then the package is-array will use it like I posted above.
Also like I mentioned above, isArray is something that most likely everyone would write wrong first unless they knew better.
Assuming they didn't know better and didn't test their own code, they could get it wrong but those people at least are not writing code for public consumption or at least you'd surely hope not. Also it doesn't look like that package is a polyfill as it has node style exports on it, it looks like it was meant for Node consumption (and of course other node packages were using it like that).
NPM doesn't, build servers probably do. Always fun when NPM goes down.
cpp_is_king
Member
I did say build servers. Anyway, I can't even believe I'm arguing this. This is basic software engineering 101. I think I'm out.
I had the exact same argument earlier today, and arrived at the same solution. Bailing.
In a way it's a shame NPM didn't leave it deleted. It might have actually taught a lesson about the cost of deps. Or why you should have a cached version of your deps on a build server.
It depends on what you mean by "people". And what build tool. Most will cache the dependencies locally.
But what if you're working at a company, and your codebase has a dependency that is now gone? Well, the devs that have it downloaded will be fine, but what about if they need a new machine, or someone new gets hired? You can't reproduce the build on the systems that don't have the dep.
This is why a sensible solution is to host an internal repository that will host your deps. Even if the origin goes away, devs can still fetch the library from your private repository.
edit: There's another possible solution: vendoring. A fancy word for "download the source for all your deps and include it in your project directly". Sounds janky, but it's very reliable. Google uses this method of dep management for their Go projects (also partly because Go deps management is lacking).
Moral Panic
Member
Majour bugs like Heartbleed etc get silently fixed weeks if not months before an annoucement. Having sensible versioning and downloading dependencies at build makes sense.
cpp_is_king
Member
All of this still goes back to "you need to manage your deps". Whatever that means and whatever process you use, it's not free. Having 50 very useful deps is better than having 5000 shitdeps that are 5 lines of code each if for no other reason than the amount of effort required to manage them is worth the benefit you get from them.
Again, not exactly rocket science.
AbortedWalrusFetus
Member
Please stop reminding me about how painful dependency management is. I like to block out the pain when possible.
no, they download it once when they add the dependency and manually update them when they feel like it.
imo, the problem with JS developers is that most of them have no higher level background of software engineering.
they started out with jQuery dabbling around with the dom while JS and web development snowballed into something bigger and they got dragged along.
there's a reason why things like coffeescript got invented in the first place because now jQuery developers needed to dive deeper into JS but couldn't figure anything out so they needed another abstraction layer that targeted the language itself.
those tiny libraries like isArray is another example normally you would know how to do something like this.
now JS is actually pretty decent and I love to work with it but some of my colleagues seriously lack a high level view now that you can write enterprise grade applications with JS.
Purple Cheeto
Member
If anything this whole kerfluffle has really shown the difference in thinking across different programming communities about a lot of fundamental ideas in software engineering.
It seems that people who have worked on more constrained software (desktop apps, mobile apps, embedded systems) find this whole thing a lot more ghastly than people whose primary domain is web centric.
It seems that people who have worked on more constrained software (desktop apps, mobile apps, embedded systems) find this whole thing a lot more ghastly than people whose primary domain is web centric.
Coffescript was invented for classic OO people who didn't like javascript because they didn't know how to organize large js projects or fully utilize functional languages. Now that js has a zillion frameworks and class sugar those people have largely been placated. Suffice to say, js has one of the largest ranges of skill levels. It's super easy to get into but mastering it is quite difficult especially since it's a fast moving target. You'll find all sorts of levels.
NPM is easily one one of the best out there. That's why people use and abuse it so hard.
It's actually really interesting because web is more vulnerable to this. Most high-end web projects do timed auto deploys, it's a pure assembly line. On the other hand super easy deploys (and super easy rollbacks) means they are just as easily fixed.
Do you know any reading material or resources that talks about this or is this more of an experience thing?
Functional programming or organizing JavaScript projects?
Both but it's "organising projects" that specifically caught my eye since it's less immediately googleable.
For functional programming, the best thing is to spend a couple weeks learning Haskell. Stop reading the book and quit using Haskell as soon as you can make something simple like a tic tac toe console app. I know this sounds like a waste of time because it's a different language, but there is no better introduction to functional programming. Haskell doesn't have any variables, so you are forced to suppress your imperative instincts and use a functional style. You will look at Javascript very differently when you go back.
Project oranization is extremely subjective and I don't think there's much consensus. Even hallmarks like "don't repeat yourself" and "no singletons" have prominent detractors.
It's more of an experience thing as there's a million ways to do it. The best place to start is to pick a framework (Angular, React/Redux, Ember, Backbone, Knockout etc) and start using it. The purpose of most frameworks is to specify a standard way to do things, each one is different and they all have tradeoffs but even using one should give you ideas on how to better structure your application whether you stick with it, go with another one or do your own thing. Even better is use several and get a feel for the strengths and weaknesses and decide what you like. Virtually all of them are some permutation of Model-View-Controller (MVC), sometimes you pair your views and models together, sometimes you pair your views and controllers together or whatever but once you get the feel for it you learn how to logically group pieces of the application. Also don't worry too much about what you choose, some are more marketable right now but much like languages they go in and out of fashion but a lot of the knowledge is portable.
I've barely done any javascript (I not enjoyed it much when I tried it for the first time a long time ago, probably because of bad tutorials and the fact that it's a moving target, as I like clean things, and have been reluctant to invest myself in it since).
But seeing comments about functional behavior makes me wants to consider it again... (I've not done a lot of Haskell, but plently of CaML, and while you can define mutable objects, I tend to avoid them as much as I can, functional-style... Also a bit of F#, a lot of Scala, some Clojure and Scheme too.) Maybe I shouldn't stay away from Javascript any longer ^_^
I don't think there's absolutes rules.
Each time I read "you should never do this" for coding styles, I die a little. I think you should always consider the situations and the alternatives.
When I see a perfectly readable 5-lines function that is translated into a 15 lines one with more complex boolean expressions and a couple more variables because " you must not use break and return should be at the last line ", I really wonder if it's really sane.
Even more so when I see this in a book that implement stacks in Python by defining push and pop by using L.insert(0, elem) and L.pop(0). Yes, because... you need to stick rigorously to principles, but turning O(1) operations into O
is fine?I use F# with the Unity game engine. I make the logic stateless, but to interact with Unity I'm forced to have one variable which stores the entire game state - player input, player location, etc. I store the game state with unions and records, then define methods on the game state which give me the next state. Then I pass the state value into all of my view classes to update them.
Code:
member this.Update () =
state <- state.Next
updateViews stateAbout this, I've wanted to avoid using Java to develop some software for Android...
Would you, by any chance, know how hard it is to use C# / F# and Unity for this? I may try this summer...
(Although one of the projects need SQL and Unicode support, and not a lot of fancy graphics, and I'm not sure Unity is a better solution for this than normal Android framework, even if I really don't like working with Java)
Easier than native development for sure with C# or Javascript. The only real learning curve is figuring out what a GameObject is, which shouldn't take long. F# is not officially supported, but you can get it to a work by making a dll with the right build settings. You can use SQLite for mobile.
Great, many thanks... I'll try to find an example that show how to build an app and upload it, and try it in a couple of months. Will be a chance to practice F# a bit more while doing something useful...
I guess the lack of support doesn't prevent you to share the code with others, on the store or elsewhere?
I guess the lack of support doesn't prevent you to share the code with others, on the store or elsewhere?
I doubt it. You just make a package that includes the F# dll in the right place and it will work for others.
OminoMichelin
Member
is there a primer to F# programming in Unity somewhere?
balgajo
Member
So guys, I will start a cross platform project using C/C++ in my company. The objective is to create one application to run in multiples POS devices. Each vendor provides an API to communicate with their devices and the plan is to create an abstraction for those APIs. Does anyone have tips(articles, books...) to do it in the best way as possible?
I take it you never used npm on your projects? It is DECEPTIVELY easy to just get a module, or have a module that DEPENDS on a module.
Somewhere along the line modules became widespread that contained such dependencies.
The fact that angry, salty and really not javascript-knowing programmers (yes, I give them that, I do not need to resort to "programmers") decide to unleash their bottled feelings about the language and its users now is really telling.
NPM will become better because of this. User that want to improve will become better because of this. Javascript will not stop evolving, and good programmers programming in javascript will evolve further. What other progammers think of this is both irrelevant and useless when it comes to trying to stop JS's widespread usage both on frontend and the backend.
(And here I am, still trying to diversify, because that is also cool. But that does not mean any issues with a package manager is a good sign of JS devs being inferior.)
Again: this particular problem became a big issue because MANY people rely on babel, for example. MANY. This is just a pyramid of cards where one particular card was responsible for this. It is a good lesson, and it is being handled very well by all parties involved.
I can make one soon if you two want it.