831–840 of 887 posts
Earlier quoted context omitted.
So have libmath depend on libsin, libcos, libtan and libsinh. People who want the kitchen-sink version can get it. People who want just one specific submodule can depend on that. What's not to like?
There's a cognitive load to every additional thing you need to know to use a module. At a certain point, added flexibility becomes more trouble than it's worth.
Usually, dependency hell doesn't bite you, until it does. Try to rebuild that thousand-dependencies app in three years from now and you'll see ;-) I recently had to rebuild a large RoR app from circa 2011 and it took me longer to solve dependencies issues than to familiarise myself with the code base. Excessive dependencies are a huge anti-pattern and, in our respective developers communities, we should try to circul…
> Try to rebuild that thousand-dependencies app in three years from now and you'll see ;-) Let's be honest though, in the current trendy javascript ecosystem these people will already be two or three jobs away before the consequences of their decisions become obvious. Most of the stuff built with this is basically disposable.
Earlier quoted context omitted.
In JavaScript, the API could be fairly complex. Thing is, JavaScript doesn't have arrays of numbers. So, what should the function do if the array passed in contains a null , an undefined , a string such as "7", "012", "008", or "2+3", a function, another array, a hash, etc? I can easily see this grow into a function accepting options indicating such things as "null values are zeroes", "ignore null values", "evaluate…
IMO the behavior of "average" should be unspecified if it's passed anything but a single nonempty array of numbers. Making it even a tiny bit more robust is wasted work. Moreover, it's harmful because it encourages sloppy calling code.
When the developers of such a serious library as React start to depend on a third-party one-function module made by some Dick-from-a-mountain (a russian idiom that means a random person who did nothing significant but tries to show out in all possible means), that means React developers are even more to blame than that Dick-from-a-mountain himself.
If you make any really popular piece of software, you absolutely must have a failover plan. No excuses for not having it.
But what's even sadder is that this issue had spawned a new wave of pseudo-elitist attacks on the entire JS dev community. Calm down guys, things like that could have happened for any language that has a widely-used centralized package system (Perl's CPAN, Python's pip, Ruby's gems etc).
Let me repeat that again: languages don't make software bad, people do. Just don't let such Dicks-from-a-mountain rule over your own modules with elementary stuff like leftpad, and you'll be safe.
Earlier quoted context omitted.
You mean like the sad story of PKzip?
May you share the story ?
Everyone keeps mentioning the lack of a standard library for JavaScript as an excuse for this shit show. IMO this is just a futile attempt to mask incompetence.
Any modern standrards-compliant implementation of JS (following ES5 and especially ES6/ES2015 standard) already has everything that a sane programmer would ever need.
leftpad = (str, len, pd = ' ') => Array(len > str.length ? 1+len-str.length : 0).join(pd) + str
WTF are you talking about? Making this into a module?!
Earlier quoted context omitted.
return string[0] === string[0].toUpperCase(); You're welcome!
WRONG. Typical junior developer mistake. Even if we disregard trivial problems such as non-letter input or empty input, this will only work with English and a few other languages. This will TOTALLY fail with e.g. Turkish input (I ı vs İ i).
Adding another module with a method does not fix the original problem, it just creates more problems for other people to solve.
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…
Small modules are easy to reason about Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page. By focusing on the small-scale complexity to such an extreme, you've managed to make the whole system much harder to understand, and understanding the big picture is vital to things like debugging and making systems which are effici…
Well put. I've noticed a curious blind spot in how people account for complexity: we count the code that 'does' things much more than the code that glues those things together. This distorts our thinking about system complexity. A cost/benefit analysis that doesn't consider all the costs isn't worth much.
An example is when people factor complex code into many small functions, then say it's much simpler because smaller functions are easier to understand. In fact this may or may not be true, and often isn't. To get a good answer you must consider the complexity you've added—in this case, that of the new function declarations and that of the calls to them—not just the complexity you've removed. But it's hard to consider what you don't see. Why is it so easy not to see things like this? I think it's our ideas about programming, especially our unquestioned assumptions.
The complexity of glue code goes from being overlooked to positively invisible when it gets moved into things like configuration files. Those are no longer seen as part of the system at all. But of course they should be.