All the Perl that's Practical to Extract and Report

Perl v. Java

jjohn on 2002-02-12T14:18:01

From a truly ill-considered Ask Slashdot question came this pearl of wisdom. A former (award winning!) Java hacker confesses his adulterous thoughts for Our Favorite Language. I'd like to pick up on a few of his points and perhaps add a bit of my own.

  • Unicode: it's a sore spot of Perl, but seems to be hunky-dory for java. I lay the blame for Perl's developmental problems here on DWIM. As Perl coders, we've come to expect Perl to handle simple (and not so simple) string manipulation without that much handholding from us. I suspect that this bit of Sloth is biting the 'porters. Certainly, the unicode issue is preventing Perl from being a first class XML processing language (no XS cheating here).
  • Perl's threading system is still developing, but java's model seems to be working fine. Of course, Perl's forking model is probably better and easier to use than java's (cross-platform forking is difficult to guarentee). I say tit-for-tat on threading/forking here.
  • Dedicated IDEs are bullshit. There, I said it. Coders shouldn't handle their code with the tongs of an IDE, like some poor MS Word shlub. If the java folks have more IDEs than Perl People, good on 'em.
  • ALL PRAISE CPAN! Perl was years ahead of MOST other languages here and continues to put java to shame. CPAN is not only an FTP archive, it's damn protocol to download and install libraries! In your face, JAR!
  • Elegance is something for which python and java are praised and for which Perl is found wanting. Clearly, I don't get the 'elegance' argument and I never have. If 'elegance' means fewer characters typed during coding, Perl wins for most applications. Consider perl one-liners, the inclusion of perl hashes, regexes, etc. Perl delivers the promises of 'less typing'. Is elegence the lack of 'weird characters?' It may be, but Perl's syntax acts like a road sign to tell the maintain what's going on. Sigils (those funny characters preceding variable names) are not a misfeature -- they are essential to maintaining a Perl program. You always know what to expect from a variable with a sigil. Without them, the reader (and coder!) needs to find the original declaration of the variable to figure out what it is. I hate that. Is elegance the object model of a language? Python and Perl's object model isn't terribly different. Shocked? Don't be. The difference between python and Perl objects is that python has a object type, where perl blesses variable data. Java and Perl object models are very different. Java's single inherentence (which is a Good Thing) and object data protection (which is a Useless Thing) definitely come from the C++ crowd.
  • You always get the source code with every Perl script and library. This makes it simpler to debug programs in Perl because you can always step through almost all of the code, including the libraries.
  • Readability. Perhaps this is meant to go under 'elegance,' but I think this is a different issue. All languages can be obfuscated. It's not the language designer's perview to make you code clearly. Any claim a language makes to being inherently cleaner to code in (I'm looking at you, Java and python) is naive. I don't expect a java programmer to maintain a Perl program, just as I don't expect a Perl programmer to maintain a java program. In fact, that's why I'm not an editor for a Japanese magazine -- I have no facility for the language. Does that mean Japanese is inferior to English?

/. will make you go blind JJ :)

hfb on 2002-02-12T16:07:46

Don't mention unicode around mr. jark. As one of the few porters left with a regular day job these days he spends his nights fighting with this rather sad state in perl. It has made some progress in the last year though so give the man some props :)

Re: no disrespect intended

jjohn on 2002-02-12T16:22:27

What I was postulating was that because Perl is so good with ASCII, people have the same expectation that it will be as good with unicode. We take for granted all the automagical string things that Perl does and I'm guessing this is what's making unicode so difficult to integrate into the language. If Perl merely said "there's a unicode module for making unicode objects which has index() and substr() methods," then Jarkko's life would be carefree indeed. Unfortunately, we Perl users want all our favorite Perl tricks to work precisely the same way with unicode and that seems to be the bear.

Re: no disrespect intended

hfb on 2002-02-12T17:25:57

None taken my sweet :) I just meant to imply that mr jark feels your pain as I can tell by the grimace on his face when he's working on Unicode or the engine that dare not speaketh its name.

Again with the Java...

lachoy on 2002-02-12T17:02:57

I posted a comment on perlmonks recently about this need for Perl people to put down Java, but a couple more things:

Dedicated IDEs are bullshit. There, I said it. Coders shouldn't handle their code with the tongs of an IDE, like some poor MS Word shlub. If the java folks have more IDEs than Perl People, good on 'em.

The thing missing from this statement is some sort of qualification, like "for me". I am more productive in xemacs and a CLI, but I'd never presume to tell someone else their tools are shit (e.g., "Coders shouldn't...") -- particularly when I've never used their tools myself. Such arrogance turns people off from hearing our substantial (and very powerful) arguments. And it also prevents us from finding what's useful from these tools and doing the old embrace-extend two-step.

I think the sentiment we should be aiming for is to show these people that an IDE is one tool that people can be productive in, but our tools can also help you be amazingly productive. They're different, they require a learning curve, but so does everything. Getting into a pissing match about which tool can do X faster is (IMO) useless and counter-productive.

CPAN: spot-on. There is a CJAN movement afoot but it will be quite some time before it can come up with something useful. Many folks have said it but it always bears repeating: CPAN is Perl's killer development app.

Readability: I also agree. People not familiar with Perl see the sigils and figure they'd never get used to it. They also mistake verbosity (which Java has in spades) for clarity.

Re:Again with the Java...

hfb on 2002-02-12T17:30:53

As the self-appointed perl historian I always find it amusing when people ask how to make their own CPAN. All you have to do is read the packrats archive to see that there was little discussion about the matter and 2 guys who just put something together and did it. PAUSE is the killer app, CPAN is merely the distribution method :)

Re:Again with the Java...

jjohn on 2002-02-12T20:55:34

The problem is the Perl is ghettoized in programming community at large. If you read the original Slashdot thread, this will become very apparent. It is my belief that too many programmers have no real idea how their code and the bare-metal machine on which it runs work together. The whole notion of an application dedicated to programming is really a windows concept. In unix, the WHOLE operating system is the IDE. In Windows, user-end programming feels like an afterthought.

Also here at use.perl, I know I'm preaching to the choir -- there's little need for me to be reasonable. I don't expect a lot of java-heads to be reading this. And if some are offended, perhaps they might want to see what all the fuss is about. If not, oh well. It is said that opinions are like assholes: everybody has one. So, don't mind me while I hang my butt out the window. :-D

Re:Again with the Java...

lachoy on 2002-02-13T04:16:04

I hear you about Perl being ghettoized. But I've found that people who can put two clues together will be convinced when I quickly create something that works well and reliably. Or when someone asks, "Do you know if we can...?" and I immediately respond: "There's a module for that. I've used it. It's easy."

People who aren't convinced by results aren't going to be convinced by anything, and they'll pass from fad to fad and eventually (in a perfect world?) seek their natural level. After a few strenuous tries, I don't bother with them.

I also know what you mean about Unix, but I'm finding that I can give the unix vibe, little by little, to even hardcore VB folks. Again, it's all about the results. I'm getting asked more and more to create scripts to insert, remove, or extract information from hundreds of VB code and form files, something the IDE just can't do. (Apparently there is a way, but the interface for automating the VB IDE is apparently so horrendous that the local VB guru, after investigating and experimenting for a couple weeks, refuses to even discuss it for fear its virus will spread.)

After two or three of these, people get interested and after I show them how easy it is, their curiosity is quite strong. Then it's: "Well, in Windows we have to do this and that extra step, but in unix we'd just pipe in here, and..." And I always install xemacs on their machines -- a real virus!

One of the reasons this is a sore spot for me is I think we (as perl advocates) do ourselves a great disservice by dissing out of hand other languages or tools. It makes us look desperate and petty. I know that this is the choir and there's no danger of that here, but then other people see we're drinking the kool-aid and they'll wonder why they should take us seriously :-)