10 ms·

>Oh, what, you thought == was for comparison? Wrong. Actually true. And truer to the dynamic spirit of Javascript than ===. Sometimes things don't have to be a

>Oh, what, you thought == was for comparison? Wrong. Actually true. And truer to the dynamic spirit of Javascript than ===. Sometimes things don't have to be absolutely equal to be equal, "1" and 1 will do just fine. You can sanitise at another level. >Oh, you didn't wrap your all your code in an anonymous, self-calling function? You lose. You loose nothing. You merely expose some names to the global namespace. Which might just be just one name, anyway, sans the anonymous self-calling function. (e.g window.ns = {}, ns.doSomething = function() ... >Oh, what you thought it was okay to leave off semicolons and var statements because they aren't required? Sorry. Sorry for nothing much. A lot of people leave them off with no problem at all. The few edge cases are not unlike any other language's edge cases. >Hmm, you didn't know how to manage dependencies between scripts? Should have studied harder. Or not. If you got the result you want. >You tried to iterate over an array? Ridiculous. You probably mean the "for i in" idiom. Which is perfectly fine over an array. The only problem arises if someone has extended the Array prototype, which you shouldn't do anyway. And even that can be bypassed with one extra hasOwnProperty check. Not to mention it's solved in ES6. >Your brain exploded when trying to write a series of asynchronous functions in continuation style? A pity, really. Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs.

davedx 14y ago
> Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs. If async programming in JavaScript "isn't supported by the language": what good is it, then?
- pretoriusB 14y ago
  Who said Javascript is good for async programming? It was designed to be easy to use with callbacks for website UI style events (which is not quite the same as async programming). The Node async is just a half-thought implementation of async on top of a VM that doesn't really support it. The thing it has going for it is traction (and some people new to async are amused by the callback style and find it "challenging", whatever). Scala/Dart/Go/Rust/Haskell/etc have a better async story. ES6 will add some promising stuff in the future (no pun intended).
- ufo 14y ago
  The basic idea of having a framework full of nonblocking async calls for stuff and using simple cooperative threading is a reasonable design decision depending on what you want to do. The problem is that Node forces you to write code in continuation passing style and that is a very "low level" way to write things, missing many of the niceties languages tend to have right now. * If you want an async value you need to give it a name and put it in a callback argument. Instead of `f() + g()` you end up doing `f(function(a){ g(function(b){ ballback(a+b) } ) })` * You need to explicitly tell the order of execution of everything (as shown in the previous example) * It can very laborious to refactor a non-CPS subroutine if part of it needs to become async, specially if you have many loops or call other subroutines. Ideally you shouldn't have to do large "boilerplate" rewrites of your code just because of a small local change. If you are curious what the better alternative for to CPS style is, my opinion is that the way to have the language do the work of breaking the code into the callbacks for you, either via dialects that compile to JS or via features such as generators. While you can get away with many of the very nice async programming libraries out there, they still can't solve all the problems with CPS style (specially the refactoring one)

davedx 14y ago

> Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs. If async programming in JavaScript "isn't supported by the language": what good is it, then?

pretoriusB 14y ago
Who said Javascript is good for async programming? It was designed to be easy to use with callbacks for website UI style events (which is not quite the same as async programming). The Node async is just a half-thought implementation of async on top of a VM that doesn't really support it. The thing it has going for it is traction (and some people new to async are amused by the callback style and find it "challenging", whatever). Scala/Dart/Go/Rust/Haskell/etc have a better async story. ES6 will add some promising stuff in the future (no pun intended).
ufo 14y ago
The basic idea of having a framework full of nonblocking async calls for stuff and using simple cooperative threading is a reasonable design decision depending on what you want to do. The problem is that Node forces you to write code in continuation passing style and that is a very "low level" way to write things, missing many of the niceties languages tend to have right now. * If you want an async value you need to give it a name and put it in a callback argument. Instead of `f() + g()` you end up doing `f(function(a){ g(function(b){ ballback(a+b) } ) })` * You need to explicitly tell the order of execution of everything (as shown in the previous example) * It can very laborious to refactor a non-CPS subroutine if part of it needs to become async, specially if you have many loops or call other subroutines. Ideally you shouldn't have to do large "boilerplate" rewrites of your code just because of a small local change. If you are curious what the better alternative for to CPS style is, my opinion is that the way to have the language do the work of breaking the code into the callbacks for you, either via dialects that compile to JS or via features such as generators. While you can get away with many of the very nice async programming libraries out there, they still can't solve all the problems with CPS style (specially the refactoring one)