Brendan Eich Discusses the Future of JavaScript

snydeq writes "JavaScript creator Brendan Eich talks at length about the future of JavaScript, ARAX, disputes with Microsoft, and the Screaming Monkey scripting engine for IE in an interview with InfoWorld's Paul Krill. JavaScript 2, which Mozilla's Eich expects to be available in some form by the end of the year, will 'address programming in the large.' To do that, Eich hopes to improve the integrity of the language without sacrificing flexibility and making JavaScript 'painfully static in a fixed way like Java does.' Eich does not expect Firefox support for JavaScript 2 until at least Version 3.1 of the browser. As for Internet Explorer, Eich explains how Screaming Monkey will help bring JavaScript 2 to IE should Microsoft drag its heels on providing meaningful support."

Really?

[Goaway]

We can't expect support for Javascript 2 in Firefox until the next version? But I want it to magically appear in the current one!

Javascripts popularity is no real suprise

[pembo13]

VBScript sucks balls and Javascript is capable of getting the job done.

Re:Javascripts popularity is no real suprise

[vivin]

Javascript has the potential to be really useful. Well, it already is. I was at JavaONE earlier this year and I went to a few Javascript sessions. One of the most eye-opening sessions was the one where the presenter described Javascript as a LISP-1 language that just happens to look like C.

As far as improvement, I think it needs a proper object oriented model (the current one is far too confusing), and also should be friendlier to implementations that require recursion. You can write recursive code in Javascript now, but it's very slow. Iterative solutions are faster.

Re:Insightful

[Red Flayer]

Don't worry about it. Troll, (s)he is... better ask Surak. Or one of the other sockpuppets.

Re:faster math for RSA

[Anonymous Coward]

unless someone disables SSL ... or uses a browser that cannot do it ... I'll stick with rot13

Re:My $0.02 worth

[famebait]

Are you sure you know the difference between the language and the proprietarty APIs the browsers expose to it?

Re:Google Web Toolkit?

[famebait]

No, that was the long of it.
This is the short:

Generated code is evil.

Now for the medium:

Code generation tends to look like it will save you time, but it usually only does so for the first five minutes, then it starts costing.

A code generator is in fact a compiler (or a compiler is a code generator, if you will), and should be specced a such. That means:

1) Unless the compiled code runs as reliably as that from established 'proper' compilers, it really is worse than useless. This is impossible unless your architecture and OS is fixed and known at compile time. For Java and similar, the VM is the architecture and the standard libraries are the OS. For javascript the architecture is the interpreter, but the OS includes is the browser's API.

2) When things go wrong, you need to be able to track directly back to the source to develop efficiently. Java and pals retain enough in in the bytecode to do this well, and in C ou compile with debug symbols. Most code generators to Java and javascript dop nothing in this area, and cannot be debugged efficiently.

Re:The Point: OO != Classes & imp. inheritance

[weston]

instead exposing the virtual method table directly. (Prototype is nothing else)

Not precisely, since the prototype property also exposes properties, as well as methods. Or, more precisely, methods are properties in javascript, since functions are first-class.

You cannot really design big systems without those two constructs

Not at all true. Well, it's tautologically true. You can't design big systems the way that most programmers who currently work on big systems design them in statically-typed explicitly class-based languages. And by some accounts, this turns out to be a huge advantage, because you get a LoC compression similar to what you'd see with Ruby.

(As for namespaces -- PHP has the same problem, but worse, given that you can't even appropriate static ad-hoc classes as a namespace mechanism. And yet the namespace problem has been more or less practically addressed by conventions, and you can't argue anymore that people aren't building large systems in it.)

different incompatible inheritance constructs by third party libraries

It's true composing "extends" implementation inheritance implementations across libraries is likely to get you in trouble. But then again, simply using implementation inheritance can get you in trouble, in C++, in Java. And having to settle on conventions and libraries is not a fatal hit to a project.

In the end javascript is the classical example of a 95% academic language.

Acadmic? Why? Because it's functional, or didn't start life with "extends"?

Javascript's shown itself as quite practical contender in a huge amount of the heavy lifting that's gone on in the RIA space over the last 5 years, and that's not half what's going to happen as it gets traction elsewhere [blogspot.com].

Re:The Point: OO != Classes & imp. inheritance

[MemoryDragon]

Actually speaking of php and big systems, I did some heavy typo 3 programming, and I saw the problems which were caused by the simple fact that there were no namespaces. Yes you could do a big system bug look at the mess the entire system (in this case typo3) was in... It took years almost a decade to get typo3 where it is now, and it is still a mess. Calling php as the classical example of namespaces are not helping in designing big systems is like a joke. In the end you even can design big systems even in hex code but that does not mean you should target them with such languages! The same goes for javascript, therefore I am happy that the newer efforts towards standardizing next versions of javascript try to tackle it. Btw. as for rails, it works because the basic structures are outlined by the codegens rails has, the programmer is basically pushed on rails :-) Which means rails enforces certain structures to bypass certain limitations of the underlying language!

Re:Javascripts popularity is no real suprise

[Haeleth]

If you delve deeper into LISP you will see that calling a language without tail recursion and macros LISP-like is an exaggeration ...

Congratulations: you have come up with a definition of "LISP-like" that excludes both McCarthy's original LISP and ANSI Common Lisp. You must be proud.