5 ms·

> This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/ama/issues/10#i

> This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/ama/issues/10#issuecomment-1.. https://github.com/sindresorhus/ama/issues/10#issuecomment-1.... If anything looking at sindresorhus's activity feed: (https://github.com/sindresorhus https://github.com/sindresorhus) perfectly supports the author's point. Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line function they need to use in their code and then spend countless commits bumping project-versions and updating package.json files. I have no idea how they get work done though..

Cut_N_Paste 11y ago
I think the gist of this whole discussion ( at least the OMG WHY?!?! ) part, can be easily explained by an excerpt from your example comment that sums up in a nutshell the all too pervasive mindset I've seen over the years: "...LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care about the details of how it's made. All you need to know is how to use the lego blocks to build your lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works..." By LOC he's referencing 'ye ole Lines of Code paradigm, and trying to make the point that in the end it just doesn't measure up to the prime directive of "containing complexity". ... and that's where I beg to differ. What I think is being completely overlooked here is the net cost of abstracting away all that complexity... It's performance. Every extra line of code, extraneous function call, unnecessary abstraction ( I'm looking at you promise ), every lazy inclusion of an entire library for the use of a shortcut to document.getElementById -- these all add unnecessary costs from the network down to the cpu. And who pays these costs? The end users of your slow, memory hogging, less-than-ideal set of instructions to the cpu that you call an application... but hey, it's easier for you, so there's that.
- spion 11y ago
  Promise was clearly necessary, because without it we had hundreds of other less principled ways to implement async control flow :)
  - nailer 11y ago
    We had, and still prefer (looking at npm stats) the async module. Eg: promise.then(function(){}).then(function(){}) is not substantially different than: async.waterfall([function(){}, function(){}]) Promise advocates kept pretending async didn't exist though, and everybody was using callback hell.
    - spion 11y ago
      Nobody pretended that async didn't exist, we just knew its the best "solution" that ignored the problem. Which was: throwing away the entire language's compositional features, including the concept of input arguments and return values, results with... poor compositionality, of course.
      - nailer 11y ago
        I thought the problem was callback hell. I've sat through a bunch of promise talks and the problem was never 'JS should be more compositional'.
        spion 11y ago
        Yes, uncompositionality of callbacks leads to callback hell. Or to reinventing every single thing but for callbacks. Like array.map (which works with promises) or array.forEach (also works with promises) or every single synchronous function (they all work when passed to promises).
        nailer 11y ago
        If you solve callback hell for a series of sequential functions by using an actual series of sequential functions, you don't have nested callbacks and you didn't require Promises or composition - just a basic understanding of data structures and first class functions. It seems you're defining callback hell as 'whatever promises solves' rather than it's common definition of over-nesting.
- wtbob 11y ago
  > ye ole Lines of Code paradigm Little-known fact: the *y in old signs is actually a 'þ', which is an Old English letter named 'thorn' and pronounced like modern 'th.' Thus, the old books & signs were really just saying, 'the.' Incidentally, þ is still used in modern Icelandic. Completely off-topic, but I þought you might be interested.
  - mreiland 11y ago
    holy shit, I had no idea. That's cool. edit: and I double checked, because the internet :) http://www.etymonline.com/index.php?term=ye http://www.etymonline.com/index.php?term=ye it's true! that's awesome.
    - wtbob 11y ago
      I really þink ðat we ought to use þ and ð in modern English, but oddly enough no-one agrees wiþ me:-)
nailer 11y ago
> Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line function they need to use in their code and then spend countless commits bumping project-versions and updating package.json files. I have no idea how they get work done though... Rather than copy paste someone else's unmaintained thing and handle all the bugs, or write their own code and unit tests, they use the same library as a few thousand other people?
- forgotpwtomain 11y ago
  If you don't know how to write a function to left-pad a string without copy & pasting, you have other problems..
  - nailer 11y ago
    What makes you think people who don't write their own left pad function can't write a left pad function?

Cut_N_Paste 11y ago

I think the gist of this whole discussion ( at least the OMG WHY?!?! ) part, can be easily explained by an excerpt from your example comment that sums up in a nutshell the all too pervasive mindset I've seen over the years: "...LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care about the details of how it's made. All you need to know is how to use the lego blocks to build your lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works..." By LOC he's referencing 'ye ole Lines of Code paradigm, and trying to make the point that in the end it just doesn't measure up to the prime directive of "containing complexity". ... and that's where I beg to differ. What I think is being completely overlooked here is the net cost of abstracting away all that complexity... It's performance. Every extra line of code, extraneous function call, unnecessary abstraction ( I'm looking at you promise ), every lazy inclusion of an entire library for the use of a shortcut to document.getElementById -- these all add unnecessary costs from the network down to the cpu. And who pays these costs? The end users of your slow, memory hogging, less-than-ideal set of instructions to the cpu that you call an application... but hey, it's easier for you, so there's that.

spion 11y ago
Promise was clearly necessary, because without it we had hundreds of other less principled ways to implement async control flow :)
- nailer 11y ago
  We had, and still prefer (looking at npm stats) the async module. Eg: promise.then(function(){}).then(function(){}) is not substantially different than: async.waterfall([function(){}, function(){}]) Promise advocates kept pretending async didn't exist though, and everybody was using callback hell.
  - spion 11y ago
    Nobody pretended that async didn't exist, we just knew its the best "solution" that ignored the problem. Which was: throwing away the entire language's compositional features, including the concept of input arguments and return values, results with... poor compositionality, of course.
    - nailer 11y ago
      I thought the problem was callback hell. I've sat through a bunch of promise talks and the problem was never 'JS should be more compositional'.
      - spion 11y ago
        Yes, uncompositionality of callbacks leads to callback hell. Or to reinventing every single thing but for callbacks. Like array.map (which works with promises) or array.forEach (also works with promises) or every single synchronous function (they all work when passed to promises).
        nailer 11y ago
        If you solve callback hell for a series of sequential functions by using an actual series of sequential functions, you don't have nested callbacks and you didn't require Promises or composition - just a basic understanding of data structures and first class functions. It seems you're defining callback hell as 'whatever promises solves' rather than it's common definition of over-nesting.
wtbob 11y ago
> ye ole Lines of Code paradigm Little-known fact: the *y in old signs is actually a 'þ', which is an Old English letter named 'thorn' and pronounced like modern 'th.' Thus, the old books & signs were really just saying, 'the.' Incidentally, þ is still used in modern Icelandic. Completely off-topic, but I þought you might be interested.
- mreiland 11y ago
  holy shit, I had no idea. That's cool. edit: and I double checked, because the internet :) http://www.etymonline.com/index.php?term=ye http://www.etymonline.com/index.php?term=ye it's true! that's awesome.
  - wtbob 11y ago
    I really þink ðat we ought to use þ and ð in modern English, but oddly enough no-one agrees wiþ me:-)

nailer 11y ago

> Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line function they need to use in their code and then spend countless commits bumping project-versions and updating package.json files. I have no idea how they get work done though... Rather than copy paste someone else's unmaintained thing and handle all the bugs, or write their own code and unit tests, they use the same library as a few thousand other people?

forgotpwtomain 11y ago
If you don't know how to write a function to left-pad a string without copy & pasting, you have other problems..
- nailer 11y ago
  What makes you think people who don't write their own left pad function can't write a left pad function?