One reason that X might "bring home the bread" when compared with Y is that there are more jobs requiring X skills in some area than there are jobs requiring Y skills. This may have little to do directly with the relative merits of X vs. Y. Or it might.

Looking around Silicon Valley and points north, I see a lot of server-side Java development going on. But I think this is more a statement about how deeply people fear and detest C++ than it is a statement about Perl. A lot of C people moved to Java as a way to avoid having to endure the torture of C++. I have plenty of friends who looked around at disasterous C++ projects around them, and saw Java as a lifeline that would save their careers. Java offered the possibility of getting things done without spending their life fighting the language and debugging.

So why not Perl? For one, Perl wasn't as well known. When it was known, it was thought of as a scripting language, not a "real" (chuckle) language. And Perl didn't have Sun's marketing engine behind it. The timing of the world moving to browsers, with Java applet engines embedded, fueled a move to Java. And by the time people saw that applets weren't going to live up to the hype, server-side environments had begun to mature. There are now several good server side "application engines" for Java that manage persistence for you. And since a lot of applications this days need to sit on the server and generate pages based on stuff in a database, that's enough to generate demand for people skilled in Java.

So yeah, the hordes are moving towards Java. But, fortunately, that isn't where all of the money is.

The future might be portability, but it's not clear if Java will be there.

It's quite easy to write portable programs with Perl, and it's at least as easy to write stuff that's horribly unportable with Java. I know of OpenGL-wielding, native-sound-library-calling multimedia demos written in Java that only run under Internet Explorer 4+ with the Microsoft JVM, and I know of programs written in Perl that work on any platform.

Programming languages are not portable, programs are.

If you anticipate enough of your programs needs and know how to encapsulate the facilities, porting will be easy, maybe as easy as "copy the code". If you use modules, or in the case of java, use any external (native or Java) libraries, you create dependencies. You have to see yourself how much increased dependencies weigh against the speed gain in development.

I've worked with both. I have done much more with Perl than with Java.

A competent programmer will be able to code in either.

A competent Java programmer will be able to write cross platform code, if your idea of platform compatibility ranges from both Win32 to Solaris. Bill Joy himself help you if you want to write an applet. (This seems to be less popular with Sun's marketing department these days.)

The nice thing about Perl, when it comes to a portability standpoint, is that the people who write it make sure it work on other platforms. Even better, for those platforms on which it's too odious for us mere mortals to attempt to program, there are crazy people like Ilya and even companies like ActiveState and Indigo that make sure the main distribution compiles on exotic platforms like VMS and Windows.

With Java, if you're not Solaris or Win32, you're second class. (No offense towards either Blackdown or kaffe, who are doing fine work in a difficult situation.) Sun's not interested in portability that helps anyone but Sun.

Perl, of course, suffers no such market-dominating constraints.

Update: mothra is quite correct that Perl does favor Unixy systems... but at least there's an officially blessed binary available for just about any platform on which Perl runs, which is not the case with Java. (I danced around that point slightly.)

With Java, if you're not Solaris or Win32, you're second class.

Yes, and with Perl, if you're not in Unix or Linux, you're second class! I don't even like Java (far.too.wordy.for.me), but let's not pretend that Perl doesn't heavily favour certain platforms as well.

Certainly Perl's favoritism isn't such that it won't even compile on Win32 systems, but there's no question that most production Perl scripts are running on Unix and Linux servers, that most documentation has a heavy Unix flavor to it (ie. refer to manpage foo for more info...), and that most CPAN modules only make the promise of having worked on some flavor of Unix.

By the way (and this is no longer specifically related to what chromatic was saying), but we can we waste slightly MORE time comparing language XYZ to Perl?

Being someone who codes almost exclusively for Win32 systems these days, I'd have to disagree. The quality of the Win32 modules does not reek of a second class effort.

As for scripts that have already been written, I might point out that perl wasn't always an easy issue with Win32 systems. If a script was written in the past, it was written for Unix. Recently, I've just started paying attention to the last time the script was edited. Relatively new scripts run on Win32 in many cases. I think with time these old scripts can be ported (a good way to spend time if this really bothers you that much) and that the perl community will learn better methods for writing multi-platform code.

Yes, and with Perl, if you're not in Unix or Linux, you're second class! I don't even like Java (far.too.wordy.for.me), but let's not pretend that Perl doesn't heavily favour certain platforms as well.

I think you have that backwards. Unix-type users tend to favor languages like Perl for more heavy-duty programming than to Windows users because of their background (mainly because of sh). They're used to writing short little shell scripts as well as longer more complex C programs, and Perl is heavily endowed with both. Thus, you see more Perl usage on Unix systems. The language itself isn't really specific to, either, though. The Win32 support is actually on par or better than the Unix support (note the number of well-written, Windows-only modules on CPAN). It's just not as heavily used because the background of my Windows programmers is not scripted/interpreted languages. It's .exe files and the C++ source that underlies them. Java is the natural extension of that.

Having worked with both Perl and Java on multiple platforms (although not for heavy graphics stuff), I'd say their portability is about the same. As corion said, it's possible to write both portable and non-portable programs in both languages.

One of the benefits of Java is having some money behind it. I'm serious. I work with with databases a lot so I can use JDBC and DBI to compare. DBI is faster (much faster in some cases) and simpler to use. But JDBC offers much richer access to metadata which can be extremely important for portability. IMO, a big reason for this is Sun's muscle -- probably a bigger reason is the wider market for JDBC drivers, but that just illustrates the point.

The companies and money behind Java also enable the various working groups to come out with some (again, IMO) really thoughtful APIs. For instance, JMS (Java Message Service) is just an interface but since vendors want to have a Java interface and they want to be 'compliant' (however that's defined), then they'll typically implement most or all of the interface. For a developer, this kicks ass. It's like all the good parts about developing for Windows without being (necessarily) constrained to a single vendor. Yes, Sun is kind of that "single vendor" but the things I've been working with (Servlets, J2EE, JMS, JDBC) they've really seemed to work with industry and the folks who are using the technology to make things easier.

If something like this existed for Perl I'd be in nirvana. :-) As it is, developing with Java is generally more of a pain than developing with Perl -- the easy things in Java aren't always easy.

Chris
M-x auto-bs-mode

After having read through two of these long discussion threads -- and very interesting they are! -- I find that there is one aspect of the comparison that has hardly been touched on at all: the database interface capabilities of the two systems. Java can use only interact with JDBC, as far as I can gather, whereas Perl can interact with Sybase, Oracle, mySQL/SQL, and one or two other database systems, correct? Wouldn't that make Perl much more useful than Java?

laura.guimauve

You're misunderstanding -- JDBC is (more or less) equivalent to the DBI in Perl. Both are middle layers which allow driver authors to write to a spec and application developers to write to the layer without worrying about the driver being used. There are caveats to that, of course :-) But if you're using general database capabilities both work quite well.

Having used both, DBI is faster but JDBC has more metadata capabilities and is generally more featureful. It's also more difficult to use (like most things in Java) because you have to always be aware of datatypes, which Perl and DBI (and well-written drivers) make transparent for you.

In addition, most (if not all) of the big databases have Type-4 (pure Java) drivers for JDBC. This means that you don't have to worry about client libraries, compiling, etc. across different platforms -- the same Type-4 Oracle JDBC driver will work on both Linux and Win32 with no modifications whatsoever. Very nice.

Chris
M-x auto-bs-mode

I'm sure the programmer who said that.. was viewing as it doesn't need runtime files.. such as VB. Java is cross platform in a way that it can run on any platform that has the jvm installed.. whereas perl can run on either Unix or Windows..if perl is installed. Which is more portable? I think both have their plus and minus'.. when it comes to that. Depends on what you want to do.

The growth of jabba da code, er Java code is directly releated to the corporate acknowledgement for Business to Business solutions. Now that more companies have invested in B2B solutions via Java, they are discovering what a fat pig it is, but with so many resources invested its to late to back out now... Plus processors will always get faster.

For the next several years Java will ..bring the bread home(which in this industry is quite an accomplishment), because of the massive investment that's being put into it, NOT because of it's portability, flexibility or ease of coding.

COBOL anyone?

No!

Once you have many implementations out there, even if everyone wanted to play honest to adher to the "Standard", there is always place fo incompatibility. Perl on the other hand is surprisingly portable for a language that had not initially been designed for portability or security . One strong point for Perl is that it is essentially one implementation portable across many operating system. This leaves less leeway for divergence!

-- stefp

Brothers! This discussion has great potential for being Flame-bait...

Tread lightly on the rice paper, Grasshopper...

Personally, I use both Java & PERL.

There's much that is Right & Wrong with both of them. But what drew me to both of them to the exclusion of everything else, was portatility, a.k.a. The Holy Grail of programming. That & Open Standards. Now I realize that Java isn't a "True" Open Standard. But I think that Sun, to SOME extent has been smart to keep control, seeing as how M$ has been hell-bent on squashing it.

It's terribly easy to write platform dependant programs, in either language.

So now we get into the pro's & cons... Superficially, the ones that beat you over the head with their obvious nature are Regular Expressions in PERL & GUI in Java. Now there is the nearly ubiquitous OROmatcher library to perform a wide range of Regular Expressions, using Java and there is PerlTk. But what's better is better, period. Then you can pick & pick & pick about execution speeds (which depend more on your platform than anything) & OOP purism, and also the simple number of lines of code required to do ANYTHING... How important it is to you & your career & the company you work form, that you "own" your source code...bla bla bla yadda yadda yadda

I beg of you my Brothers, embrace both. Though, IMHO I'd rather suck fish lips than go anywhere near VB.. 8-P

I am in the process of relearning computer programming, my last language being Pascal. I researched carefully on what to learn first. I chose Perl because it is versitile as well as being the first on the lips of real people, not some pumped up advertising website. I do not regret this choice, having found that Perl has lived up to and surpassed my expectations. I love the fact that "TIMTOWTDI" and that the community is willing to help a novice like me expand and learn without being harsh.

However I am resigned to the fact that I must learn more (ie Java and JavaScript) to become more marketable.

puts down the chalk and walks away from the board

Why Java Sucks

This link isn't really appropriate. Views of "this language sucks" or "that OS sucks" are a dime a dozen. How many more dead horses need to be beaten?

Actually if you have been around computers a while it is immediately apparent upon reading the discussion that the author of that link has quite a bit more knowledge than the average, "Language X sucks because" author.

Depending on the circles you hang out in, you will also find the author's name immediately recognizable. At least I found it so.

In fact that particular page is one that I have seen discussed before. By people with quite a bit of experience in many languages. As a discussion of key mistakes in language design that you want to avoid. Now you may disagree with some of his biases (I know that I do), but there is not one technical criticism he makes that is not worth listening to.

So please swallow your criticism, go back to the site, and read it. Feel free to ask for explanations of any of the terms that you do not understand. Feel free to ask for explanations of why the things that he wants would be useful things to have. (And no, Perl does not have all of them. But it does have several.)

But take it from me that this is not your random, lame-ass, let's flame a language today, link. And it is not written by a random geek with an opinion and a website. OK, some of the criticisms might be dated now that Java is a little more mature, they are still worth a read.