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 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 and VisualStudio .NET 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
still lets you know what's going on, it just says it concisely. And
Perl 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:
- 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.
- 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.