871–880 of 887 posts
Earlier quoted context omitted.
Case in point: the left-pad package has quadratic complexity.
Depends on the JS implementation in question. And I think node uses one that optimizes string concatenation, possibly making that the fastest way to do it.
It's really nice how we once again depend on "I think some guys do it like this" for performance. What happened to standards?
What's next? SEO for code?
Earlier quoted context omitted.
You're talking about the purely technical aspects of package management that keep your build from breaking. My point is that there's a lot more to it than that. Lockfiles do not keep software from requiring maintenance. Introducing a dependency means handing off a chunk of your software project to someone else to maintain. If they do it wrong, you're on the hook for it. For example, I was a maintainer for an admin UI…
But if you write it yourself, you're also on the hook for it. So I don't see a meaningful difference here.
A dependency introduces some constant amount of risk (d) that does not vary with the size of the dependency. Every line of code you write yourself also introduces a much smaller constant amount of risk (y).
If you introduce a separate dependency for every line of code in a 1000-line project, your risk is 1000d.
If you can pull in someone else's code for the whole thing and don't need to write any code yourself, your risk is d.
If 200 lines of your code can be replaced with an external library, your risk is d + 800y.
I think the real disagreement here is over the value of d. My experience leads me to put the value of d pretty high relative to y, so to me 1000d is the worst possible case. If someone sees d as equal to y, then they'd see dependencies as no problem whatsoever.
(Obviously in reality the risk of a dependency is not really constant - it's probably more like d + 0.1y or d + 0.01y or whatever, since a 10-line dependency is less risky than a 1000-line dependency. Hopefully my point still stands.)
Yes, or more accurately a large new generation of coders is entering the workforce who know how to code only in a superficial sense and think this is a good thing. Programming, and especially startup programming, is being taken over by people who are primarily technicians rather than engineers. They want to assemble prefab components in standardized ways rather than invent new things. They are plumbers who know how t…
The thing is, it actually doesn't matter. No one needs to be a certain way. Cool things will be done by people that can and will do those cool things. In the end the prescriptivity of this whole space is only ascribed by people internal to the whole system: externally nothing is 'supposed' to be done. This is just a symptom of more people programming. The thing that will speak the loudest is actions and results. If p…
If you do have specific short term goals -- such as, say, "building a profitable software product before we run out of money" -- then all methods of approaching the task are demonstrably not equal. Some will work much better than others in terms of achieving that goal.
We can study the empirical results of the numerous attempts already made by other people and thus avoid repeating their mistakes.
Earlier quoted context omitted.
Worry not my friend. I'll take the risk of being wrong. Up to now, it seems that there's consensus on the fact that the JS/frontend world is the worst offender when it comes to engineering robust software. At least there are JS programmers that seem aware of it and agree that this has to change. So there's still hope I guess.
> JS/frontend world is the worst offender when it comes to engineering robust software I completely agree. I still can't understand why the language that we depend on for increasingly large-scale front-end work still works like this: [1, 10, 2, 21].sort() // returns: [1, 10, 2, 21] It's 2016, software engineering is purported to be a profession, and we still have the worst tools imaginable.
Part of the problem, in my opinion, is that packages are not subject to any review process. These dependency chains get out of hand because they are rarely top-of-mind.
Earlier quoted context omitted.
This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…
How is that superior to copypasting from a stackoverflow answer? If it's a popular issue, lots of people had the same issue, many will be nice enough to add their edge cases and make the answer better, most will not. Same goes for contributing to a package. With a package you would be able to update when someone adds an edge case, but it might break your existent code and that edge case may be something that is not p…
How do I systematically make sure that I have the latest version of every stackoverflow code snippet? If it's a new post, it may not have all the edge cases fixed yet. So now I have to check back on each of the X number of snippets I've copied.
In the npm approach, I can easily tell if there's a new version. For prod, I can lock to a specific version, but in my test environment, I can use ^ to get newer versions and test those before I put them in production.
If the edge case of new version of a package breaks my code, I've learned that I'm missing a unit test. Plus, the question isn't whether this bad thing might happen on occasion, the question is whether this approach is, on balance, superior to cutting and pasting random code snippets into my code. I think the downside of the npm approach is less than the downside of the copypasting from stackoverflow approach.
And every moderately useful npm package I've looked at has very good to great documenation.
Earlier quoted context omitted.
A module doesn’t solve that kind of type confusion, though. Static typing does. The next best thing in JavaScript is passing consistent types of values to your functions, so just write function isPositiveInteger(x) { return x > 0 && Number.isInteger(x); } and always pass it a number. (Of course, this shouldn’t even be a function, because JavaScript is confused about the definition of “integer” – maybe you really want…
x >>> 0 changes a negative integer to an unsigned (positive) 32-bit integer. You can have integers greater than 32 bits. They're represented internally as floats. Bitwise operators make 32-bit assumptions, with the top bit as a sign bit, unless you do x >>> 0, in which case you can revert a sign bit overflow back to a positive integer. If you have a positive integer that's greater than 32 bits, x >>> 0 === x fails. T…
I didn't know the >>> operator converts to 32-bit. How does it do that? Mask off the top bits? Or give you a NaN if it's bigger?
But (and someone please correct me if I'm wrong), at the end of the line it's still represented as a 64-bit float internally and accurately.
Earlier quoted context omitted.
This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…
> TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"? What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?