Slashdot Mirror
JavaScript Creator Talks About the Future
mikejuk writes "JavaScript is currently an important language — possibly the most important of all the languages at this point in time. So an impromptu talk at JSConf given by the creator of JavaScript, Brendan Eich, is not something to ignore. He seems to be a worried about the way committees define languages and wants ordinary JavaScript programmers to get involved."
While the JavaScript language, development environments and implementations are absolutely terrible, as I see you're well aware, those are not the worst parts of it all. By far, the community is the most atrocious thing related to JavaScript. The people are generally nice enough, but my gosh, are they ever ignorant when it comes to computing.
JavaScript tends to drive away everyone who is even remotely a good programmer, as such people can usually see just how flawed JavaScript is, and they want nothing to do with it. So what we have left over is a bunch of non-skilled "programmers" who think they know what they're talking about, but in reality have absolutely no clue. They continually produce some of the shittiest code that has ever been written.
The scariest part is how they want to start getting involved with server-side development. This was typically one area of web development were good developers could use good technologies to get the job done well. But now the JavaScript community has put together very half-assed Erlang clones like Node.js, and have been hyping them as viable server-side technologies (when they clearly aren't). This is going to be a huge disaster, caused solely by the ignorance of the JavaScript community, and those who are foolish enough to hire such people to develop software.
""+" doesn't append _two numbers_, but it can append _number to string_ - which you can have in any language with operator overloading."
function foo(x,y) { return x + y; }
foo("5",6) == "56"
In every other language I've seen, the CORRECTly expected result is 11 or error. Perl, C++, etc. The point is that you can never trust your input if you are expecting numeric.
You must guard the inputs with explicit (and thus inefficient/unreadable casts). If you're using a 3rd party library, you'll be pulling you hair out trying to figure out what went wrong.
The language is full of such wtf's. While you can happily redefine most core operations (e.g. how jQuery fixes IE), you can't overload the + operator. Call my cynical, but I don't like languages that let you corrupt basic building blocks.
That being said, javascript is excellent at what it was designed for - and passable for what it's currently used for, but I fear for the future if it's the basis of future industrial strength applications.
One place I WOULD like to see it extended is DB's.. CouchDB has a very nice java-script based map-reduce framework - it leads to concise and expressive code (that's really NASTY if plsql, etc are used).
Basically javascript is excellent fragment-code. But HORRIBLE for modular libraries - having to write an entire library (like jquery) in a scoped wrapper then assigned to a mutable/corruptable symbol is sick. (Especially since library A will mutate library B without permission - hello 1970s!!)
-Michael
The C++ standards committee has been lost in template la-la land for the last decade. They've focused on features understood by few and used correctly in production code by fewer. Since the discovery that the C++ template system could be abused as a term-rewriting system to perform arbitrary computations at run-time, that concept has received far too much attention. It's an ugly way to program, but it's "l33t". On the other hand, they've been unable to fix any of the fundamental safety problems in the language. C++ is unique among mainstream languages in providing hiding ("abstraction") without memory safety. (C has neither, Simula, Pascal, Ada, Java, Delphi, Erlang, Haskell, Go, and all the "scripting languages" have both.) So there's an example of a committee screwing up.
On the Python side, we have von Rossum. The problem there is that he likes features that are easy to implement in his CPython implementation, which is a naive interpreter, even if they inhibit most attempts at optimization. As a result, Python isn't much faster than it was a decade ago, and is still about 60x slower than C. Attempts to speed it up have either failed or resulted in insanely complex, yet still sluggish, implementations. So that's the "guru" approach.