Hacker News new | past | comments | ask | show | jobs | submit login

I see stuff like:

    promise.when(function(value){
       //blah blah blah
    })
    .error(function(err){
       //handle it
    })
and I think to myself I'm seeing text replacements:

    "promise.when(function(value)" = "try"
    ".error(function" = "catch"
    "})" = "}"
So how is this actually different from the code we're supposedly too lazy to write or too stupid to figure out or something in the first place, thus requiring this slightly more verbose form?

And where is this all going? Like, what's the right granularity of lines-of-code to when chains? If programmers are too lazy to try/catch, then why aren't we too lazy to when/then/error a gigantic block, or you know, not at all? And if we were to instead [w|t]hen/error every line, then I think about DRY and and it occurs to me the most likely next step is a language that "implicitly whens your code", that every line is written like regular procedural code, but automagically has "when" inserted in the middle.

Or in other words, you know, continuations.

But it occurs to me that the only reason any of this stuff is of any interest is because JavaScript, and therefore Node, still lacks real MT support, so you have to jump through these infinitely fractal spilling callback tangos to fake it.

Web Workers was 2009, people. 5 YEARS MAN. Five years that we've been waiting to hear anything about having sane primitives for MT.




Nope, `doStuff().then(function(value)" != try`

A closer representation would be `try { var value = doStuff()` which has similar verbosity.

ES6 will have generators and "arrow" function syntax. Meaning:

  doThing().then(function(value){
     //blah blah blah
  })
  .catch(function(err){
     //handle it
  })
becomes either:

  try { 
    var value = yield doThing();
    //blah blah blah
  } catch (err) {
    //handle it
  }
or

  doThing().then(value => /* blah blah blah */)
    .catch(err => /* handle it */);
meaning you can pick your paradigm :) Except that the functional one composes slightly better, perhaps.

  doThing().then(value => /* blah blah blah */)
    .catch(only(ParseError, err => /* handle it */));
vs

  try { 
    var value = yield doThing();
    //blah blah blah
  } catch (err) {
    only(err, ParseError); // argument repetition
    //handle it
  }


Uhhh, you're not convincing me that you've said anything meaningful towards improving software quality.


As opposed to what, threads? They have contributed towards improving software quality? In most languages with mutable state they've been a disaster -- correct me if I'm wrong.

Adding threads in JavaScript would also be a disaster. Practically everything is mutable and there are absolutely no locking mechanisms.


One possible solution to introduce threads to JS is to isolate threads from each other and use only message-passing:

https://github.com/audreyt/node-webworker-threads/


Sorry, but share-nothing threads that can only communicate via (afaics) serialized message passing are no longer threads. There is very little benefit to those compared to just spawning child processes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: