71–79 of 79 posts
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.
> 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?
Earlier quoted context omitted.
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?
Yes. Asynchronous style using callbacks has been done many, many, many times, and it really doesn't work very well. It does small things quickly, but have you noticed the number of complaints about how Node.js produces spaghetti code increasing lately, quietly and slowly but steadily? It's still buried under the hype, but expect it to get worse. And not "get worse before it gets better", just... get worse. I laid it…
Earlier quoted context omitted.
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.
It is not that simple in real life, unfortunately. Even ignoring the fact that inlineCallbacks's overhead is significant, inlineCallback forces you to serialize things which may be run in parallel. If you do 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…
inlineCallbacks allows you to write code in a synchronous manner (that's the point). If you'd like to wait for completion of both f1 and f2 functions simultaneously you could:
yield DeferredList([f1(), f2()])
Non trivial async code is hard to read (period).
Exceptions allows you deal with errors in the place where you know what to do with them, not in the place where they arise (as in any other Python code).
Earlier quoted context omitted.
The good news for fogus is that everyone who prefers CoffeeScript validates the idea that an alternative syntax is enough of a win to be worth the adoption headaches.
It's not just syntax, but some semantics too. Last expression in a function is returned. This includes assignment statements which are in fact expressions. foo = () -> a = bar() z = () -> if a b = fu() else b = kar() Here, foo returns the function z, and z returns either fu() or kar() while assigning the value to b One could argue this is just syntax but I think this way beyond the kind of thing that comes to mind wh…
foo = ->
a = bar()
z = ->
if a
b = fu()
else
b = kar()Earlier quoted context omitted.
Yes. Asynchronous style using callbacks has been done many, many, many times, and it really doesn't work very well. It does small things quickly, but have you noticed the number of complaints about how Node.js produces spaghetti code increasing lately, quietly and slowly but steadily? It's still buried under the hype, but expect it to get worse. And not "get worse before it gets better", just... get worse. I laid it…
what do you think of that erlang version of the V8 interpreter I posted about higher up? I do find the idea of using the erlang VM where it can do a lot of good to be very attractive. While I would probably prefer python running on Beam to Javascript, JS is very "lightweight" if you take my meaning a certain way, and quite ubiquituous even compared to Python. It would also seem to dissolve your specific complaints po…
You don't need a project like Beam.js to do that, but having someone else having already written the utility code can certainly be useful. Nothing like that existed for Perl but it hasn't been hard to do what I needed.
Earlier quoted context omitted.
It is not that simple in real life, unfortunately. Even ignoring the fact that inlineCallbacks's overhead is significant, inlineCallback forces you to serialize things which may be run in parallel. If you do 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…
In real life inlineCallbacks's overhead is not significant compared to typical IO times (even snail in a park reaches its destination sooner than a rocket makes it to Pluto and back). inlineCallbacks allows you to write code in a synchronous manner (that's the point). If you'd like to wait for completion of both f1 and f2 functions simultaneously you could: yield DeferredList([f1(), f2()]) The ticket you mentioned is…
Using deferred lists is a fair point, but then you are kind of back to using deferred directly.
As for tracebacks, I used the ticket as an example: if you have to use failure.printTraceback, it means you caught the exception, which means you need to catch them everywhere. But the problem is when there is a big in your application because you forget to handle an exception - debugging those is a PITA because you don't get the right traceback.
So yeah, async code is hard, inlineCallback sometimes helps, but all this really feel like a big kludge to me - I would rather use a framework where async is abstracted away. Doing all this by hand does not work very well for complex applications.
How about Node.as? Flash doesn't get much love these days but I've always thought ActionScript 3 would make a great server side language. It's more like other OOP languages, has an event model like JavaScript (sync or async), and doesn't have many of JS's idiosyncrasies. Edit: http://haxe.org/ is based on AS3
Earlier quoted context omitted.
Except that Javascript has lexical scope. Use the var keyword to define local variables. foo = function(){ var bar=0 return function(){ bar=bar+1 return bar } } baz=foo() baz() // => 1 baz() // => 2 baz() // => 3 bar; // => ERROR: bar is not defined
They're "hoisted" and only local to the function, though. I'd (personally) prefer it if it worked like C, and a variable was defined from the "var" statement until the next closing brace. Then you could have a variable local to one branch of an if statement, etc, without faking scopes by abusing closures (eg (function() { })(); ). And nested loops that both use "i" would work.
Earlier quoted context omitted.
That's because closures actually capture the variable, not the current value of it. They'd be a lot less useful if they just made a copy of the variables...
I'm sorry my original post wasn't very clear. My intended point was that if Javascript had true lexical scope then each iteration of the loop would create a distinct variable. A reference to that variable would then be captured by each closure. You can simulate the behavior of lexical scoping by "abusing" closures as someone mentioned before. Like this: for ( var i = 1; i < 10; ++i ) ( function( i ) { setTimeout( fun…
It would be the same variable with or without lexical scope (by that I mean block-level).