JavaScript: The World's Most Misunderstood Programming Language Has Become Most Popular | Hacker News Reader

JavaScript: The World's Most Misunderstood Programming Language Has Become Most Popular

javascript.crockford.com

49 pointsinitself30 comments

It is a fortunate historical accident that Eich was infatuated with ultra-dynamic languages like Scheme and Self when he came up with JS. For all its flaws, JS retains enough of their DNA to have given rise to the wonderful world of web apps and, effectively, take over the world. When you consider how many historical accidents went against this style, I think we're lucky to have JS. And it does seem to have been an accident, given how hard Eich has been trying to turn it in to something else (for "serious" programming don't you know).

p.s. I've written this here before, but can't track down the link.

An interesting argument.

I suspect that js is not yet the world's most popular language but by this link's argument, it may become one of the world's most popular languages.

However, as ajax evolves, js may become more of a "virtual machine" into which the initial UI source code is compiled rather than being the raw language in which the UI specified.

Javascript will be the new basic. I would tell any high school student to pick up javascript over any other language. They can graduate to something else later (bonus: javascipt is not a crippling first language unlike basic).

I'm not sure if javascript will become a big target language. The only framework that I know of that compiles into javascript is GWT and I don't think that it is receiving widespread use.

Maybe not, but who wants to write Java?

Parenscript is another language that compiles to JavaScript, and although it's very simple, I think most web apps written in CL use it. So it might not be popular overall, but it is popular among its target market.

Now if only I could have a cxml-stp style DOM in Javascript...

although it's very simple

Parenscript's simplicity is by design and is one of the best things about it. It makes it easy to read and debug the generated JS, and allows for efficiency while still adding a ton of abstractive power.

Now if only I could have a cxml-stp style DOM in Javascript

I don't know what that is. I googled it, and still don't know what it is. Could you give a brief description and an example or two of why you like it?

cxml-stp is http://www.lichteblau.com/cxml-stp/.

Basically, it's the W3C DOM, but Lisp-like. As an example, CL has a function called "find-if". It visits every element in a sequence, and returns a new sequence containing the elements that match the supplied predicate function. (Think "grep" in Perl.) The DOM doesn't have anything like this, but STP does -- find-child-if and find-recursively-if. That means you can write something expressive like (find-recursively-if (of-name "p") document) to get all the <p> nodes in the document, rather than writing the traversal code manually.

I have used DOM in a variety of languages, and it only feels natural in Java. No other language is crippled the way Java is, so it doesn't make much sense to use the W3C standard, unless you just want to port existing DOM code form one language to another. (Standards are good for legacy code, but not so good for new code.)

I want to say something about leaky abstractions and caution the reader that writing code that you then pass to something that generates some other code is a very very scary thing by and large. The Java compiler and gcc are really mature, and every so often bugs are still spotted. Imagine if you're super-awesome-Objective-C-to-Javascript compiler has a bug. How do you know if the bug is in your Objective-C code, in the compiler, or just a weird browser oddity? Basically you end up kind of needing to know everything between you and the browser, so it may be a good idea to minimize those things.

(Actually, I recommend sitting down and writing Javascript without a library, just so you have an idea of what works and what doesn't across browser. It was somewhat surprising for me to be sure.)

While I agree that JS probably can't be treated like a machine language and just ignored, my project has gotten huge value out of the generated-JS approach.

I see from another comment that you've used GWT. This may be why our experience differs. Java and Javascript are so far apart (ironic given their names) that to generate one from the other is inevitably going to be complex. We use Parenscript, and the semantics of Lisp and JS are much closer. As a result, I've been consistently surprised by how suitable JS has proven as a target language and how simple the whole approach is.

We've even extended Parenscript into a pretty expressive subset of Common Lisp compiling efficiently to Javascript. We never set out to do this - it just spontaneously evolved - and it's a small subset, nowhere near all of CL. But it covers enough that we can write large portions of our app to run both on the server and in the client, which turns out to be valuable sometimes.

That being said, we pay close attention to the generated Javascript, so I agree with your suspicion of X-to-JS compilers in that sense. What we do is a semi-abstraction.

To be sure, the closer the two languages are, the less impedance mismatch there is.

But no matter what, you brush up against the fact that when the languages are just plain different, you have to be careful. And if you know Javascript is different from Language X, and can debug the difference, why are you writing Language X and not Javascript?

Honestly, most of what Lisp does that makes it unique (first class functions that aren't ugly, macros), are either availabe (first class functions), or something that the compiler can take care of for you, so it seems that Lisp is actually a scarily-good-fit for language to compile to JS. (Assuming no encountered bugs that is ;))

Yes, that's right. And the macros go a long way.

Actually, there is one big impedance mismatch: null. The semantics of Lisp and JS around null-zero-false are incompatible, and it leads to annoying bugs. I'm still looking for a good solution to that problem. The other big thing is that JS uses returns everywhere and Lisp doesn't. It might be possible to have the compiler add those in in the right places, but we haven't tried that yet.

(Actually, I just realized, JS has == semantics that are... kind of crazy. Do you write equals calls as a call to an equal method or just kind of keep it in mind?)

The latter. And you're right, those == and === semantics are kind of crazy. But I think of that issue as more or less the same as the null-undefined-false-0 issue.

Also, to answer your question:

And if you know Javascript is different from Language X, and can debug the difference, why are you writing Language X and not Javascript?

... the answer, when X is Lisp, is that the benefit of the additional abstractive power is much greater than the cost of the impedance mismatch. Both sides of that equation would vary greatly depending on X, which is just a way of repeating what we've already discussed :)

> I want to say something about leaky abstractions and caution the reader that writing code that you then pass to something that generates some other code is a very very scary thing by and large.

You are aware that programmers have been doing this in essence since Assembly Language was invented right? Programming directly in binary is just too much for our human minds to take.

That said, you are much more correct than you realize. Even programming a "simple" or "direct" translation, like compiling from C to object code is rife with pitfalls...

http://cm.bell-labs.com/who/ken/trust.html

Well, yes, hence my explicit mention of GCC and the java compiler. :)

In general, as long as the compiler is bug free, you should be fine. Its just that never running into a compiler bug is much less likely when you're using very new code. Code is often buggy after all ;)

JavaScript is not only "not too bad", it is actually great. I wonder if it is even cooler than Lisp, because those hashes that are objects and arrays and everything are so versatile. Sure it would be fairly easy to create a JS style object system in Lisp, but I think it isn't there from the start (only know Scheme, a bit).

js itself isn't so important.

already the desktop UI approach (think Java AWT/Swing) is gaining traction, eg GWT.

nonetheless, if using js directly, the js itself isn't so important: * use a good js library with helpful abstractions for DOM traversal, manipulation, etc * use good js frameworks, eg for compiling data plus templates into html * use ajax to get html

Do you actually know anyone who uses GWT? I have not heard good things about it. I personally would rather ues plain javascript with jquery.

I actually use GWT, and my advice is to be very careful.

I've managed to have bugs that show up in the browser that I have had an amazingly difficult time tracking down. You get a pile of javascript from your pile of java, and it can be hard to tell where the bug is at all.

Complexity is dangerous, and GWT is fantastically complicated. I haven't run into a GWT compilation bug, but I'm sure there exists such a thing, and the day I run into it I will simply sit down and cry because I have no other recourse.

(But when it works, I guess its kind of a nice way to build UIs, if you like Java-style UI APIs... I've never met such a person, but I'm sure they exist ;))

Kdice.com, a game much like Risk, was done with GWT by one guy, and he wrote a book on GWT.

FYI: Douglas Crockford is a contributor to Yahoo UI Theater. His lectures on js can be found there.

http://developer.yahoo.com/yui/theater/

It doesn't have anything to do with Java. They just added that to increase the Netscape stock ticker.

One should read this instead (from the same domain):

http://javascript.crockford.com/javascript.htm

Since when did javascript become a "language"? Is it even Turing complete? I thought the word "script" meant "scripting language" which is NOT the same thing as a full fledged language. If indeed javascript is the most popular "language" then God or Turing help us all.

of course it's turing complete. the bar for that is very low.

Indeed, you only need one instruction to be turing complete. Subtract and branch if negative is turing complete: http://en.wikipedia.org/wiki/One_instruction_set_computer.

"... Since when did javascript become a "language"? Is it even Turing complete? ..."

You're right.

What self respecting Startup would bother with such an obviously deficient language? It's just not up to the job. Just keep using your Turing complete C/C++, Java (or insert your own favourite Turing complete language) and everything will be alright.

The perfect troll is the one where you're laughing so hard that you can't decide whether to ignore it, rebut it, downmod it, congratulate the author for writing something so perfectly ironic, or preserve it in a zoo so that future generations will know that such things once walked the earth.

LOL, I suppose Lisp is not Turing complete either. JavaScript happens to be one of the most elegant languages (sans the DOM and browser stuff that is tightly coupled with the language)

You use the word elegant like it's an objective statement, which it is not.

I would disagree about it being elegant. It's a fine language, but it has no unifying concept. It's procedural, it has anonymous functions, it has simple OO built-in. This isn't really elegance because you can't go anywhere uncharted with this. The simplicity is there because there isn't much built-in. Code is not data. There is no module system. There is no generalized flow control. (I am not sure why language designers like manually implementing function calls / return, exceptions, loop/break/continue, etc. when continuations generalize all of this.)

Anyway, JavaScript is useful, but it is a limited subset of nearly every other language. This may be good, but where features are missing, everyone has their own incompatible "fix" for that. That may or may not be elegance; I'm not sure.

Javascript is good enough for your blog.

Reply on news.ycombinator.com