Comments on only rainwater and pure grain alcohol: Why I don't like JavaScript 2

PS (from blogtest)...I don't do it because I like ...

2008-08-13T11:16:00.000-07:00

PS (from blogtest)...

I don't do it because I like it, I do it because I know how!

Valuable comments all.Differentiation between lang...

2008-08-13T11:10:00.000-07:00

Valuable comments all.

Differentiation between languages is not only a factor of technology moving on, they're also a consequence of the set of problems you're interested in solving. So, you can regard that Fortran, Cobol, C list as a time-line, but I regard it as a family of different solutions to different problem-spaces, today there is still an argument that certain numerical applications are best written in Fortran because, for its age and faults, this is just the kind of engineering problem the language was designed to assist. Certain types of time-critical device driver are still better written in Assembly language. SO often a new kid on the block isn't always absolutely better than the old kids, it's just geared towards a specific trend of development problems that may not have existed before. The old problems, e.g. systems development problems, don't go away and languages for such problems are still useful.

It's too obvious to be worth a mention that the ideal language hasn't been invented, and just probably doesn't exist. The scope of the kind of instruction automated devices may be called to execute, be they web browsers, digital-watches, operating systems or robots tells not only there may never be a one-size fits all human-machine linguistic solution but that it's almost certainly best for us that there isn't, just like there is never likely to be a widely accepted costume that is equally comfortable in bed, outdoors, in rain or at a wedding.

The biggest problem we're faced with since the internet went boom is that so much hope, hype and revenue is dropped on whatever the-next-big-thing-in-IT is that everybody wants to be in on the act as it goes up. Now we're moving away from hardware based development to a more abstract software-platform / browser environment platform everybody wants to make themselves internet friendly and claim they know what the next-big-thing will be, often by trying to make oneself responsible for inventing it or at least be seen to be current-big-thing tool users because it looks flash on your resume.

Python is a truly excellent language. As are Lisp, Smalltalk, Forth and... well that's about the end of the list come to think of it ;)

Most people will tend to recommend whatever it is they themselves are doing is the current big thing, largely because that is where they themselves find comfort and enjoyment for a plethora of possible reasons, none of them being that they have found the solution that works for us all.

Personally I don't like programming. As a task, writing is pretty boring for me in any language.

We already have a pretty good, time tested, cross-...

2008-07-07T17:23:00.000-07:00

We already have a pretty good, time tested, cross-platform, vector graphics API. It's called OpenGL. The OpenGL immediate mode renderer to be exact. We can toss in Open Scenegraph if you want a high-level non-procedural API, OpenAL for audio, and OpenCL for computation.

If Google Gears exposed these APIs to Javascript (like Android does with embedded GL), you could build SVG/VML/Flash/Silverlight/JavaFX in the JavaScript.

I also agree with Dan, a bytecode VM is better than Javascript, and using bytecode does not preclude debuggability nor source-reversal. This totally depends on the byte-code design, for example, an AST-based code would provide almost exact reversal.

Javascript cannot be the universal byte-code intermediate, it lacks many features that other languages would want in the VM. For example, non-double numeric types, real 32-bit integers and 64-bit longs, which are important for many applications you'd want to write in the browser.

These language wars always come down to people posing false dichotomies. Static languages are always verbose, dynamic languages are always slow, you can't debug bytecode, you can't interactively develop with static languages (e.g. no REPL), and so on.

Javascript is a powerful or interesting language, if all you've ever used was C or Java, but if you're been using other dynamic scripting languages, Self, Smalltalk, Ruby, or other statically typed languages like ML-derivatives, Haskell/Clean, Scala, etc then it's not particulary exciting. It's just another syntax for feature's you've already been using.

I think Dan is spot on. What should be standardized is the browser's native APIs: DOM, CSS, Events, I/O, graphics, audio. The actual syntax of the code that leverages these APIs is irrelevent.

"I don't think JavaScript can do anything that Pyt...

2008-07-07T15:49:00.000-07:00

"I don't think JavaScript can do anything that Python couldn't do"

And, technically speaking, there's nothing Python can do you can't do in asm, or with a Turing machine. It may just take a lot more effort. Python and JavaScript have similar levels of power, though, so it's true there's not much one can do that the other can't. However, that's hardly shabby, and once you add in the fact that it's a ubiquitous platform it's incredibly compelling. I know that's kind of your gripe, but my guess would be you've never really used JavaScript. Think of it as Lisp with C syntax, perhaps.

I am of a similar opinion, but I take it to the ne...

2008-07-07T11:57:00.000-07:00

I am of a similar opinion, but I take it to the next level in this case. You are asking for a standard vector/drawing API. There are so many different native APIs just like there are so many different programming languages. And time has shown that we can't all agree on a single one. So why should the web have a single standard vector/drawing API? And why should our apps run inside the browser?!!

In my opinion, we only need a standard format to exchange data. The apps itself can be native. Why re-invent the OS in a browser? The following are two possible reasons:

If the aim is to have a write-once-run-everywhere environment, why not standardize the OS? Obviously that is not going to happen, just like we can't agree on a single programming language or drawing API. Companies make native apps for multiple platforms (with or without multi-platform toolkits). Also, web apps need to take care of multiple versions of browsers and their differences. There will always be differences.

If the aim is to be able to access your data from any computer, it still does not explain why the app has to run inside the browser. We could instead allow the browser to download native apps and run them inside a sandbox. Also, as smartphones become more popular, people will have their own "computer" (the smartphone) with them all the time and all they will need is connectivity to their data (in case all their data is not on their smartphone).

@timothy I guess it's not that I don't think JavaS...

2008-07-07T10:30:00.000-07:00

@timothy I guess it's not that I don't think JavaScript is powerful in the absolute; it's that I don't think it's particularly powerful in the relative. For instance, I don't think JavaScript can do anything that Python couldn't do.

It's a perfectly serviceable language, it's just not one that lights my fire. I already know which languages do, and I'd rather use those in the browser than have to learn a new one which still may or may not light my fire.

@kris_zip Indeed, JS is a sort of de-facto bytecod...

2008-07-07T10:29:00.000-07:00

@kris_zip Indeed, JS is a sort of de-facto bytecode, and so from that perspective my goals are met, JS2 is a no-op, and we can move on to enhance the browser in other ways like Gears or HTML.

However from talking to the GWT team, I know there are at least a few tweaks to JS that would be helpful to GWT in its goal of writing faster code. If those could be standardized, then I think that would be a net plus.

It's interesting that you don't like JS and don't ...

2008-07-07T09:08:00.000-07:00

It's interesting that you don't like JS and don't think it's powerful.

I've been programming in all kinds of languages for 30 years and JavaScript is my favorite language--the most exciting one for me in years and years.

Just goes to show you that yeah, people will never agree on languages.

Bytecode, in the traditional sense, (one-byte opco...

2008-07-07T08:19:00.000-07:00

Bytecode, in the traditional sense, (one-byte opcodes followed by parameters), is not a win for the web. It decreases readability/debuggability, is no more (probably less) compact than minified/gzipped JS, and JS parsing is a minimal cost.
However, I believe that in some sense, JS effectively _is_ the bytecode of the web. JS is the bytecode of GWT, Mascara, Caja, and many other projects that give programmers the option to program solely in another language. JS is a platform, not just a language. I believe that this use case is only going to continue to grow, and I agree with you that is important for continuing to give developers a choice of language. Evolving JS should be more focused on improving it's capabilities as a platform, instead ES4 has been more focused on language/programming in the large aspects like integrity.
However, there are certainly a number of features in ES4 that make it a much more capable platform as a target for the compilation of other languages (many of them coming in ES3.1), and so I think there is progress.