Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

perrin (4270)

  (email not shown publicly)

Perrin is a contributor to various Perl-related projects like mod_perl, Template Toolkit, and Class::DBI. He is a frequent speaker at OSCON, YAPC, and ApacheCon, and a contributor to several perl-related books.

Journal of perrin (4270)

Friday September 12, 2008
03:15 PM

Is he talking about JavaScript or Perl?

[ #37428 ]
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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • There very well could be a similar book for another language in the medium-term future. It may not include the railroad diagrams, however.

    • 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 rem

      • 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.

        • 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?

          • 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.

      • 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 fe