21–30 of 79 posts
I prefer coffee-script. It also works in the browser. http://jashkenas.github.com/coffee-script/
Why 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.
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.
One of my favorite advantages of Node is in fact that it is based on javascript. When building my application I can share code between client/sever side (string formatting methods for example) and don't need to do any mental context switching when it comes to languages. I've developed in javascript for years and all that I have learned doesn't go out the window here, all I need to do is learn how to use a few libraries.
The "faults" of javascript are primarily inexperience with event looped architectures that use callbacks (people complaining about having to use callbacks and the spaghetti code messes they make), people remembering the past horrible browser implementations of it (where something would work/be fast in one browser and not another ... Internet Explorer I'm looking at you) and confusion over how prototypical languages work vs. standard OOP.
Callbacks aren't that bad and a few extra nesting levels shouldn't create chaos in your code. Since its based entirely off of one javascript implementation (V8) the cross browser stuff is gone. How it handles OOP is different, just watch these videos first and you'll be fine: http://www.yuiblog.com/blog/2007/01/24/video-crockford-tjpl/
As far as speed goes it gets huge benefits by being javascript. Every time the Google coding machine feels like making V8 a little faster, Node gets faster too.
Yes its different, no its not worse ... its better but takes some getting used to.
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…
I wonder about the word "abusing" here. Languages that have block-level lexical scoping (I hope I am using the correct word) sometimes implement block scoping by renaming the variables and hoisting them to the enclosing function, and they sometimes implement block scoping by creating a new closure just as we do by hand in JavaScript, and then hoisting the result.
For example, naïve implementations of Scheme give you a "let" macro that is expanded into the closure form you give above, and then an optimizing step comes along a little later and performs lambda hoisting for you. So this "abusing" we are doing is what the language would have done for us in certain implementations anyways!
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…
for (var i = 1; i Why 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.
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.
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.
I prefer coffee-script. It also works in the browser. http://jashkenas.github.com/coffee-script/
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.
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()
One could argue this is just syntax but I think this way beyond the kind of thing that comes to mind when somebody thinks of "syntactic sugar".
Why 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.
d = long_io_operation()
d.addCallback(callback)
d.addErrback(errback)
try:
result = yield long_io_operation()
callback(result)
except Exception, e:
errback(e)
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…
EDIT: http://pastebin.com/7BUXKVXT
Paste it into Racket and choose language R5RS.
(define-syntax for
(syntax-rules ()
((for ((var init) condition step) expr ...)
(let ((var init))
(let loop ()
(if condition
(begin
(begin expr ...)
step
(loop))))))))
(define (test-for)
(let ((v (make-vector 10)))
(for ((i 0) (I prefer coffee-script. It also works in the browser. http://jashkenas.github.com/coffee-script/