3 ms·

It's the third time I see that link already, he's wrong, so please stop posting it :) The way to reuse N lines of code is to refactor them in a function. The w

by blub 11y ago

It's the third time I see that link already, he's wrong, so please stop posting it :) The way to reuse N lines of code is to refactor them in a function. The way to reuse functions is to pack them into libraries. This is something that probably everyone agrees with. Many have issues with the idea that one should create libraries containing one function only! You've touched yourself upon the why: having hundreds of dependencies adds both technical and cognitive overhead. It's very hard to design things to be extended, so in practice one ends up with a fragile module, not one that can be improved by improving a dependency (I wonder how a function that checks if a number is negative can be improved...). As far as I know there is no other toolchain on this planet where it's done this way, which together with the clarification above should be telling you and sindresorhus something!

danieldk 11y ago
Many have issues with the idea that one should create libraries containing one function only! You've touched yourself upon the why: having hundreds of dependencies adds both technical and cognitive overhead. Indeed. Moreover, it's a sign of a weak or incomplete standard library. Early Java had this problem as well. However, since distribution consisted of passing around JAR files, most utility code was bundled in larger libraries (e.g., see commons-.*).
dozzie 11y ago
> As far as I know there is no other toolchain on this planet where it's done this way [...] If by "this way" you mean microdependencies in JavaScript, you should also look at Ruby, which goes in a similar direction. And at Python, which apparently tries to follow the lead.
- pjmlp 11y ago
  Somehow I see a common theme there...
  - workusername 11y ago
    Yes, let's dig into it.
    - pjmlp 11y ago
      From my point of view, all dynamic languages usually used by people without CS background.
      - steveklabnik 11y ago
        My first five years after getting my CS degree, all of my paid work was in languages with dynamic typing.
        pjmlp 11y ago
        Some people apparently took my comment personally, but it doesn't change the fact that many in those communities aren't from a CS background. Which is why some decisions, like the whole npm modules, or the ruby gems before bundles (if I get it right), get to be taken without consideration how it works in large scale. Of course people with CS background also use dynamic languages. I have Python, Smalltalk, Lisp, Perl, JavaScript on my CV.
        steveklabnik 11y ago
        There are lots of people from both kinds of backgrounds in all kinds of communities; how much of classic hacker lore is about high school dropouts, let alone college dropouts? A CS degree doesn't mean you'll be a good programmer in industry.
        pjmlp 11y ago
        No, but it helps. I have a technical school specialization in computing and a CS degree. Many of the things we learned at technical school only made sense afterwards when I got into CS. Also some of the design problems we had, which were solved by the usual"try something until it works", became basic programming exercises with the right CS information. Yeah, it isn't a magic solution, but it helps in what concerns designing software in the large. Most other backgrounds aren't exposed to such issues.
- icedchai 11y ago
  Generally neither Ruby nor Python have "dependencies" as small as you see with NPM/JavaScript. JS takes it to an extreme.
zaphar 11y ago
Javascript has a problem unique among all the other languages toolchains. It's primary use is to ship to a browser. However shipping an entire string-util library because you need a string prefix function is wasteful and bad engineering. But javascript doesn't have dead code elimination anywhere in it's toolchain unless you use Closure. And that really only works well if all of your dependencies are using Closure as well. As a result of all this javascript needs a poor mans dead code elimination at the package manager level. Including a package only includes the code you will actually use. This helps to keep your javascript code that you send to the browser small. What works for Java or C++ won't work here for the above reasons. This isn't npm's fault, it's intrinsic to javascript the language and it's primary target platform the browser.
deleted 11y ago
[deleted]

by blub 11y ago

danieldk 11y ago

Many have issues with the idea that one should create libraries containing one function only! You've touched yourself upon the why: having hundreds of dependencies adds both technical and cognitive overhead. Indeed. Moreover, it's a sign of a weak or incomplete standard library. Early Java had this problem as well. However, since distribution consisted of passing around JAR files, most utility code was bundled in larger libraries (e.g., see commons-.*).

dozzie 11y ago

> As far as I know there is no other toolchain on this planet where it's done this way [...] If by "this way" you mean microdependencies in JavaScript, you should also look at Ruby, which goes in a similar direction. And at Python, which apparently tries to follow the lead.

pjmlp 11y ago
Somehow I see a common theme there...
- workusername 11y ago
  Yes, let's dig into it.
  - pjmlp 11y ago
    From my point of view, all dynamic languages usually used by people without CS background.
    - steveklabnik 11y ago
      My first five years after getting my CS degree, all of my paid work was in languages with dynamic typing.
      - pjmlp 11y ago
        Some people apparently took my comment personally, but it doesn't change the fact that many in those communities aren't from a CS background. Which is why some decisions, like the whole npm modules, or the ruby gems before bundles (if I get it right), get to be taken without consideration how it works in large scale. Of course people with CS background also use dynamic languages. I have Python, Smalltalk, Lisp, Perl, JavaScript on my CV.
        steveklabnik 11y ago
        There are lots of people from both kinds of backgrounds in all kinds of communities; how much of classic hacker lore is about high school dropouts, let alone college dropouts? A CS degree doesn't mean you'll be a good programmer in industry.
        pjmlp 11y ago
        No, but it helps. I have a technical school specialization in computing and a CS degree. Many of the things we learned at technical school only made sense afterwards when I got into CS. Also some of the design problems we had, which were solved by the usual"try something until it works", became basic programming exercises with the right CS information. Yeah, it isn't a magic solution, but it helps in what concerns designing software in the large. Most other backgrounds aren't exposed to such issues.
icedchai 11y ago
Generally neither Ruby nor Python have "dependencies" as small as you see with NPM/JavaScript. JS takes it to an extreme.

zaphar 11y ago

Javascript has a problem unique among all the other languages toolchains. It's primary use is to ship to a browser. However shipping an entire string-util library because you need a string prefix function is wasteful and bad engineering. But javascript doesn't have dead code elimination anywhere in it's toolchain unless you use Closure. And that really only works well if all of your dependencies are using Closure as well. As a result of all this javascript needs a poor mans dead code elimination at the package manager level. Including a package only includes the code you will actually use. This helps to keep your javascript code that you send to the browser small. What works for Java or C++ won't work here for the above reasons. This isn't npm's fault, it's intrinsic to javascript the language and it's primary target platform the browser.

deleted 11y ago

[deleted]