Comment by forgotpwtomain

11 years ago

> 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....

If anything looking at sindresorhus's activity feed: (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..

17 comments

forgotpwtomain

Reply
Cut_N_Paste  11 years 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.

  • wtbob  11 years 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.

  • spion  11 years ago

    Promise was clearly necessary, because without it we had hundreds of other less principled ways to implement async control flow :)

    • nailer  11 years 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.

      8 replies →

nailer  11 years 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  11 years ago

    If you don't know how to write a function to left-pad a string without copy & pasting, you have other problems..

    • nailer  11 years ago

      What makes you think people who don't write their own left pad function can't write a left pad function?