Java vs Perl

Things that are hard to do in Java, and easy in Perl.

Primitives can't be stored in collections without wrapping them in some awkward Object, like a one-element array or a java.lang.Number-subclass, which both require a mile of typing. (This should be addressed by the JDK 1.5 Autoboxing. Moshe mailto:moshix@yahoo.com )
The servlet-api sucks. You have to write your own classes and methods to do shit everyone wants to do often. In perl you just use CGI qw(:standard) ; and you have most everything you need at your fingertips. (This is a strongly biased statement. Firstly, it mentions the use of an external module (CGI) for Perl, while ignoring that there are several such public, open source libraries out there for use with Java (notably in the Apache Commons library: http://jakarta.apache.org/ ). Secondly, no mention of JSPs is made. --żpburry?)
Formatting and parsing strings in java is an error-prone bitch that requires a mile of typing.
Java is slow to start up, and usually requires something on the order of three times as much memory as other runtimes.
Sort an array of Strings (Annoyingly hard in java if you want to sort on anything but natural ordering, see the StringLengthComparatorDemo example on java vs perl examples. --Kreiger)
JNI isn't the easiest thing (Java Native Interface that links to C/C++ libraries). I would not say that it is extremely difficult though. (For perl, use XS, which is used by many perl modules. See perlxstut(1) and perlxs(1). Of course, we also have Inline::C(3). What's more, CPAN offers numerous modules for interfacing java in perl. There are modules for JNI, RMI, and Inline::Java. See java in perl --Kreiger)
No provisions for handling things like paths and text-encodings coming from the outside. Everything is assumed to be data about the system the application is running on. So, for example, handling macintosh paths in windows is a bitch.

Things that are easy to do in java, and easy in Perl

Convert a byte-representation to a string and a string to a byte-representation (Since perl 5.8.0.)

Things that are easy to do in Java, and hard in Perl

Threads.

More to come when i feel like it.
If you think i'm wrong, then feel free to correct me. Also, feel free to add more examples. For problems with perl, see http://www.perl.com/language/versus/perl.html
--Kreiger

I believe that these examples show the benefits of Perl when compared to Java, but it avoids the benifits Java provides. Such as ease of debugging, reuse, extension, and performance. There are not many maintenance developers that would choose to maintain a perl legacy application over a java legacy application ( if they were proficent equally in both languages ). I believe that Perl has it's uses in area's where Java would be too cluncky and slow to write. On the other side of the coin, Java has is in it's element in larger projects that benefit from polymorphism and reuse.
--żScot Hale?

Scot: I agree that there are some things that java is better for. I much prefer java for object-oriented design due to less kludgy syntax, and for unicode-dependent programs, though unicode-support is supposed to be good in the 5.8.0 version of perl.

You are correct that my examples show areas where perl outshines java. I will try to find some examples where java outshines perl, although i believe there are few.

I'd have to say that after programming in both java and perl for three years, i find perl the winner in ease of reuse and extension. You have to look no further than CPAN (http://www.cpan.org/) for proof.
Performance-wise, i'd say that they are about equal, as long as you have the three times as much memory that java requires for an equivalent program, and can stand the startup-time.

Do you have any good examples of solutions in java that are obviously better compared to doing them
in perl? Feel free to add examples to this page, or create a new page (java vs perl examples) with an example.
--Kreiger

I must admit, I didn't realize how robust Perl has become. I found http://www-106.ibm.com/developerworks/linux/library/l-p560.html to be a good article comparing Perl to other languages including Java. I think the last section "The best of Perl" gives a good comparison among the languages.

I do not know much perl myself, so I don't think I will be able to come up with examples (if there are any!)
--żScot Hale?

That IBM article is from 2001. That's 8 years ago. If Perl was robust back then, it's way more robust now, with Moose for OO and Catalyst for web application development.

--żdandv?

I used to use Perl for everything. I wrote OO Perl, and I thought it was cool to have to recreate the entire structure of an object-oriented paradigm by hand. Then I got a job. Now I use Java for just about everything. To be honest, I only maintain proficiency in three languages: Java, C, and Perl. C for things that need to be tight, fast, and can afford to be machine specific. Perl for quick and dirty sysadmin tasks. Java for everything else.
--żDanT?

DanT: I've commented on your examples on java vs perl examples.
--Kreiger

I also use Java, C and Perl. I would not want to maintain a large Perl script; or one that tries to encapsulate complex business logic. The code can be fugly looking, and seems to be made worse by the types of people that use scripting languages. By that, I mean they are not necessarily concerned with elegant code, but only efficient code -- and it's usually very procedural in nature. That said, Perl has an excellent component (module) based framework which I find works great for short (~1KLOC or less) scripts that are more utility oriented: for example, inserting records into a database, email notifications, reports, and of course file manipulation.

I don't use C much anymore, but it generally remains cross-platform and low-level.

Java I use for: Standalone apps, Applets, Swing apps, JSPs, Java Beans and I'm now exploring J2EE (specifically STRUTS, EJBs etc). You can go to open-source solutions for some of this stuff (ex: PHP or Perl CGI) but I think the tech surrounding Java is generally more scalable.

--żR.?

I think calling Perl script 'fugly looking' is a little unfair on the language. I's all down to the programmer. It's a great language, but just gets a bad name because people do quick and dirty scripting with it. I've been programming perl for a while, and have learn't how to properly write the code. I have no Java experience, so if I replicated one of my perl scripts in Java....which one would look 'fugly looking' then??? The truth is, it's all about the task in hand. People tend to like the language that they know best...and never think much of the ones they don't know. I think DanT's got the best idea, picking the best tool for the job. I little bit like the unix admin who only uses perl and is then introduced to the world of sed, awk e.t.c..

Matt

--{

As someone trained in Java from it's inception, I loved it at first use. Now that I've done big projects with it for several years, I love it even more. Everyone except windows developers can now totally avoid the error prone nature of C.

I always avoided perl as a language that was "by hackers, for hackers" It uses every possible punctuation mark on the keyboard and allows at least a dozen ways to perform any task. Cool for authors and hackers, a nightmare for beginners, and maintainers.

Now that I've been doing sys admin tasks for a couple of years, I see the use of perl... As someone above said--in Java dealing with strings can be very painful, and dealing with the OS can be very unnatural.

I'm just staring to get into the OO aspects of Perl because of a large script I wrote which needs to have reuse possibilities. I must say that this is where the beauty of Perl breaks down. Java is beautiful because it makes it hard to do things wrong with regard to modularization. Perl on the other hand is just the opposite...

I agree with others... Perl for admin scripts, Java for everything else, and C to help you create perl or java libraries when needed.

Will Riddle

-
As a perl programmer i am attracted towards the independence that perl allows you to do a task as quick as possible and at the same time allows n number of ways to do a task is a excellent feature. Java inspite of having a structured approach makes a hard part in doing a job. It wastes lot of time. Still serves some good purpose by making a readable program.

I dont agree with others ... Perl for admin scripts, Java for everything else....

This not the reality. Being a dynamic language perl has lot of structured ways to do a job. Its all about following standards. If you dont then you are under trouble. Perl can acheive all the task that java would do, more over you can do it in half the time you take to code your java program.

I always tend towards the architecture of the system that i would develop and then choose a appropriate langauage.Perl is as portable as java and supports more platform except the mobile devices where we need a small runtime environment.

Sasi Kumar.G

I dislike Java so much that I'll even consider coding in perl to avoid it. BTW, Kreiger, how about an updated position on this issue? I've been hearing a disturbingly large amount of Java-tolerance from you lately...

Sunnan

Yes, i've started liking Java more and more, but that's mostly because IntelliJ IDEA has made it easy. It does all the typing for me. Java is still in many ways braindead.

Kreiger

People,

I am an experienced Java/J2EE developer and am very new to Perl and I am sat amongst a group of perl fans on a daily basis; AAARRRRGGHHH!!!.

It does bug me that alot of people have to be biased towards the Language they have used the most and are proficient in and then claim that they believe in the right tool for the job. The truth is your loyatlies will always sit on one side; it's natural.

I believe that for one to really realise the pros and cons between anything; you need to spend the same amount of time & effort with them all.

All languages have there pro's and cons; none is better, they all have there different uses.

Having not used Perl much yet so far these are my toughts. Please feel free to comment on them but plese do not bite!!!

Perl, tends to be used for Unix Admin, tasks, small applications in areas like the Build and Deployment of an Application Life cycle; where things need to be scripted short with small tasks that benefit from being procedural, job oriented and used to role out things like applications across servers.

Perl can be used in an object oriented manner but not object orientation to it's fullest as it has its limitation on how object oriented you can used it. It doesn't provide all the constructs to go down a true OO route, nor does it enforce OO techniques; therefore allowing programmers to slack, hack and write bad code that is not as readable, maintainable, flexible and extendible. And of course, it lack scalabilty.

Yes a good programmer with good object oriented knowledge and experience would be able to write good OO Perl; but they would have had to entered the Perl world after working with a string OO language like Java or C#.

I have no doubt Perl is very powerful, is quick to learn and quick to write small programs in; and is great language for it uses. It's important to know when it should be used.

Java, enforces some OO and aids you to think, design and develop object orientedly; although inexperienced OO developers can abuse Java too. But an experience object oriented developer would take java to the entire strengths of OO and would prefer to write in an OO language; even though it might not be good at the task at hand.

Java is clunky but very readable and maintainable compared to perl. Some would argue that a good Perl programmer would have no problem maintaining Perl; but I still believe that it is no way near as readable and would take longer to understand than a Java program.

'' Really. Please define a simple set of tuples in Java, JSON, and Perl. In other words, do this in Java:

my $parameters = {

   user => 'joe',
   password => secret,
   favorites => \@favorites

};
'' - żdandv?

And then comes the enterprise world of business systems, web application, legacy integration, transactional and messaging systems, reuse, lower maintenance, use of frameworks, leveraging OO techniques to develop flexible code, and the speed at which new functionality can be added to enterprise scale applications, giving corporate organisations what they need to make more money. Java rules in this department.

Theorically anything is possible in any language; it just depends on if the fucntionality has readly available to use. I'm a fan of reuse before you buy, and buy before you build! Why waiste time & effort building something when it is already available; why not leverage something on the market and use your time to evolve things further. Time is money! Choose the fastest option!

Imran