Earlier quoted context omitted.
> It's not deceptive if you have a preemptively multitasking runtime that you trust That may be so, but since Javascript is inherently single threaded _and_ this is about javascript I agree with Cushman that it is indeed deceptive.
But we aren't talking about Javascript. It's about a theoretical replacement language. Also, the reason you care about the "synchronicity" in the first place is because your environment forces you to care! When it all Just Works (TM), you don't care whether it's "synchronous" or not. That's a deficiency in your language, not a feature. I'm not theorizing. I program in this sort of language all the time. You worry muc…
Fogus: Node.js should become its own language
61–70 of 79 posts
Re: Fogus: Node.js should become its own language
#62Earlier quoted context omitted.
> It's not deceptive if you have a preemptively multitasking runtime that you trust That may be so, but since Javascript is inherently single threaded _and_ this is about javascript I agree with Cushman that it is indeed deceptive.
But we aren't talking about Javascript. It's about a theoretical replacement language. Also, the reason you care about the "synchronicity" in the first place is because your environment forces you to care! When it all Just Works (TM), you don't care whether it's "synchronous" or not. That's a deficiency in your language, not a feature. I'm not theorizing. I program in this sort of language all the time. You worry muc…
Re: Fogus: Node.js should become its own language
#63Earlier quoted context omitted.
'this' is evil in Javascript. The very first line in any constructor function that I write is: var that = this; From then on, I use 'that' instead of 'this', relying on closure magic to make things work. You never have to worry about how the function is bound thereafter.
Thanks. I think I like that solution, as it's extremely simple. Are there any drawbacks? CoffeeScript is cool, as it is basically "Python in JS" but I have some resistance against languages that convert to other languages. I'm not so sure why.
Re: Fogus: Node.js should become its own language
#64Since fogus is responding here: Other than hitching your wagon onto the fantastic hype storm that Node.js has generated, which I must say is a good move overall, reading your target description, why not start with Haskell or Erlang? You could start from there and mutate out but actually have a library base to start from. Or one of the languages sitting on top of Erlang like Reia. (Or discover that you don't need to m…
I will upvote you if you explain what you mean by the last part about "this style of programming" previously being on its (it's? anyone) way out. Do you mean an asynchronous style using callbacks?
I laid it out more at http://news.ycombinator.com/item?id=2370303 .
Javascript doesn't particularly bring any abstraction capabilities to the table that Perl (POE, Event::Lib, IO::Async), Python (Twisted), or Ruby (EventMachine) doesn't, and current Javascript is actually deficient in the abstraction department by comparison. (The latest ECMAscript spec can compare to them, so Javascript will get there. Something like Python generators allow you to string together a couple more tricks together before the complexity becomes a problem, and Javascript will eventually have this.) They all result in programs that end up the same way. There are some tricks you can play that improve the situation a bit over raw callbacks, like trying to sequence them, but composing these tricks together gets harder and harder the fancier you get.
None of those libraries really took off and some of them I know had way more effort poured into them than Node.js has seen yet, like Twisted. And it's because the style, combined with language runtimes that can't manage the scheduling for you while retaining the code context, has certain inevitable results. You can (and should!) delay the inevitable, but it's still inevitable.
At the very least, I would suggest that if you going to consider using Node.js you should be aware of the fact that it's not a blindingly new thing, it's a relatively well-explored space being translated into a new language, and you can get a good sense of the tradeoffs from the many previous explorations of this space. There are still places where it may be the right choice; as I said in that other message, I have chosen event-based coding in another context because it was still the right choice. But I knew the tradeoffs going in, and took steps to mitigate them, rather than being blindsided by them.
Re: Fogus: Node.js should become its own language
#65Why would you write this: [long_io_operation with callback] When you can instead write this: [long_io_operation without callback] Off the top of my head, I'd say because "var result = long_io_operation(req);" is not only not self-documenting but actively deceptive if long_io_operation is an asynchronous call. I'm not sure I see what's to be gained by pretending closures don't exist.
Python's twisted library supports both styles: d = long_io_operation() d.addCallback(callback) d.addErrback(errback) With defer.inlineCallbacks: try: result = yield long_io_operation() callback(result) except Exception, e: errback(e) It is not necessary to use functions in the second case.
yield f1()
yield f2()
You force f1 to finish before being able to start f2, which goes against the whole point of using something like twisted in the first place ! I have also noticed that inlineCallback screw up the traceback (e.g. http://twistedmatrix.com/trac/ticket/3622 - I still see this with twisted 10.0.0).While I am no genius, I am a decent programmer, with quite a few years of experience in python, and I still can't read most non trivial async code in twisted with confidence. It is almost impossible IMO to get a clear idea of the codeflows and especially error flows to ensure error handling is done right. Error handling is already difficult as is, adding exception made it that much harder, but adding async makes it basically impossible except for Vulcans.
Re: Fogus: Node.js should become its own language
#66Since fogus is responding here: Other than hitching your wagon onto the fantastic hype storm that Node.js has generated, which I must say is a good move overall, reading your target description, why not start with Haskell or Erlang? You could start from there and mutate out but actually have a library base to start from. Or one of the languages sitting on top of Erlang like Reia. (Or discover that you don't need to m…
I will upvote you if you explain what you mean by the last part about "this style of programming" previously being on its (it's? anyone) way out. Do you mean an asynchronous style using callbacks?
"way out" belongs to "it", so you're looking for the possessive form. English pronoun possessives do not use apostrophes (whose, mine, his, her, their, its), while everything else DOES (the dog's, Steve's, Portugal's, the crowd's).
tl;dr: it's "its".
Re: Fogus: Node.js should become its own language
#67Earlier quoted context omitted.
It's not deceptive if you have a preemptively multitasking runtime that you trust (like the Erlang VM); it's a much more natural way of writing code. Single-threaded, event-driven callback spaghetti makes code harder to read, and inherently means more code. If someone took v8, added lightweight coroutines, and wrote a preemptive scheduler for it, I bet you could massively reduce the SLOC count for large node.js apps.
> It's not deceptive if you have a preemptively multitasking runtime that you trust That may be so, but since Javascript is inherently single threaded _and_ this is about javascript I agree with Cushman that it is indeed deceptive.
Is that in the language standard, or are you confusing details of implementations for the language's design?
Re: Fogus: Node.js should become its own language
#68Earlier quoted context omitted.
> It's not deceptive if you have a preemptively multitasking runtime that you trust That may be so, but since Javascript is inherently single threaded _and_ this is about javascript I agree with Cushman that it is indeed deceptive.
But we aren't talking about Javascript. It's about a theoretical replacement language. Also, the reason you care about the "synchronicity" in the first place is because your environment forces you to care! When it all Just Works (TM), you don't care whether it's "synchronous" or not. That's a deficiency in your language, not a feature. I'm not theorizing. I program in this sort of language all the time. You worry muc…
Apparently the plan is to implement this "theoretical replacement language" in javascript using node.js
Re: Fogus: Node.js should become its own language
#69Earlier quoted context omitted.
> It's not deceptive if you have a preemptively multitasking runtime that you trust That may be so, but since Javascript is inherently single threaded _and_ this is about javascript I agree with Cushman that it is indeed deceptive.
> That may be so, but since Javascript is inherently single threaded Is that in the language standard, or are you confusing details of implementations for the language's design?
Re: Fogus: Node.js should become its own language
#70Don't get me wrong, this could end up being the best thing since sliced bread, but the advantage of closures is that a higher-order approach can work wonders. Just take a look at async.js. For me, more interesting than a pure assault on callbacks would be to see if you could handle more asynchronous scenarios, using async.js as a baseline. e.g. callback waterfall, callback when all children are finished, callback whe…
What's so hard about this to get a sequential execution of functions/blocks, error'ing out on the first error:
async.waterfall(
[ function (callback) {
// do thing 1
callback();
}
, function (callback) {
// do thing 2
callback();
}
, function (callback) {
// do thing 3
callback();
}
]
, function (error) {
if (error) {
// ohnoes errors
}
// all done!
}
);