So I Don't Like Perl. Sue Me.

---

A number of folks commented on the last post about my "ignorant and apparently unsupported
swipes against Parrot and Perl". Responses:

1. I took exactly one swipe at Perl, and there was a smiley at the end of it. Apparently,
   based on the heavily-slanted pro-Perl/anti-Perl-bigotry comments I've received, Perl
   programmers don't understand smileys. So I will translate: "It means I am smiling
   as I say this, which is intended as a way of conveying light-heartedness or humor."
2. I didn't take any swipes at Parrot. I said, "Parrot may change that in time, but right
   now it sits at a 0.5 release and doesn't seem to be making huge inroads into reaching
   a 1.0 release that will be attractive to anyone outside of the "bleeding-edge" crowd."
   It is sitting at a 0.5 release (up from a 0.4 release at this time last year), and
   it doesn't seem to be making huge inroads into reaching a 1.0 release, which I have
   had several CxO types tell me is the major reason they won't even consider looking
   at it. That's not a "swipe", that's a practical reality. The same CxO types stay the
   hell away from Microsoft .NET betas and haven't upgraded to JDK 1.6 yet, either, and
   they're perfectly justified in doing so: it's called the bleeding edge for a reason.
3. Fact: I don't like Perl. Therefore, on my blog, which is a voice for my opinion and
   statements, Perl sucks. I don't like a language that has as many side effects and
   (to my mind) strange symbolic syntax as Perl uses. The side effects I think are a
   bad programming language design artifact; the strange symbolic syntax is purely an
   aesthetic preference.
4. Fact: I don't pretend that everybody should agree with me. If you like Perl, cool.
   I also happen to be Lutheran. If you're Catholic, that's cool, too. Doesn't mean we
   can't get along, so long as you respect my aesthetic preferences so I can respect
   yours.
5. I don't have to agree with you to learn from you, and vice versa. In fact, I like
   it better when people argue, because I learn more that way.
6. I also don't have to like your favorite language, and you don't have to like mine
   (if I had one).
7. I'm not ignorant, and please don't try to assert your supposed superiority by taking
   that unsupported swipe at me, either. I've tried Perl. I've tried Python, too, and
   I find its use of significant whitespace to be awkward and ill-considered, and a major
   drawback to what otherwise feels like an acceptable language. Simply because I disagree
   with your love of the language doesn't make me ignorant any more than you are if you
   dislike Java or C# or C++ or any of the languages I like.
8. Fact: I admit to a deep ignorance of the Perl community. I've never claimed anything
   of the sort. I also admit to a deep ignorance of the Scientology community, yet that
   doesn't stop me from passing personal judgment on the Scientologists' beliefs, particularly
   as expressed by Tom Cruise, or Republicans' beliefs, as expressed by Pat Robertson.
   And honestly, I don't think I need a deep understanding of the Perl community to judge
   the language, just as I don't need a deep understanding of Tom Cruise to judge Scientology,
   or just as you don't need a deep understanding of me to judge my opinions.
9. If by "homework", by the way, you mean "Spend years writing Perl until you come to
   love it as I do", then yes, I admit, by your definition of "homework", I've not done
   my homework. If by "homework" you mean "Learn Perl until you become reasonably proficient
   in it", then yes, I have done my homework. I had to maintain some Perl scripts once
   upon an eon ago, not to mention the periodic deciphering of the Perl scripts that
   come with the various Linux/Solaris/Mac OS images I work with, and my dislike and
   familiarity with the language stemmed from that experience. I have a similar dislike
   of 65C02 assembler.
10. I've met you, chromatic, though you may not remember it: At the second FOO Camp, you
    and I and Larry Wall and Brad Merrill and Dave Thomas and Peter Drayton had an impromptu
    discussion about Parrot, virtual machines, the experiences Microsoft learned while
    building the Common Type System for the CLR, some of the lessons I'd learned from
    playing with multiple languages on top of the JVM, and some of the difficulties in
    trying to support multiple languages on top of a single VM platform. I trust that
    you don't consider Dave Thomas to be ignorant; he and I had a long conversation after
    that impromptu round table and we came to the conclusion that Parrot was going to
    be in for a very rough ride without some kind of common type definitions across the
    various languages built for it. (He was a little stunned at the idea that there wasn't
    some kind of common hash type across the languages, if that helps to recall the discussion.)
    This in no way impugns the effort you're putting into Parrot, by the way, nor should
    you take this criticism to suggest that you should stop your work. Frankly, I'd love
    to see how Parrot ends up, since it takes a radically different approach to a virtual
    execution engine than other environments do, and stark contrast is always a good learning
    experience. The fact that Parrot has advanced all of a minor build number in the last
    year seems to me, an outsider who periodically grabs the code, builds it and pokes
    around, to be indicative of the idea that Parrot is taking a while.
11. Oh, and by the way, chromatic, since I've got your attention, while there, you argued
    that the Parrot register-based approach was superior to the CLR or JVM approach because
    "passing things in registers is much faster than passing them on the stack". (I may
    be misquoting what you said, but this is what Peter, Brad, Dave and I all heard.)
    I wanted to probe that statement further, but Brad jumped in to explain to you (and
    the subject got changed fairly quickly, so I don't know if you picked up on it) that
    the execution stack in the CLR (and the JVM) is an abstraction--both virtual machines
    make use of registers where and when possible, and can do so fairly easily. Numerous
    stack-based VMs have done this over the years as a performance enhancement. I assume
    you know this, so I'm curious to know if I misunderstood the rationale behind a register-based
    VM.
12. Fact: Perl 6 recently celebrated the fifth anniversary of its announcement. Not its
    ship date, but the announcement. Fact: Perl 6 has not yet shipped.
13. Opinion: I hate to say this if you're a Perl lover, but based on the above, Perl 6
    is quickly vying for the Biggest Vaporware Ever award. The only language that rivals
    this in terms of incubation length is the official C++ standard, which took close
    to or more than a decade. And it (rightly) was crucified in the popular press
    for taking that long, too. (And there was a long time where we--a large group of other
    C++ programmers I worked with--weren't sure it would ship at all, much less before
    the language was completely dead, because there was no visible progress taking place:
    no new features, no new libraries, no new changes, nothing.)
14. Fact: I would love for Parrot to ship, because I would love to be able to start experimenting
    with building languages that emit PIR. I would love to embed Parrot as an execution
    engine inside of a larger application, using said language as the glue around the
    core parts of the application. I would love to do all of this in a paid project. When
    Parrot reaches a 1.0 release, I'll consider it, just as I had to wait until the CLR
    and C# reached a 1.0 release when I started playing with them in July of 2001.
15. Fact: The JVM and CLR are not nearly as good for heavily-recursive languages (such
    as what we see in functional languages like Haskell and ML and F# and Erlang and Scala)
    because neither one, as of this writing, supports tail-call recursion optimization;
    the CLR pretends to, via the "tail" opcode that is essentially ignored as of CLR v2.0
    (the CLR that ships with .NET 2, 3 and 3.5), but the JVM doesn't even go that far.
    JIT compilers can do a few things to help optimize here, but realistically both environments
    need this if they're to become reasonable dynamic language platforms.
16. Fact: Lots of large systems have been built in COBOL, too, and scale even better than
    systems built in Perl, or C#, or Java, or C++. That doesn't mean I like them, want
    to program in them, or that the COBOL community should be any less proud of them.
    Again, just because I don't care for abstract art doesn't undermine the brilliance
    of an artist like Mark Rothko.
17. And I find the statement, "If you need X, don't look at other languages"
    to be incredibly short-sighted. Even if I were only paid to write Java, I would look
    at other languages, because I learn more about programming in general by doing so,
    thus improving my Java code. I would heartily suggest the same thing for the C# programmer,
    the C++ programmer, the VB programmer, the Ruby programmer, the Perl programmer, ad
    infinitum.

At the end of the day, the fact that I don't like Perl doesn't undermine its efficacy
amongst those who use it. The fact that Perl scale(1)s and scale(2)s doesn't take
away from the fact that I don't like its syntax, semantics, or idioms. The fact that
the Perl community can't take a ribbing over the large numbers of incomprehensible
Perl scripts out there only reinforces the idea that Perl developers like incomprehensible
syntax. (If you want a kind of dirty revenge, ask the Java developers about generics.)

Besides, if you listen to Paul Graham, all these languages are just footnotes on Lisp,
anyway, so let's all quit yer bitchin' and start REPLing with lots of intuitively
selected (or, if you prefer, irritatingly silly) parentheses.

But, in the interests of making peace with the Perl community....

65C02 assembler sucks way worse than Perl. (And no smiley; that's a statement
delivered in straight-faced monotone.)

---

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.