Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

A Perl vs. Java fight brews

by Moron (Curate)
on Jul 24, 2006 at 13:03 UTC ( #563254=perlquestion: print w/ replies, xml ) Need Help??
Moron has asked for the wisdom of the Perl Monks concerning the following question:

The scenario is that for nearly ten years, (intensive) customisation of a certain datawarehousing package has been done mainly in the following languages:

- ksh

- Formula Engine (which provides scripting glue between a time-series database and a relational database)

- ac_bl (SQL with an object layer over it)

- some other specialised lanaguages.

One or two pieces of Perl have crept in here and there, but the major services of the customised system have been written in a blend starting with ksh and variously spawning interpreters for the other languages.

Beyond a certain point in time, my continued presence at this site will probably depend on my winning the case to replace ksh with Perl as the future language for customisation. I have four colleagues, none of whom have Perl experience. The colleagues agree that change is necessary but are of the opinion that Java should be the language of choice (there is more Java in the original system than Perl, although the manufacturer has written a Perl API (= some modules) as well as a Java API). The features of Perl I can see winning against ksh for this system are as follows:

- greatly reduce the spawning of new ksh processes

- ready interface to unix system services

- Open3 to control input and output between existing utility programs

- CPAN

- associative arrays

- scoped untyped variables

- flexible choice of procedural versus OO (ksh is only procedural)

- perl -d (debugger - no such thing for ksh)

- perl's regexp engine is better than awk/sed's without needing to shell out

- perl's hashes are more flexible and scopable than formula engine's (Formula Engine provides only a single global hash).

- perl can communicate more effectively with background processes.

The problem is, how do such features compare with Java? I don't know enough Java to know what to look for, (other than an impression that there are open source Java libraries versus CPAN modules) although I can manage to put together the comparative study for Perl versus C++. Anyone out there know enough Perl and Java to be able to say how Java would compete with Perl for fulfilment of the same benefits? (Although I want Perl to win, I still have to be scrupulously honest and fair to win the case.)

-M

Free your mind

Comment on A Perl vs. Java fight brews
Re: A Perl vs. Java fight brews
by adrianh (Chancellor) on Jul 24, 2006 at 14:06 UTC
    I have four colleagues, none of whom have Perl experience. The colleagues agree that change is necessary but are of the opinion that Java should be the language of choice (there is more Java in the original system than Perl, although the manufacturer has written a Perl API (= some modules) as well as a Java API).

    Although it's not the answer you're looking for but if I had a team with four Java folk, and a system that was already partly implemented in Java, I'd just do it in Java. Not because of technical issues, but because of social ones (more Java skills in house, no need to retrain, etc.)

    However - to your original points:

    - greatly reduce the spawning of new ksh processes
    - ready interface to unix system services
    - Open3 to control input and output between existing utility programs

    All these apply equally well to Java

    - CPAN

    A possible win - but only if you can point to the bits of CPAN that will actually help this particular project get implemented more quickly.

    - associative arrays
    - scoped untyped variables
    - flexible choice of procedural versus OO (ksh is only procedural)

    Java has hashes. In any case - you need to argue why these things are good for your project.

    - perl -d (debugger - no such thing for ksh)

    I'd say Java has better tool support (debuggers, IDEs, refactoring, etc.) than Perl.

    perl's regexp engine is better than awk/sed's without needing to shell out

    Potential win for Perl.

    - perl's hashes are more flexible and scopable than formula engine's (Formula Engine provides only a single global hash).

    Java has other data structures too. You'll need to argue that Perl's are better for you application.

    - perl can communicate more effectively with background processes.

    So can Java.

      Java has had regular expressions for years. They've even implemented the named capture syntax that we won't have until perl6.

      ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

        Java has had regular expressions for years. They've even implemented the named capture syntax that we won't have until perl6.

        I didn't think they were as flexible as the Perl ones (e.g. using composition to build up regexes from component regexes, //e, etc.)?

        However I freely admit I could be wrong. It's been several years since I've done any serious Java and I'm too lazy to look things up :-)

        Though regex support in Java was introduced several years ago (but not that many: JDK 1.4 AFAIK, 2002 circa, if we mean the java.util.regex package), it still doesn't offer advanced things such as match-time code evaluation, match-time pattern interpolation and conditional interpolation.

        So, for example, with a Java regex you can't build a recursive pattern (to check for instance if the parentheses in a text are balanced), while in Perl you can ;-)

        Update

        It can also be interesting to see how more verbose Java regexes are compared to Perl regexes.
        Here is a simple Perl example:
        my $pat = qr/a+b/; my $res = "aaab" =~ $pat;
        and here is its Java counterpart:
        import java.util.regex.*; Pattern pat = Pattern.compile("a+b"); Matcher mat = pat.matcher("aaab"); boolean res = mat.matches();
        Really, the above 2 last lines could be substituted by the following somewhat shorter code:
        boolean res = pat.matcher("aaab").matches();
        but if you don't explicitly instantiate a Matcher object, you can't have several things such as match, prematch, postmatch etc. which Perl gives you for free (through the various predefined variables $&, $`, $' etc.)

        Ciao, Emanuele.
      No they are not Java folk - they are ksh folk whose argument for Java is rather superficial in my opinion, though that doesn't automatically mean they are wrong, of course. But thanks for continuing with your analysis! At least it warns me that I have to find out how to code these Java features for the Java vs. Perl benchmark tests - what I forgot to ask is what about comparative development time for a typical routine in Java vs. Perl - such costs will also have to be taken into account by management.

      As I understand it, Java uses its own virtual machine - isn't that going to be slower than perl's use of the real machine via C, for example when using IO services?

      -M

      Free your mind

        If the folks are old shell script hands, I would pitch perl as a better shell language. In particular, if the project is ported to perl from the shell scripts, it will probably proceed faster than if it is coded from specs in either Perl or Java.

        Off the top of my head guesses about performance, aren't going to help you. Run some timings of typical things your system does. If Java wins I'll be surprised, but if the margin is large I'll also be surprised. Java has had a lot of optimization attention over the years, I'm guessing some of that paid off.

        Phil

        How important actually is raw performance? Generally algorythm changes will make much more difference to performance than the difference between two somewhat similar languages. If one language supports a better technique more easlily than the other then that may be important, but raw speed differences between Java and Perl are unlikely to matter much for most applications.

        Can you show us some sample ksh? Is it more like Java or Perl, or so completely different that it doesn't matter?

        Remember that the important thing up front is how easily your team will be able to retrain to use the new language efectively. That can be helped a lot if there is at least one person who is competent using the new target language. Everyone flapping around together generating poor code and making bad implementation choices while learning the language is likely to cause problems for much longer than it takes everyone to become competent with the new language.


        DWIM is Perl's answer to Gödel
        Since you're mostly porting from ksh, can you find a mostly shell-ish example that ports nicely and readably into Perl, then port it into Java as well. It's good to be able to say "We have a fair amount of code like this, and look how similar it looks in Perl. It just has some of the anoyances cleaned up. The Java for this looks pretty awkward." It has to be representative of a fair amount of code, but it doesn't have to be representative of all the code for your point to be important. People care about the parts Perl will make nicer, and the parts Java will make nicer. You want to do a good job of presenting the Perl side, for your body of code. The things Perl takes from shell scripting should help a lot. A good example is powerful in guiding thinking.

      I’d say Java has better tool support (debuggers, IDEs, refactoring, etc.) than Perl.

      It also needs them far more badly than Perl. Not only is Java generally more verbose, but it is deliberately designed to prevent you from abstracting your code past a point. As a result, large Java systems grow quadratically with the number of interacting parts in the system – and without tools, well, you aren’t exactly lost, but it’s going to be really unfun.

      (I was going to say that the only thing Perl is still missing is a really good graphical debugger for people who prefer working with them (I prefer logging, but I acknowledge that it’s not the same for everyone), but then I remembered Devel::ebug, and now I’m not entirely sure.)

      So to the OP, I would suggest reimplementing some small but significant portion of the system in both Perl and Java, and see how large they grow. It is a demonstrated fact that bug counts are invariably linear with the size of the codebase, even though noone has a deep understanding of why; it is also common experience that maintenance effort grows faster than linearly with the bug count. Java solutions almost always cost more and take longer than ones written in a more expressive language. I’m not even advocating Perl in specific here – pick Python if you want to, just stay away from the Java albatross.

      Makeshifts last the longest.

        It also needs them far more badly than Perl

        No argument from me there. I'd still like a good refactoring tool for Perl though.

Re: A Perl vs. Java fight brews
by philcrow (Priest) on Jul 24, 2006 at 14:19 UTC
    It's been a while since I did any serious Java, but I was in a Java shop at my last job (I left it in 2003).

    First, Java may be a good choice if that's what your team knows. But, I wouldn't think of it as an ideal text processing or glue language.

    Now for your points:

    - greatly reduce the spawning of new ksh processes
    If you're going to interface with java language libraries you too will have to spawn jvms or use Inline::Java or something similar from a vendor. If you're going to use Perl's system command, Java has something similar.
    - ready interface to unix system services
    Java tries to be OS agnostice, so you probably win this point. You won't find core routines like getpwent etc.
    - Open3 to control input and output between existing utility programs
    Java has sophisticated IO classes, but sophistication is not necessarily a substitute for simplicity. I would take a typical example and code it up in Perl, then ask an oponent to do the same in Java and have a discussion.
    - CPAN
    Of course, I think there is no substitute for CPAN. But, to be fair, there are lots of Java libraries floating about. It's just the central collection that's missing (and possibly the volume of truly free code).
    - associative arrays
    Java has hashes, using them is more tedious than in Perl since Perl has built in operators to deal with them. That is, Java will require something like value = hash_name.get( key_name ); instead of the more compact value = hash_name{key_name}. This is magnified for, two or three dimensional hashes, for example compare $myhash{$key}{$key2} to myhash.get(key).get(key2). Further, you'll need to write some String only hash classes for yourself or suffer interminable type contortions (these roads I have travelled). To demonstrate, build up some simple HoAoH or other similar structures and the code to load and access them in Perl and Java. This will be your strongest demo. Don't let them talk you into complex class heirarchies when a HoHoAoH would do.
    - scoped untyped variables
    They are going to be very skeptical of untyped variables, so they aren't necessarily a selling point.
    - flexible choice of procedural versus OO (ksh is only procedural)
    This is a sword the cuts both ways for Perl. ksh and other shells are procedural (and, horrors, the procedures must come before code that calls them). Java on the other hand is object oriented only (I call this OOO). Flexibility in a glue system is a big win. Since your original system was procedural, it would be nice to keep that basic structure. Java won't easily allow that. Since your original system had hard to manage data, it would be nice to introduce objects. Shells won't allow that. Perl allows both in spades.
    - perl -d (debugger - no such thing for ksh)
    Java has a fine system for debugging and profiling, including hooks to write your own debugger. This is a wash in the comparison.
    - perl's regexp engine is better than awk/sed's without needing to shell out
    Again, Java has regex support, but it is via function calls instead of operators. People think Perl looks like line noise in large part because of the regexes. I think Java looks like line noise because of the parentheses and dots.
    - perl's hashes are more flexible and scopable than formula engine's (Formula Engine provides only a single global hash).
    Java doesn't have scoping problems. But it does have method only hash syntax and hash elements must be objects. As noted above, this leads to a big win in code simplicity for simple strutures in Perl.
    - perl can communicate more effectively with background processes.
    Except for the usual verbosity arguments against Java, it is OK in this area.

    Phil

    p.s. It won't kill you to write in Java, but you might need a better keyboard for the extra typing.

      Thanks for your helpful pointers. Code equates to money and training would be needed in equal measure for either language. So if all things are reasonably equal technically, management would still be easily swayed if they have to pay say double in man-hours for Java versus Perl to develop the same thing.

      -M

      Free your mind

      Java will require something like value = hash_name.get( key_name ); instead of the more compact value = hash_name{key_name}. This is magnified for, two or three dimensional hashes, for example compare $myhash{$key}{$key2} to myhash.get(key).get(key2).
      Don't forget about the need for casting, which makes matters worse. Java "hashes" (Java has many basic hash types, so you have to choose an implementation first) can contain any kind of object, so when you retrieve a value, you have to tell it what kind of object it is, before you can do anything with it. So your nested hash example really has to become more like
      value = (datatype)((hashtype)myhash.get(key)).get(key);
      where datatype and hashtype need to be replaced with the real class names for the kind of objects you're using. Are you appalled enough, yet?
        Don't forget about the need for casting, which makes matters worse...
        Well put.

        This is what I was alluding to when I said this in passing:

        Further, you'll need to write some String only hash classes for yourself or suffer interminable type contortions (these roads I have travelled).
        You can usually get around constant casting by making some classes of your own that explicitly return String types, then all the casting happens in those classes. But it is still a pain.

        Phil

Re: A Perl vs. Java fight brews
by davorg (Chancellor) on Jul 24, 2006 at 14:34 UTC

    <heresy>
    If, as you say, your colleagues would need training whether you went for Perl or Java then perhaps it's worth considering something completely different.

    Ruby has all of the advantages of a dynamic language and doesn't have the (largely undeserved) bad reputation that Perl has. Perhaps your colleagues would be more interesting in learning something new and exciting like Ruby rather than something old like Perl.

    You'd still save the project from being implemented in Java and as a Perl programmer you'd almost certainly feel right at home with Ruby.
    </heresy>

    --
    <http://dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

      Unfortunately, I can't use your opinion in its summary form, I would need to present how Ruby matches up against the same checklist of technical features before I could it include it in the analysis - without that starting point I wouldn't know what to look for in the Ruby documentation when producing unbiased benchmarking code.

      -M

      Free your mind

        Ruby is basically Perl 5, only the language has less syntax and is much more regular (so much so as to manage to make closures feel natural even to Java wussies), has clean and out-of-the-box-useful OO; but there is no CPAN for it.

        If I were to start over learning dynamic languages now, I would quite probably pick Ruby over Perl 5 – but I stick around because I already know Perl 5 very well, and Ruby doesn’t offer substantially more expressiveness and power.

        Ruby also has the advantage of being fresh and getting hyped right now, so might be an easier sell than the “crufty” and “write-only” (etc yadda yadda) Perl 5.

        Makeshifts last the longest.

Re: A Perl vs. Java fight brews
by iguanodon (Curate) on Jul 24, 2006 at 15:01 UTC
    I'll state up front that I would choose Perl for the task you've outlined. But then I'm responding to a post on perlmonks, which might reveal a little bias.

    One question I'd ask you is: do any of your colleagues have Java experience? If nobody has any Java experience but one member of the team is proficient in Perl, then that makes a big difference. If on the other hand 4 out of 5 team members have used Java, it's going to be a lot tougher to sell Perl.

    greatly reduce the spawning of new ksh processes
    If I understand the requirements correctly, I think Perl would be a better choice in this area because it's possible to do a lot of shell type operations directly in Perl code.
    ready interface to unix system services
    Similar to the above, Perl is much more "unix-ish" than Java. An example of something that is much more difficult in Java is manipulating file permissions. There is no chmod in Java.
    Open3 to control input and output between existing utility programs
    If you mean using pipes, I can't comment because I've never done that with Java. What I can say is that file I/O is a lot more work in Java compared to Perl. In Java you don't just open a file and print $fh "foo", you have to deal with a bunch of confusing APIs. Similarly, there is no @lines = <$fh> in Java, and reading from files involves more, different, confusing APIs.
    CPAN
    This is a clear win for Perl. There is no equivalent repository for Java. I think the amount and quality of available Java libraries has increased a lot in the past few years but it still takes a lot more time to find and evaluate the options.
    associative arrays
    There are several hash-type structures available in Java. You'll find them harder to work with than Perl's hash though. First, you need to decide whether you need a Map, HashMap, Hashtable, TreeMap, etc. You can store just about anything in these structures, as long as it's an object. But then when you go to get something out, you'll need to cast it back to the proper type of object before you can do anything with it. Then there are the sorting issues. Some of these collections can't be sorted, period. Others can be sorted, but if you want to sort in an order different from the "natural order", you'll need to write your own Comparator class. This is a great example of where I gripe that I wish I was using Perl instead.
    scoped untyped variables
    Scoped, yes. Untyped, sorry, Java don't do that.
    flexible choice of procedural versus OO (ksh is only procedural)
    Sorry, Java is OO only.
    perl -d (debugger - no such thing for ksh)
    I've never used the Java command-line debugger, but if you use an IDE like Eclipse, the debugging is actually pretty cool.
    perl's regexp engine is better than awk/sed's without needing to shell out
    Starting with JDK 1.4, Java has native regex support. There are also some third party implementations like Jakarta ORO and Jakarta Regexp. Like most things in java, using regular expressions requires more code than in Perl. I recommend Mastering Regular Expressions, it has good coverage of the available options for Java. Also, I've found cases where I was unable to port a regex that worked in Perl to any of these.
    perl's hashes are more flexible and scopable than formula engine's (Formula Engine provides only a single global hash).
    See my comments above on associative arrays.
    perl can communicate more effectively with background processes.
    I'm not sure exactly what you mean here. If you mean getting information about processes that you didn't spawn, the Java security model will probably make this difficult.

      Thanks for your insightful comments. In regard to communicating with background processes, some related Perl coding examples of what I mean can be found in the Interprocess Communication chapter of Programming Perl (3rd edition) by Larry Wall - can Java communicate this flexibly with its children? Does it have forks, threads, etc. anyway?

      -M

      Free your mind

        Thread support in Java is pretty robust, and I think that's the way you'd handle this type of problem. Rather than forking children and communicating with them, in Java you'd use threads to do the work.

        If you really need processes, this could be a big selling point in favour of Perl.

        Java fork emulation is a real pain in the ass: you basically have no easy way to fork the current process, so you have to call Runtime.exec() and pass it the Java class to execute. This fires up a new JVM, which takes a lot of CPU and memory. Then, you'll also have major problems in communicating between the various JVMs, since Java does not (natively) offer anything like pipe or the inter-process communication tools offered by the various IPC::* modules, so you basically have to resort to JNI, or you have to use sockets, RMI, or even CORBA (one can also resort to EJB, that's true, but this could be an overkill and an unmistakable source of major headaches).

        As for threads, though it's true that Java prefers threads over real processes (and their implementation in Java is robust), it is important to stress that threads are not real processes.
        For instance, real processes will seamlessly migrate over an SSI cluster of machines (as long as they don't use shared memory), while threads will not.
        Also, an application based on real processes rather than on threads is much more robust, since each process runs in a separate address space while threads all live in the same address space, so that a single thread crash can bring down the whole application.
        And forking a new process is only marginally slower than creating a new thread, on systems that use Copy-On-Write (basically any modern *nix).

        Ciao, Emanuele.

      Sorry, Java is OO only.

      I keep hearing this, but it makes no sense. A class filled with static members and methods is no different than a package filled with global variables and functions. Perl uses a methods as subs approach. Java uses a subs as methods approach. The syntax is different, but both are capable of procedural and OO programming.

        Yes, you can make all static classes and put a driving script in a main method in Java. But, not matter what, you must put all of that in a class. Hence the charge: Java is Object Oriented Only. We say this, because every single line of operative code must be in a method and every single method must be explicityly placed into a class. You can't just write a driver:
        print "driver starting\n"; `call_system_util1`; `call_system_util2`; print "driver finished\n";
        The equivalent code in Java must be in a method of some class. That's overkill in this case and it buys nothing except tedious typing, which is why we make the charge and it sticks.

        There are two subtle bits of syntatic sugar here. First, Perl puts things in the main package by default. Second, code does not have to appear in a method/sub/function/whatever. It can just go in a driving script. Perhaps these differences seem small, but they are real.

        Phil

Re: A Perl vs. Java fight brews
by Herkum (Parson) on Jul 24, 2006 at 17:14 UTC

    One thing other people have not pointed out is that there are significant differences in the way you program for Java vs. the way you program in Perl.

    Perl can be OO, procedural or a mix of both. Java is Object-Oriented only!

    For some people OOP will be an issue, especially for someone who is used to procedural or batch programming. They will struggle with it horribly till they figure it out. In the meantime, the code they write will be of little value in the long run and be scrapped as it's short-comings become obvious( for example stability ).

    Another issue is that Java language offers little functionality; the power of Java is in its libraries. Instead of learning a language your programmers are going to be learning libraries, lots and lots of libraries and how to put them together. Once again count upon a high learning curve.

    Perl is a pretty good intermediary between UNIX scripting and Java. If you can get ahold of objects in Perl, the syntax and structure is very similiar too Java. It can be vehicle to move to Java for those with an interest in the language.

    Another major point I want to make, if they convince management that Java is the way to go; they might convince management they need to hire someone with Java experience rather than train current employees. There are plenty of companies that are willing to do Java development and they may convert themselves out of a job.

    Note: This is not an attempting at putting down Java; converting a program to another a language based purely on its abilities is not going to be the only thing to consider. Sometimes people forget that a business is being run and people on the business side, while not looking over directly over their shoulders, are watching.

    If a project is struggling because the current programmers are not coping well with a new programming language, regardless of their enthusiam for it, a company may seriously consider out-sourcing the project to someone with more experience.

Re: A Perl vs. Java fight brews
by samizdat (Vicar) on Jul 25, 2006 at 01:43 UTC
    I'd definitely agree with the comment above that people comfortable with Korn shell will adapt more easily to Perl than Java. Java is an incredibly wordy, _boring_ language that takes forever to code. (Yes, I've done it) I also just (at Sandia) was involved in maintaining several web systems that were completely implemented in ksh scripts as Apache CGI. I replaced some of them and added functionality with Perl scripts, which dropped quite nicely in.

    A Java system is of necessity a complete rewrite. I think that's the only point that I don't think has yet been made in this thread. Perl can be introduced script by script, and that's a huge advantage when dinking with a production system.

    Think long and hard before choosing Java because "it's the 'right' choice for enterprise development." :D

    Don Wilde
    "There's more than one level to any answer."
Re: A Perl vs. Java fight brews
by Skeeve (Vicar) on Jul 25, 2006 at 08:25 UTC

    I don't know, whether or not this is relevant:

    In 2003 I was member of a team that developed programs and scripts for one of the major financial institiutes here in Germany. They used Perl! The teamleader selected perl over Java because the development cycles are much shorter.


    s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
    +.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
Re: A Perl vs. Java fight brews
by exussum0 (Vicar) on Jul 25, 2006 at 10:45 UTC
    - ready interface to unix system services
    Java 5 has a bit more sophisticated process management, but nothing directly related to unix.
    - Open3 to control input and output between existing utility programs
    You have this via the Runtime and Process objects.
    - CPAN
    It depends on how you look at CPAN. CPAN as something that provides API to basic needs? Java does it as well. More complex systems and these super algorithms and language changing modules, like WWW:Mechanize, Algorithm::Loops and pugs, no, java doesn't have it.
    - associative arrays
    Map object.
    - scoped untyped variables
    You can do some scoping, but not untyped.
    - flexible choice of procedural versus OO (ksh is only procedural)
    You can do non-oo in java, regardless of what the nay-sayers say. Just define all of your methods as static. You still have to refer to them as say ClassName.myStaticProc(...).
    - perl -d (debugger - no such thing for ksh)
    jdb
    - perl's regexp engine is better than awk/sed's without needing to shell out
    jakarta oro can do about anything perl5's regexp's can do, except commenting, execution of code w/i a regexp.
    - perl's hashes are more flexible and scopable than formula engine's (Formula Engine provides only a single global hash).
    dunno what this is
    - perl can communicate more effectively with background processes.
    In what way? You can kill, get the status of and read/write from background processes. Fork 'em off and what not.
      In the OP I listed the advantages of Perl vs ksh, rather than Java which is what I wanted to know rather than express - I expect ultimately to have to make nC2 comparisons where n is the number of languages, probably in the set {ksh, Perl, Ruby, Java}, the way things are looking.

      -M

      Free your mind

        Whoops ^^ In comparison to java, THE things that yell out at me is:

        - a single algorithm in perl can be far more terse than java can be because a lot of the syntax, java forces verbosity, which in the end CAN lead to more readable code.

        - perl is very flexible, and easy to work with higher algorithms while remaining loose. it's hard to desccribe. so you get these things like mechanize.

        - java is very rigid, you gain a LOT of flexibility via patterns of use

        - java has type safety. It's really hard to not see when you missassign things beyond casting. IDE's such as eclipse and intellij make it harder to create these scenarios.

        - java can be bit more OS agnostic than perl is. Example, all filename slashes are can be written as /. All gui's can be written using swing. There are bugs in the jvm implementations that cause quirks, that do get fixed over time. I think it's more fun than dealing w/ perl/tk. I can copy a tomcat installation around from a windows box to a unix box and not recompile a thing if i start up the jvm properly.

        - java requires no c like compilation to extend, as they are written in java. java has the wretched classpath, when mixed w/ a classloader, can be a small pain to deal with

        - perl has constructs that are magnitudes easier than java will be, by design. $x[@index]=@values vs a java loop.

        - the perl community seems to be more creative, where as the java community is more goal oriented. I'd argue thta the perl community is more about coding for the love of it first, and the java community more business oriented.

        - java changes more frequently than java, but is more easy to install. perl is almost everywhere, more so than java, and does not change so often. I would attribute perl's quality there to being quite flexible to begin with. I'm not sure. Not looking for an argument :)

        I thought of a few more while on the train. Go vote the other node I wrote up if you like this node, so I can rid myself of the "zomg he's point whoring!"

        - Perl, mostly, by the nature of how things are compiled live from source, is more opensource than java. You CAN decompile java, but that's just an extra step and the decompilation isn't always pretty. I'm sure B::Deparse would do the same of a loaded module, but then, you can just vi that file :)

        - java is less forgiving of dependencies missing. i.e. you can't compile something that's needed by your source code. In perl, it's harder to get an error due to some bad usage of a module. Autoloader can make for fun times w/ that. :)

        - the various odd perl errors you get are findable in perldiag, where as java lacks such a mechanism.

        - perl's documentation comes with perl. java, not so much :)

        - java is backed more by money, where as perl is backed more by community, it seems. then you can get into the entire enterpriseness of both. guh, i hate that argument.

        perl is just an acronym, java is an island and coffee. tell me the name isn't just cooler :) /hides

Re: A Perl vs. Java fight brews
by bart (Canon) on Jul 25, 2006 at 11:42 UTC
    For me, the choice simply boils down to this: how easy is it to write something in Perl, and in Java? In my experience, Java is very verbose, with lots and lots of explicit layers (converting strings to byte buffers to ...) that you don't need in Perl, so you can easily end up with 2-3 times the amount of code in Java than in Perl.

    So I recommend the approach as advocated by Aristotle: write a significant part both in Perl an in Java, and compare how hard it was, how big the code is, how feature rich, and how many bugs you can find. For good measure, It'd throw in a few more languages, at the very least, Python. That way, you will not give the impression of being a stubborn hardhead, and people will be more willing to listen to your arguments. And, you and your people might like it.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://563254]
Approved by Corion
Front-paged by grinder
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2014-04-21 02:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (489 votes), past polls