4 ms·

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 n

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.
        spion 11y ago
        Callback hell is a "loss of composition" problem. Most languages, including JavaScript, have things called expressions. Expressions rely on functions returning their output. They become useless when functions give their output through a callback passed as their input: they don't compose with that frankenstein. Node style callbacks are a prime example of how in the quest for "simplicity" and hate for abstractions its easy to build a monster / frankenstein like caolan's async. Node callbacks were a self-contradicting philosophy: it abandoned all thats already in the language in the quest to avoid an abstraction that was not already in the language :)
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:-)

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.
        spion 11y ago
        Callback hell is a "loss of composition" problem. Most languages, including JavaScript, have things called expressions. Expressions rely on functions returning their output. They become useless when functions give their output through a callback passed as their input: they don't compose with that frankenstein. Node style callbacks are a prime example of how in the quest for "simplicity" and hate for abstractions its easy to build a monster / frankenstein like caolan's async. Node callbacks were a self-contradicting philosophy: it abandoned all thats already in the language in the quest to avoid an abstraction that was not already in the language :)

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:-)