Here's a great quote from Douglas Crockford's "JavaScript: The Good Parts":
The worst features of a language aren't the features that are obviously dangerous or useless. Those are easily avoided. The worst features are the attractive nuisances, the features that are both useful and dangerous.
There very well could be a similar book for another language in the medium-term future. It may not include the railroad diagrams, however.
Re:JavaScript or Perl
Eric Wilhelm on 2008-09-13T05:53:34
You don't think the railroad diagrams totally make the book or what?
I actually just read that same quote the other night (because I skipped to "the bad parts" when I ran across some WTF parts having gotten somewhat bored with the explanation of the syntax parts.) But I have to disagree because I'm thinking that the worst part of the language is the lack of block scoping because it makes closures nearly useless without acrobatics (these acrobatics are the WTF part.)
My suggested solution would be to just remove all of the parts and replace them with a good language (pragmatists will take offense here, but I didn't say this was a pragmatic solution (and committees are what got us in this mess anyway.)) Javascript is neat and all, but why oh why?!
Re:JavaScript or Perl
chromatic on 2008-09-13T07:38:20
I hate reading, writing, and maintaining parsers (seriously, I hate them so much I almost refuse to fix bugs in them), and I find grammars easier to read than the railroad diagrams. Remember though that I have practical experience reading, writing, and maintaining parsers, and that I can already visualize language in terms of parsers, so I'm clearly not the target reader.
The argument pro JavaScript is two-fold: the most awful parts are the DOM implementations, and it's mostly ubiquitous in modern browsers. I hate web programming, so I can mostly avoid it, but apart from the broken scoping and the lack of include mechanisms, it's a workable language.
Re: machine code for the browser
Eric Wilhelm on 2008-09-13T17:53:40
Reading the JSLint section (I decided to just read the end and then go back for the good parts), it sounds like 80% of the human effort goes into working around problems in the language or the various runtimes, which loses expressiveness and requires humans to keep track of a lot of computer problems. Workable is, after all, work.
So, if everyone runs JSLint on their javascript anyway, why not just use a good language which can be compiled into this cross-browser machine code stuff?
Re: machine code for the browser
chromatic on 2008-09-13T19:21:43
So, if everyone runs JSLint on their javascript anyway, why not just use a good language which can be compiled into this cross-browser machine code stuff?
Fragmentation. For a different example, once you decide that C just doesn't work for a systems programming language in the late 20th century, you have a lot of choices.
Re:JavaScript or Perl
Aristotle on 2008-09-13T12:18:33
Perl, Javascript, Ruby and Python share almost the exact same expressiveness, and in a pinch I wouldn’t be unhappy about having to work in any of those. The order in which I listed them is my order of preference – yes, I like Javascript better than Ruby.
The absence of proper block scope is common to all of these languages except Perl, btw.
(Note that Ruby 1.9 will fix block scoping – but only for closures, not in general, thereby adding to its already large pile of non-composable one-off features. Even Perl is more regular.)
