![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
elfsWow. I just can't imagine anything more idiotic than this: Why we are not coding [our app] in Node.js. The three reasons he gives are (1) we don't want to have to learn about multi-threaded programming, (2) the language specification isn't stable, and (3) We don't want to have to learn what a closure is.
I can respect 2. Node is not ready for prime-time. It's a great language, just as C is a great language. Amazon was (originally) written as C scripts on top of NCSA httpd. Craigslist was written in Perl on top of Apache. Facebook is written in PHP and Apache. Twitter is written in Ruby and Apache. Disqus in written in Python and Nginx. Someone is going to write a blockbuster deployment and it's going to be in Node.js, and that will probably happen long before Node.js 1.0 is released, and long before there's a community standard library mechanism, and long before the bulk of Node.js's plug-ins are compatible with the current release. But they'll still do it. If Moneyolo doesn't want to be that person, more power to 'em.
But Node.js isn't multi-threaded. It's the antithesis of multi-threaded: it's event driven. There are no threads anywhere to be found. If you want more performance from multiple cores, get yourself a server-based kernel and run one instance per core. This claim shows that Moneyolo rejected the language before they understood it. And if they don't understand what an event-driven system is, they should get out of the web development business. Web development is entirely event driven, from beginning to end, and synchronizing these events into a coherent interaction with the customer is critical.
But what bugs me most is #3. "We don't want to have to learn what a closure is."
Okay, idiots, pay attention: Perl, Python, and Ruby have closures. A closure is an anonymous function, returned as the result of a factory expression, which continues to have access to all of the variables that were available in the scope of the factory expression at the time of its instantiation, even after that scope has been torn down.
That's it. Closures, continuations (yielding), and currying are all mechanisms by which we make programming easier and more expressive. Complaining that you don't want to learn these things is a bit like saying that "Those fancy subroutine things are nifty, but our programmers already know GOTO, and we don't want to waste their time on some newfangled fad."
Closures have been around, theoretically, since 1975, and have been implemented in popular languanges since 1998. That's 13 years, hardly some new fad. They're an important part of the modern toolbox, and anyone who dismisses them out of hand is riding herd on a bunch of PHP monkeys who think Javascript's most important innovation is the rollover.
I can respect 2. Node is not ready for prime-time. It's a great language, just as C is a great language. Amazon was (originally) written as C scripts on top of NCSA httpd. Craigslist was written in Perl on top of Apache. Facebook is written in PHP and Apache. Twitter is written in Ruby and Apache. Disqus in written in Python and Nginx. Someone is going to write a blockbuster deployment and it's going to be in Node.js, and that will probably happen long before Node.js 1.0 is released, and long before there's a community standard library mechanism, and long before the bulk of Node.js's plug-ins are compatible with the current release. But they'll still do it. If Moneyolo doesn't want to be that person, more power to 'em.
But Node.js isn't multi-threaded. It's the antithesis of multi-threaded: it's event driven. There are no threads anywhere to be found. If you want more performance from multiple cores, get yourself a server-based kernel and run one instance per core. This claim shows that Moneyolo rejected the language before they understood it. And if they don't understand what an event-driven system is, they should get out of the web development business. Web development is entirely event driven, from beginning to end, and synchronizing these events into a coherent interaction with the customer is critical.
But what bugs me most is #3. "We don't want to have to learn what a closure is."
Okay, idiots, pay attention: Perl, Python, and Ruby have closures. A closure is an anonymous function, returned as the result of a factory expression, which continues to have access to all of the variables that were available in the scope of the factory expression at the time of its instantiation, even after that scope has been torn down.
That's it. Closures, continuations (yielding), and currying are all mechanisms by which we make programming easier and more expressive. Complaining that you don't want to learn these things is a bit like saying that "Those fancy subroutine things are nifty, but our programmers already know GOTO, and we don't want to waste their time on some newfangled fad."
Closures have been around, theoretically, since 1975, and have been implemented in popular languanges since 1998. That's 13 years, hardly some new fad. They're an important part of the modern toolbox, and anyone who dismisses them out of hand is riding herd on a bunch of PHP monkeys who think Javascript's most important innovation is the rollover.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-03-03 10:38 pm (UTC)no subject
Date: 2011-03-03 10:40 pm (UTC)no subject
Date: 2011-03-04 05:22 am (UTC)no subject
Date: 2011-03-05 07:53 am (UTC)no subject
Date: 2011-03-07 01:07 am (UTC)People who don't know what they're talking about can be so amusing. :)