Flutterby™! : Perl vs Java

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

Perl vs Java

2003-03-17 18:11:31.131806+00 by Dan Lyke 6 comments

Rafe Colburn has an interesting Perl versus Java comparison, focusing on the philosophical differences between the approaches the two languages take. He illustrates with some code from Blosxom which at first glance seems fairly obscure. He presents a Java[Wiki] version and says:

Clearly the Java code is much more readable, and that's why I like it from a maintainability perspective. That said, if you're really up to speed on your Perl, it's amazing the sorts of things you can compress down into one amazingly byzantine looking line of code.

I differ. Read through those 12 lines of Java) code. Take the time with "perl -le 'print ...'" to figure out what the one line of Perl code does.

Now, imagine maintaining a huge system. You non-programmers think of it as trying to organize a large book. Realize that this is an idiom you're likely to see a few times in this book. Even though the first time through it takes twice as long to understand that phrase, in subsequent passes through the text you can grasp the meaning of the code in one line. The Java equivalent would be like reading a book that said "converted from one language to another" rather than "translated" every time the topic came up.

Dave Winer goes further in his link to Rafe's screed and says:

If you use an outliner to edit your source code, his multi-line Java example shrinks down to one line, just like his Perl example.

I think this is untrue too. Emacs[Wiki] and VisualStudio .NET[Wiki] both have code-folding in them. We can quibble over whether those are true "outliner"s, but the outliner hides the functionality: "There's a 'for' loop here, but I don't know what's inside it." Perl[Wiki] still lets you know what's going on, it just says it concisely. And Perl[Wiki] offers you the tools to figure out what's going on fairly simply.

[ related topics: Dave Winer Perl Software Engineering ]

comments in ascending chronological order (reverse):

#Comment made: 2003-03-17 19:21:48.273495+00 by: Jerry Kindall

Functions, baby, functions. http://www.jerf.org/irights/2003/03/17.html

#Comment made: 2003-03-17 20:19:13.568429+00 by: Dan Lyke

I disagree with a few things in that for one reason. Well, okay, two:

  1. He's right about Un*x only. But ya know what? Backslashes for path separators are a lame idea and most of Windows gets along with forward slashes just fine. So make your users specify forward slashes. Or normalize your paths on input.
  2. Functions help abstract, but that abstraction becomes different for every function. Idioms work for code compression in all circumstances.

#Comment made: 2003-03-17 21:08:05.58167+00 by: dws [edit history]

There's a point past which concisness and compression is a good thing. Blosxom takes a step passed that point. I've been considering using blosxom to replace my home-grown blog system, and have spent a bit of time going over to code (including the various betas as Rael heads towards the next major release). Though it's powerful, I've found blosxom to be a bit too hard to read (long conjunctions of expression fragments), and a bit too hard to debug . And I do a lot of Perl. All that compression means fewer places to set breakpoints. There were a few problems that were hard for me to spot due to the tightness of the code, including one that caused unnecessary index rebuilding. (Patch submitted.) I may still use blosxom.

#Comment made: 2003-03-17 21:58:54.669278+00 by: Mark A. Hershberger

If you want a non-unix-only solution to the problem blosxom is trying to solve here, use File::Spec's splitdir().

You can write un-readable garbage in any language. Perl's garbage is just more powerful.

(Did I mention that I worked with Ilya Zakharevich to add code folding to cperl-mode in Emacs? Toot Toot! It's Dave Winer's fault, though. If he didn't keep harping on outliners, I'd never have attempted to add code-folding to cperl-mode. And even now, I don't see a lot of use in it.)

#Comment made: 2003-03-17 23:34:29.164735+00 by: baylink

What you're discussing, Dan, is a syndrome referred to as "What You See Is ALL You Get", and it's the standard explanation of why power is *good* in the expressiveness of programming languages.

Ask a biker why horsepower is *good*, rather than bad ("and downshifting would have wasted *just* enough time to ensure that I died in the proper gear"); it's the same answer.

#Comment made: 2003-03-18 08:07:20.650504+00 by: dexev [edit history]

That metaphor doesnt' work for me.

Power = # of things I can do Power != # of ways to do each one.

I would say Perl is more like a bike with three sets of handlebars. I think Java is a gold-plated Vespa.