The Computer Jihad

Motivated by the latest silly comments on Slashdot, I decided to write a bit about the religious wars we routinely face in the programming world. These religious wars are routinely fought in many arenas. US Politics has the neocons versus everyone else. Chess has long had the Classical school versus the hypermoderns. The martial arts has had everyone versus everyone else (including the omnipresent yet ridiculous "we teach you that you don't need to fight but my sifu can kick your sifu's ass"). If you care about programming or have even a passing interest in it, I suggest you take a look at the following. Otherwise, take a gander at someone else's journal. The following will likely put you to sleep.

Many Perl programmers laugh at those silly Java programmers. They secretly wonder if Sun Microsystems tried to see how verbose someone can create a language and still have people foolish enough to use it. Consider, for example, the classic "Hello World" program.

class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World!");

Compare that to Perl:

print "Hello World!\n";

Because Perl allows programmers to use a procedural style and doesn't try to shoehorn things into an object-oriented style (OO), it's fairly easy to use. Java, with the most basic program out there, forces us to understand about classes, static methods, gives a hint at arrays and takes one of the most common behaviors, printing, and turns print() into the horrible System.out.println(). Of course, this is a simple example. Let's take one a bit more complicated, writing a line to a file.


class WriteFile {
    public static void main(String args[]) {
        FileOutputStream foStream;
        PrintStream pStream;

        try {
            foStream = new FileOutputStream("somefile.txt");
            pStream  = new PrintStream( foStream );
            pStream.println ("This is written to a file");
        catch (Exception e) {
            System.err.println ("Error writing to file " + e);

Now let's compare that to Perl.

open FH, ">", "somefile.txt"           or die "Can't open file: $!";
print FH "This is written to a file\n" or die "Can't print to file: $!";

In the Java program, not only is it considerably more verbose, we have several lines which can throw an exception. Did we get it by opening the file, printing to the file or closing it? Who knows? Perl allows fine-grained control by testing each exception explicitly. You could use multiple catch blocks in Java to handle each type of exception but that just makes the code longer and make the statement throwing the exception further away from the catch block. And in Perl I didn't even have to close the filehandle. Perl does that for me automatically when the file falls out of scope.

Of course, the more Java you develop, the more you have to face issues like this. Java takes far more time than Perl to develop in and developers who are familiar with both will readily testify to this. This may seem like nitpicking but when you're signing paychecks, having to pay for a hell of a lot more developer hours can tremendously change your focus. But is this the only drawback of Java? No. The language has some serious problems.

  • Java languished for a long time without regular expressions and some servers still don't have the versions of Java which support them.
  • Autoboxing in Java 1.5 was an attempt to get around some of the difficulties inherent mixing primitives with objects in a strongly typed language.
  • The latest Dr. Dobb's has an interesting article about functional programming in Java -- something many other programming languages have allowed for years. Java programmers are just learning this.
  • Java still doesn't have closures (much less first class functions).
  • Interfaces were a neat idea which introduced a different set of problems for the ones they solved.
  • Sun's decision to go with strong typing means they must focus more on class types than class capabilities, thereby eliminating many of the benefits of allomorphism.

OK, for most of you who don't pay attention of Java or comp-sci theory, the aforementioned list doesn't make much sense. Who the hell needs closures? People used to ask that about recursion. People even used to ask that about structured programming. So here's something that might catch your eye: millions of dollars. Paul Graham is a famous programmer who built software for online stores. More and more customers kept calling, Paul was making more money and eventually Yahoo! bought them out and Paul is rich. Here's what Paul had to say about his competitors:

During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers.

Still need convincing? A friend of mine who I will not name worked for a company that I'm not allowed to name. This company was developing online financial management software. There was a lot of interest in this company and they had tons of venture capital pouring into them. After he discussed with me what they were doing, he mentioned that they were doing all of their development in C++. A hot product. Tons of venture capital. A growing company. I told him to find another job.

That sounds weird, but here's the rub: they couldn't compete. Their software, though it sounded exciting, was a Web application. If it really took off, any company with a grain of common sense would see the profit potential and start developing that application in a language suited for rapid development. Features my friend told me these developers took months to develop could be duplicated in weeks -- even days -- with a dynamic programming language.

After a long time trying to get their product to market they finally realized that it was taking them too long to build. After much soul searching they admitted that C++ was a bottle-neck. They switched to Java. Their domain is now for sale. My friend went on unemployment.

The sad thing is, I'm a pretty good Perl developer and I can often run circles around most C++ and Java developers. In large applications covering problem domains suitable for both Perl and Java, the Java programmer can't hold a candle to me. I work on large systems too. I've worked on software used to collect data from thousands of theaters across the US and tell Hollywood how much money their films make. The company I work for now provides consulting on Perl software used by Rand Corporation, the World Health organization and Radio Free Asia. Don't tell me Perl doesn't scale.

But here's the catch: applications covering problem domains suitable for both Perl and Java. So far everything I've written might convince the casual reader that Java is doomed. The problem is that many developers choose the solution before defining the problem. It's not the case that any programming language is "one size fits all". Probably the biggest issue with Perl is raw performance. If you need an application to run fast, pitting Perl against C++ is akin to pitting me against an Olympic class sprinter. It's pathetic. But wait, there's more!

Areas where Perl falls down:

  • Raw performance.
  • Thread support is a big bucket of suck.
  • Need a rich graphical user environment? Java has Swing built in. Perl has difficult-to-compile add-ons.
  • Poor data encapsulation in objects.
  • Many Perl programmers aren't very good.
  • Poor introspection.
  • Primitive argument handling.
  • Lack of multi-method dispatch.
  • Can be difficult to deploy on systems where Perl is not already running.
  • Perl's linguistic underpinnings are strange and many programmers don't understand them.

The last point is telling. Perl relies on strange ideas of "context" and "topics". These are fundamental concepts which are nonetheless not taught well and programmers who are familiar with Algol-style languages will look at Perl and perhaps think they're in familiar territory. That is, until they see this:

my $data   = $line =~ /($some_regex)/;   # scalar context
my ($data) = $line =~ /($some_regex)/;   # list context

It's almost certain you want the second of the two lines but without understanding how the parentheses enforce list context, the distinction between these two lines is very, very strange.

Performance, as I mentioned before, is very important. Many programmers who complain to me about Perl cite this as a reason they will never use Perl. But what is performance? The misunderstanding here is at the heart of virtually all programming wars. No, I don't just mean misunderstanding what "performance" means; I'm referring to the mistake of using terms and just assuming everyone else is talking about the same thing. Performance might mean how fast the application runs. However, it might mean developer performance. Perl wins by taking a single developer and making him or her able to crank out far more code than someone using C. C wins by taking a single program and making it far faster than a Perl program is ever likely to be. So who's right? Neither. And here's the problem:

Do not choose solutions if you don't know what the problem is.

Some Perl programmers gloat over the fact that our language runs moderately faster than Ruby. So what? Ruby on Rails has been kicking our ass in by driving tons of developers to Ruby. Perl programmers gloat over the fact that Perl has namespaces and PHP doesn't. Very few modern languages do without this indispensable tool, but somehow PHP has been gaining a lot of steam because it's very good at the problem it's optimized to handle: rapid Web site development.

If you have a good understanding of the problem you need to solve, you can choose appropriate solutions. No programmer with half a brain is going to announce at the beginning of a project that she'll use text files instead of a database. Maybe a text file is perfectly appropriate for the project but you can't know that until you know what the project is. Choosing solutions for poorly understood problems means you're probably going to choose suboptimal solutions. Claiming "my programming language is the One True Way" means that you're going to look silly if you need heavy logical inference but don't know about Prolog or Mercury.

I think I know why developers get this way. It's the same reason why riots break out at soccer (ahem, football) games. When you identify with something you don't want to feel like you're stupid. You want to feel superior. Naturally, "we" have made intelligent choices and "they" must be fools. It's our natural tendency to not want to admit, even to ourselves, that our long-term choices are bad. And admitting that another language might be better suited for the task at hand is suggesting that our language is deficient in some way. Somehow the programmer projects a bit of himself into the language and takes this as a personal affront. I've been viciously blasted by programmers for having the temerity to suggest that Perl isn't as bad as they make it out to be. I've heard Perl programmers viciously blast Java developers for suggesting that Java is the ultimate language (and Lisp programmers really laugh at this assertion).

We programmers need to stop circling our wagons and instead open them, welcoming in programmers from other tribes. We need to learn from one another, not fight one another. All of this constant bickering and arguing only makes us look silly. Java, despite only being partially OO, can teach Perl programmers a lot about OO programming. Perl can teach Java programmers about the beauty of rich data structures and closure-based systems. Me? I still write most of my stuff in Perl but I'll drop down to C if I need raw performance. If I want to play around with GUI applications and multi-threaded code, I'll look at Java or Python. There's nothing wrong with flirting with the enemy. After all, they're really not enemies.

  • Current Mood: accomplished accomplished
Taking on ever more responsibilities so you may better contribute to your community. Or maybe just that they seem to appreciate you:

"The Grants Commmittee will be led by Curtis "Ovid" Poe, who has already distinguished himself as a grant manager for TPF. His experience and dedication, most recently with the Google Summer of Code / Perl Foundation grant recipients, has shown how valuable Curtis is to TPF."
More on topic, though admittedly I only browsed what you wrote, thank you for going past the classic io example. Too many people compare print and system.out.println and consider that the end of the Java/perl argument.
This was very timely—my father had been asking for advice on a language to write web apps in, and I made an argument for dynamic languages instead of Java/.Net. When I got home and checked my friends page, this was right on it, and I sent him a link. Thanks for the ammunition!
Sort of. He said that it made them aware of some possibilities they hadn't considered, but they haven't made a decision yet.
Yeah. His company currently uses Visual FoxPro, an xBase-derived (but fairly modern) language owned by Microsoft. M$ has never been that happy with FoxPro—it can't be made to work in .Net without losing all of its advantages, it doesn't fit well into Visual Studio, and it competes with BillG's beloved BASIC—so they have persistent concerns that it's going to be canceled. Moreover, programmers for it are somewhat difficult to come by, so they're at least looking at switching to another language for future development.
FoxPro --> ??
My former workplace just went through that exact same transition. Well, like 3 years ago. They ended up going with Java, which is when I came on board. It was the right tool for the time. I left that company not long ago, but faced with that decision NOW I would likely go for Ruby instead.
w00 yeah!
Let's get together!

Lambdacamels are one good data point here. Perl and Haskell working together!

I particularly like the Prolog/Mercury point, since I disagreed with a Perl programmer that Perl is the best choice for logical inference.

I think the problem is that sometimes we identify with the tech or lang. "I am a $LANGUAGE Programmer" necessarily implies identity.

There's a neat idea by Robert Anton Wilson that fixes part of this -

Even though I advertise for Haskell, I do not consider myself a Haskell programmer. Haskell is the best tool for my head right now, but I have no doubt I will find something better.

Anyway, it's silly to identify with a language, there isn't really such a thing. Each extension to Haskell changes the balance of the language, and the same for Perl. The new languages are often, but not always, close to the previous language. It's better to identify with a group of people who match your head, and let their ideas and discussions add to your understanding.
Re: w00 yeah!
Ah, Haskell. Looks like a wonderful language. I've always wanted to learn it, but never seem to have the time :/
Re: w00 yeah!
A minor correction -- the idea of Eprime seems to have originated, although not under that name, with Alfred Korzybski (, rather than R.A. Wilson. -- matthewsimon
Since your bio asked me to state why I just added you: Because I like reading your "little bits". (I followed the trail from, which I never really got into, but still check now and again.)
Thanks for letting me know. I've been surprised at how many folks have added me but left that off.

Glad you like my stuff!
Actually, I would argue that Java is great for teaching some OO concepts but since it's not even remotely close to a pure OO language, it really can't teach OOP. Much of the Java code that I have seen is primarily procedural code with an OO wrapper.
I agree with most of what you're saying here.
I use mostly Perl, but I would never try and write a GUI application with it (especially if it were to run in the M.S world).

It almost seems that the failing of a language can tell something about the person who is a self proclaimed zealot of that same language:
Perl programmers are lazy; there is so much bad Perl.
Java programmers don't look for the easy way out, in other words "will not use anything but Java".
C/C++ programmers seem to have a superiority complex.

I think that if people where less obsessed with their favorite brand of grammar and just used the right tool for the right job there would be less of this "religious" battle over what language is best, if only it were a perfect world. But then again, I guess I just restated what you have already written.

The major failing that all languages have in common is of a personal nature. Programmers are the problem with programming.
Most doomed projects are doomed from the design stage.
What ever happened to appreciation for the artistic aspect of designing software?

> they admitted that C++ was a bottle-neck. They switched to Java. Their domain
>is now for sale. My friend went on unemployment.

Ruby, Perl, whatever. There is no better model than an interpreted, rapid-development-oriented language for your web front-end, that calls to a compiled language for back-end for the "real work". That "compiled tool" may be an accounting algorithm in C++, a SQL server (which is hopefully written in a compiled language!), or even a shell script that calls a pipeline of various compiled programs. The right tool for the right problem.

The problem is that there is no profit in selling a model... only in selling a language. When selling a language you are competing with people claiming, "My language is perfect for everything" and if you say, "My language is perfect for specific cases, and use their language elsewhere" you lose when talking to CEOs. It it's nice and neat like the "my language is all you need" salesperson is pitching.

I think that's why LAMP (Linux, Apache, MySQL, Perl) is so powerful. Perl is your front-end, and it hides the fact that you are using a compiled, C program as your back-end (MySQL). Oh, some would claim that MySQL is an interpreted language, but SQL is really just an API to get to a compiled application.
Good Read!
Good read Ovid!

Horrified by perl
"Did we get it by opening the file, printing to the file or closing it? Who knows? Perl allows fine-grained control by testing each exception explicitly."

Is this supposed to be funny? It makes no sense.

Perl has exceptions like my Specialized has passenger seating.
I smiled a bit in reading this post. Though I can write programs in Perl, I'm far from being a programmer. Over the years I managed those whose job title was "programmer" only to find their skills were no better than mine and I didn't have the supposed training or degree. My experience is that most professional programmers are simply hacking to get something that works without regard to making it work well, efficient or easy to maintain.

As a hobby, I started doing small websites for others. Each iteration was a learning experience as I wanted to improve technique and work towards good design and standards. Tasks take twice as long as a result but, the payoff has always been worth it. I'm starting to learn Perl and discussed with other "web designers" (yeah, right!) languages and found prejudice running rampant with no real basis to qualify their view except by quoting others who were equally clueless but more authoritative-sounding in their writing style.

I wish I'd seen this post back during those discussions. Today, I don't frequent most web-design discussion boards since most posters have a competency between useless and dangerous providing only solutions that further one's bad programming practice... "remove the line 'use strict;' and your 'hello world' program will run." Pretty bad when the advice was provided by a forum senior.

The post makes a simple statement in those who err in choosing the solution language before knowing the problem. How true. People tend to chose based on what they know rather than ask if there is something better. This simple yet very profound statement runs true across many disciplines and I've chastised those who failed to research options apart from how they did it yesterday.

All I know about programming is that I don't know enough to even casually call myself a programmer. I'll leave that title to those who actually deserve it from the programs they've written.
badbeer: you may say that you're far from being a programmer, but that's true of many programmers I meet. In fact, I think it's fair to say that a large portion of the world's business struggles by on programs written by people who are not, or should not, be programmers. The world still continues.

As long as people don't die or have their livelihoods destroyed, it's actually kind of OK :)