Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
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 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?!

      • 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