Previous Entry Add to Memories Share Next Entry
The Computer Jihad
Mechanical
publius_ovidius

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.

import java.io.*;

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");
            pStream.close();
        }
        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.


Ah, Haskell. Looks like a wonderful language. I've always wanted to learn it, but never seem to have the time :/