You assume that he likes what he created.

In this rant he didn't say Node.js was the solution, or better than any of these crappy abstractions.

Don't assume that. He might not say he doesn't like node.js, but it doesn't mean he is happy with it.

I don't assume that he likes what he created. My point is: if he thinks things are these way why didn't he try to create a framework that did things simpler? The research on concurrency has plenty of options that are easier to read and reason about than callback-based code.

Good point he never even mentions node.js. ;)

But I do feel that node.js is Rayn's attempt to enlighten me and hopeful others. He doesn't try to hide everything like ports and the underlying c code. Its all there, and best of all in a language that is familiar(at least for web developers).

Interestingly, part of the reason Node.js used JS was that JS didn't have a ready-made standard library so it made a clean break from a lot of the styles of the past. Node was an opportunity to force a community to rethink a lot of things.

In what way did it accomplish this? The style Node has chosen for modeling concurrency is decades old. Twisted has been using it since the late 90's. So JS doesn't have a standard library? Who cares? You still have to write one for your event-loop, which is what you had to do in Twisted. I don't see any rethinking going on, I see steps backwards.

>So JS doesn't have a standard library? Who cares?

If you want people to get the performance benefits from using non-blocking libraries, you care.

Why? You have This write a new standard library no matter what language you choose. Js not having a stdlib doesn't save you work.

If you have established blocking standard libraries people are less likely to write/contribute to non-blocking ones.

Your claim that JavaScript is "notoriously difficult to write quality software in" is unsubstantiated. Which language in your opinion makes it easy to write quality software in?

People only like JavaScript because they know it. Yes, it's more productive than Java because it's (barely) functional, but I personally believe the renewed love for JavaScript is mostly Stockholm Syndrome.

I wonder if JavaScript is mainly loved for its frameworks and libraries? Without jQuery, node.js, etc., how many people would be singing its praise?

I believe since Java 6 (possibly 5), the JDK has come bundled with a minimal installation of Rhino which runs JS on the JVM. How many people actively use that? It's not hard to get going, 5 or less lines of code to start running a JS file and it will run everywhere with JRE >6.

But there's no jQuery, etc. It's a somewhat nicer way to work with Java since you aren't forced into I-don't-care-about-it-exception-catching hell and Map<Map<Map<...>>> madness, but compared to Jython or Clojure it doesn't match up. You can get a headless jQuery working with Rhino, though it's not as simple as it should be.

Rhino is really slow when compared to V8, like Ruby slow.

Rhino is slow, but it's freaking awesome if you need to write an algorithm that can run in the browser and on the server. Much much much nicer than having to maintain two implementations in two different languages.

Part of JS's popularity is definitely politics... the fact it's in the browser gives it a huge shot in the arm.

It's a decent language, though. Here's a comparison of JS to Ruby for some of the stuff people generally love Ruby for. JS comes out looking pretty decent.

http://fingernailsinoatmeal.com/post/292301859/metaprogrammi...

To quote Douglas Crockford on JavaScript, "Lisp in C's Clothing"

Before I learned a Lisp, I agreed with that statement. Now, I think nothing could be further from the truth.

Indeed. Lisp is a simple language that can be completely defined in half a page. A naive implementation takes less than a thousand lines of code. The language is homoiconic, i.e, there's no difference between programs and data -- everything is a list. This enables programmers to perform complex transformations on code using macros. Lisp compilers such as SBCL generate code that is almost as fast as C++. Oh, and the original Lisp as described by McCarthy is strictly rooted in mathematics. If you limit yourself to writing only a subset of Common Lisp/Scheme -- one that emphasizes immutability and recursive functions on lists of symbols -- it is possible to use formal methods to prove the correctness of your code.

None of that is true for JS. I don't think Crockford thought his remark through.

As a lisp (Scheme and Clojure) user who nonetheless takes issue with this statement:

1. Modern (JS) runtimes have JITs that can generate code almost as fast as C++.

2. You can write purely functional code in JS.

3. JS has arguably less features than R5RS Scheme, which itself is hard to fit on half a page.

What do you mean by point 2? Unless you don't plan on doing any I/O, you can't write purely functional code in JS. Not that you can in Lisp either...

I meant that there is nothing about JS that prohibits writing pure functions and reaping all the associated benefits (formal reasoning, etc.)

If it ain't got macros, then it ain't a Lisp. Javascript is definitely no Lisp, but I really like that it allows function composition, which is somehow reminiscent of a Lisp. f(g(h(x))); instead of (f (g (h x)))

Um, pretty much every C-derived language supports function composition, and uses that syntax for it. Am I missing something?

You're right. I meant to say passing first-class functions as arguments, rather than pointers to functions as you would in C or an object method as you would in Java.

I agree. I think this "JS is Lisp" nonsense is a pretty little platitude that many developers use simply because they don't know any better.

Crockford goes on to clarify that Javascript is really a combination of Java syntax, Self inheritance, and Scheme-like lexical scoping.

By the definition given in the article (just solve the user's problem, don't build a tower of abstractions): Forth.

JS is known for being a language with a lot of "WTFs" in it. Yes, you can write bad code in any languages and you can even write great code in JS. But to quote Fogus: "My problem with Javascript has always been that expertise is defined more in terms of understanding its faults rather than its features"