22 comments

[ 2.9 ms ] story [ 51.9 ms ] thread
Reads like satire, but may be serious -- really can't tell.
(comment deleted)
Looks like he's serious. Basically, he recites all the things about Javascript he doesn't like and then claims that makes it not a "real" language. I'd point out the obvious logical failure, but he doesn't seem to be the type that would care.
(comment deleted)
Nobody on Hacker News really thinks compiling your high-level or VM-based language really provides any security, do they?
Nobody on Hacker News really thinks that it's not possible to compile javascript, do they?
You'd hope most of them realize they're already working with compiled Javascript.
Toy, schmoy. It's what we're stuck with. My biggest gripe is lack of a great js editor. (Please feel free to contradict me with examples.)
IDEA does a pretty decent job, including autocompletion, clickthrough, docs - even supposed to have debugging but only afaik with html files on a server running within the IDE (since that's not how I dev frontend code I can't vouch for the JS debugger - though I can say the remote debugging capabilities on a Java appserver make for nice Ajax debugging)
There are good editors (emacs has a pretty decent JSmode; IntelliJ has a pretty nice JS editor).

I just wish there were IDEs out there that allowed you to create projects solely as JS - complete with JSunit, build (run tests + compress) scripts, etc.

Don't miss the previos episodes of the opera. Why Java is a toy? Why C is a toy? Why assembler is a toy? Why software is a toy? Why computers are toys? Why steam engines are toys? Why stones are toys?
(comment deleted)
Boy on Boy, I don't know where to start, the obvious linkbait title, or reasons why javascript isn't a real language being the same as reasons you don't like javascript.

I want those few minutes of my life I spent reading this back.

Wait, what, is he serious? I mean, truly serious? This isn't some elaborate hoax, like MAVAV?

Class-based OO can offer the developer features such as static methods, abstract classes, interfaces, method overloading and operator overloading. None of these features can be offered by prototypal objects.

Okay, here's a suggestion for anyone who wants to write about OO: do some research first. When the programming paradigm is different, that means that you do things differently. Just because you don't do it the exact same way you're used to, i.e. declare a class and a method inside it with the "static" keyword, doesn't mean it's not there. Had he mentioned typing concerns in prototype-based OO languages, it would've been an interesting read. But this is just plain silly.

Oh, and by the way, I guess that any language that isn't a "true OO language" is a toy language, right?

I was trying to guess what MAVAV was, my first thought was McAfee AntiVirus AntiVirus (to protect you from accidental deletion of svchost, of course).
Sorry, what makes digitally signing plaintext code interpreted by a VM impossible while signing binary code running on a VM possible?
The only redeeming feature of that article is that there appear to be no ads, so at least in reading his drivel I didn't potentially earn him any money.
Interesting how much programmers care about the nuances of a language and don't bother to mention capabilities.

GWT's main purpose is not to convert JS to a proper language, but to provide a huge set of tools, like code generation for each browser, so you don't have to download code for WebKit if you're using IE, like you have to with jQuery. They probably chose Java to attract developers who are used to Java. Their Closure framework does the same things in JavaScript.

JavaScript is also tied to a platform, a very important one. This means there is a big developer community making lots of libraries for the language, proper or not proper OO be damned.

A bigger problem is the age, initial design criteria and currently limiting capabilities of the web.

This is what a rethought language looks like

http://blog.golang.org/2010/05/new-talk-and-tutorials.html

http://stanford-online.stanford.edu/courses/ee380/100428-ee3...

Go solves far more problems than ECMA attempts to solve. The difference between JavaScrpit and C#, ActionScript, Java are minor. The real criteria is what can be built, how quickly, and how many people can use what's built. JavaScript is a workable language there, no less capable than Java because of some OO nuance.

Go has the potential to make all these older languages look like toys, if you judge by it's capabilities instead of theoretical ideologies.

> JavaScript can’t be compiled

Both .net and java supposedly compile, but only to intermediate language. The actual byte code still gets compiled at runtime into actual machine language (with all the awesome jit magic). No difference.

> JavaScript has almost no type security

Type safety is illusion. Unless you can differentiate between int-feet from int-meters.

> JavaScript encourages abstraction layers

Ha, every abstraction layer is usless unless its between assembly and the layer I am comfortable with.

The poor guy embodies all that prevents us from marching forward: "I learned about classes, I don't want to learn anymore, everybody knows that the rest is crap anyway! Right?"

If you read this, know that prototype-base programing pioneered the HotSpot and a lot of the JIT in your classical language's VM.

Oh and by the way, if your classes aren't object, does that mean that your language fails to qualify as OO? Maybe your classical language isn't OO after all.