Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Is Java really better than Perl???

by Roger (Parson)
on Apr 20, 2004 at 08:34 UTC ( #346565=perlmeditation: print w/ replies, xml ) Need Help??

Dear brothers, urgent help is needed! My company is going to halt all development on Perl in favour of Java. The following were the arguments they came up with.

1) To consolidate the total number of languages in use by the Competency, leading to more efficient use of staff

2) Unsuitability of the language itself for large-scale development i.e poor IDE support, debugging support, GUI, Web work, etc - this was documented in the "Mid Range Language Strategy Document" last year.

3) There's nothing you can do in Perl that you can't do in Java. This position was cemented by the Perl-Java bake-off which demonstrated Java to be at least equivalent in speed to Perl and after much grunting this was accepted, except by some "old crusties", I suspect mainly for INERTIA reasons.

4) In fact with the new design reviews, any Perl implementations will not get past that gate.

The only valid uses of Perl are:

1) utility scripting

2) legacy apps


As you can see, the person who came up with these "accusations" doesn't really have much idea about Perl, and certainly not the wonderful things Perl can do. And most of all, the honor of us Perl programmers are at stake.

Please help me to formulate a strong argument against these senseless accusations and show him that Perl is a truly elegant language and can do whatever Java does in less time.

Thanks very much in advance.

Comment on Is Java really better than Perl???
Re: Is Java really better than Perl???
by EvdB (Deacon) on Apr 20, 2004 at 09:11 UTC
    It is difficult to counter general arguments without ending up in a "Oh yes it is", "Oh no it isn't" type discussion.

    It would seem that your company may be suffering from plain sailing boredom. This is where everything is ticking along nicely and so the managers get bored and decide that something needs to be changed. After all it is only big decisions that count, right?

    Why not have a weighted vote? Give coders 4 votes, managers 2 votes and anyone else one vote. Ask something like "Should we exclusively use Java for all our development?". If you lose live with it or relocate.

    Before having a vote have a whole company meeting and get the two sides to slog it out and answer questions from the floor.

    Whilst you're at it get your company to consider "The only hot beverage should be coffee, tea is for old crusties".

    --tidiness is the memory loss of environmental mnemonics

      More specific answers:

      1) To consolidate the total number of languages in use by the Competency, leading to more efficient use of staff

      This is highly dubious, the tough part of coding is getting the algorithms right, the language is just the way to tell the computer what to do. How far should this be taken - arguably you should continue and specify particular frameworks, tools, IDEs etc. You'll end up with code by numbers.

      2) Unsuitability of the language itself for large-scale development i.e poor IDE support, debugging support, GUI, Web work, etc - this was documented in the "Mid Range Language Strategy Document" last year.

      ie - it ain't perty. This is often a problem that I find - people who do not code do not like non GUI interfaces for lots of reasons - mainly lack of hunt and click. That document might want a bit of critique. There will be some valid points but if your team can't work as a team then it is not a team.

      3) There's nothing you can do in Perl that you can't do in Java. This position was cemented by the Perl-Java bake-off which demonstrated Java to be at least equivalent in speed to Perl and after much grunting this was accepted, except by some "old crusties", I suspect mainly for INERTIA reasons.

      There's nothing you can do in Java that can't be done in perl... There is also an important distiction between execution speed and develepment speed. Also consider development time to lifetime ratio - very important.

      4) In fact with the new design reviews, any Perl implementations will not get past that gate.

      Hmmm, unable to comment.

      Good luck fighting this.

        To consolidate the total number of languages in use by the Competency, leading to more efficient use of staff
        This is highly dubious, the tough part of coding is getting the algorithms right, the language is just the way to tell the computer what to do.
        While this is true, it's not an argument. If your company is programming in two languages, they need to hire skills for two languages - they have two options. Either hire two groups of people, one group is skilled in one language, the other is skilled in the other language. The drawback is that one group can't do the work of the other - unless you do some investment to train them. The other option is to hire people skilled in both languages. But those tend to be harder to find, and more expensive (and rightly so, because they are more able).

        Note that I'm not saying that it's always good to focus on one language (or OS, or platform, or colour of shoes, or whatever). I'm just saying that there are arguments (many of them having to do with costs in some way) for homogeneity - but there are arguments for heterogeneity as well (flexibility, spreading for risks). It's not a black and white decision.

        There's nothing you can do in Java that can't be done in perl.
        I don't think that's the argument. The argument is that there's nothing you can do in Perl that you can't do in Java - so there's no reason to keep Perl.
        There is also an important distiction between execution speed and develepment speed. Also consider development time to lifetime ratio - very important.
        Important, but not overly. In many cases, execution speed is far more important than development speed. If you have a website that makes it money from sales, and investing 2 programmer years to shave off 5 seconds of the transaction time leads to 10% less customers to leave before concluding the deal, it may be well worth the investment.

        Abigail

      Why not have a weighted vote?

      Because companies are not democracies.

      incidentally, I've voted -- on a few posts in this 'ere thread, because they're whiney and irritating. Some monks need to grow up.

Re: Is Java really better than Perl???
by fireartist (Chaplain) on Apr 20, 2004 at 09:26 UTC
    Do a supersearch, there are many other posts like this.

    Short answer: If the company is bigger than a couple of coders and one manager, then there's probably no chance of overturning the decision and if you try you'll probably just make enemies.
    • Either accept the opportunity to widen your skills working with another language and learn from it what you can.
    • Or, search for a new Perl job.
Re: Is Java really better than Perl???
by Abigail-II (Bishop) on Apr 20, 2004 at 09:34 UTC
    Please help me to formulate a strong argument against these senseless accusations and show him that Perl is a truly elegant language and can do whatever Java does in less time.
    I think you first have to invent a time-machine. Let's go over the arguments:
    To consolidate the total number of languages in use by the Competency, leading to more efficient use of staff
    That's a valid argument. Of course, it's not an argument for any specific language - just an argument to drop one or more.
    Unsuitability of the language itself for large-scale development i.e poor IDE support, debugging support, GUI, Web work, etc - this was documented in the "Mid Range Language Strategy Document" last year.
    Well, if you wanted a strong argument, you should have written an equivalent document last year. It should focus on how the languages are used in your company. If you have to turn elsewhere to find arguments, doesn't that mean you actually don't have a good argument yourself?
    There's nothing you can do in Perl that you can't do in Java.
    Depending on how you look at it. Certain programming techniques you can use in Perl you can't use in Java - but if you consider a program as a black box, you can't construct a Perl program that does things a Java program can't.
    This position was cemented by the Perl-Java bake-off which demonstrated Java to be at least equivalent in speed to Perl and after much grunting this was accepted, except by some "old crusties", I suspect mainly for INERTIA reasons.
    Well, there you lost another chance - note the past tense. Where was your input in the bake-off?
    In fact with the new design reviews, any Perl implementations will not get past that gate.
    Uhm, that's not an argument, but a policy, isn't?
    As you can see, the person who came up with these "accusations" doesn't really have much idea about Perl, and certainly not the wonderful things Perl can do.
    I can't see that. In fact, your arguments make me think that the decision wasn't taking lightly, and the judgement was made on actual research, and not based on an article read in some managers magazine. If all companies did such research before making decisions like that, the world would be a happy place.
    And most of all, the honor of us Perl programmers are at stake.
    Well, so is the honor of Java programmers.

    I think you have a couple of options:

    • Adapt. Start programming in Java. Explore new worlds.
    • Rebel. Refuse to write in Java. You may get fired.
    • Focus. Mainly write utility scripts. That's where Perl shines as well.
    • Trump. Write your programs in Java. Write them in Perl as well. Make sure the Perl ones are faster/resource friendlier/quicker to develop/more robust/more maintainer friendly, without the Java programs being mediocre. Do this for the majority of the programs you write.
    • Leave. Get a job elsewhere.
    Abigail
      Hi Abigail,

      Thanks for the responses. Actually I was only lately told about the decision. A Java guy who doesn't really know Perl (I have seen his code) came up with this idea, and because he is somewhat closer to the manager and at a level higher than me, the issue becomes nasty.

      1. Perl programmers were not consulted when this decision was made (by the Java programmer).
      2. General accusations were easier to write and sound like they have done thorough research but have really not.
      3. It's all to do with company politics.

        Well, perhaps the only recourse you have is write a clear document why it's not a good idea to drop Perl. Start with organizing - find out who else thinks it's a bad idea to drop Perl - a counter document carries more weight if it's signed by a multitude of people. Make sure the document focusses on why it's bad for the company to drop Perl. Make sure you can back up your argument with facts - just saying that it takes the same amount of resources (== money!) to develop an equivalent program in Perl than a program in Java doesn't say much. If you have figures (which means, you got to do some research) to back up your claims, your arguments will be much stronger. Remember that your document has to be better than the one of the Java guy - he has already won a major battle.

        Abigail

Re: Is Java really better than Perl???
by exussum0 (Vicar) on Apr 20, 2004 at 12:45 UTC
    1) To consolidate the total number of languages in use by the Competency, leading to more efficient use of staff
    Consolidation of technologies to a finite set is good. It is good when many technologies are used as well. I've been in shops that use 3 without a problem. No need for consolidation there. I'm now working in a shop that uses at least 7: 3 different shells, c++, java and perl. It almost works out, but we get a lot of duplication of smaller API functions such as, "getPrice()" like functions. If there is a lot of duplication or inability work due to multiple languages, it is a good move. If there are significant groups using the language, it may be a bad move.
    2) Unsuitability of the language itself for large-scale development i.e poor IDE support, debugging support, GUI, Web work, etc - this was documented in the "Mid Range Language Strategy Document" last year.
    Large scale development can be done well with coding standards. W/o, any langauge can be a clusterfuck. Java has great IDE and integration support, most likely, because java is very easy to parse. OOP does lend itself to GUI stuff, but Perl/TK DOES allow for it. But because Java's syntax is easy to parse, building gui's from a gui is a little easier, since code can be reimported back into a tool regardless how ugly the code gets.
    3) There's nothing you can do in Perl that you can't do in Java. This position was cemented by the Perl-Java bake-off which demonstrated Java to be at least equivalent in speed to Perl and after much grunting this was accepted, except by some "old crusties", I suspect mainly for INERTIA reasons.
    If most of your development team can write faster java than perl, then java is a better tool for them. I can write C++ with the best of them. But mine will not be as optimized. It's not a slight on perl. It's jsut a matter of what works for people. It's not about perl being bad. It's about finding a tool that works.
    4) In fact with the new design reviews, any Perl implementations will not get past that gate.
    Unless you can show that perl is a better tool for the company, you are not going to get anywhere. That will require convincing key people, and many developers, they can code better in perl. After all, it's baout making money in the end.
    The only valid uses of Perl are: 1) utility scripting 2) legacy apps
    If I cannot write scripts in a sufficient manner in perl, then perl would be a bad idea. If I can't do gui stuff in java well, then java is a bad idea. Whomever wrote that should be sent to a Systems Analysis and Design course. And maybe forced to witness what perl CAN do.
    Please help me to formulate a strong argument against these senseless accusations and show him that Perl is a truly elegant language and can do whatever Java does in less time.
    Simple. You need to show the pluses and minuses of each. Show how each would benefit the company in terms of interpolation with other systems... with people... You have to show that in the end, more money can be made. That means showing that it can work with current systems, new systems, with new developers, old developers. In the end, you aren't proposing just a language, but a system to work with. If java wasn't addressed in this manner, it too is a bad solution. In the end, a language would be used that no one understands and becomes nasty to implement.
Re: Is Java really better than Perl???
by perrin (Chancellor) on Apr 20, 2004 at 13:45 UTC
    PLease read some of the other responses to this sort of question on PerlMonks, and this article. To my mind, one of the strongest arguments against this "Unsuitability of the language itself for large-scale development" accusation is the large web-based businesses that chose perl over java, like Amazon, TicketMaster, parts of Yahoo, and CitySearch. The only truly large commerce site I know that makes extensive use of Java is eBay.
Re: Is Java really better than Perl???
by Heidegger (Hermit) on Apr 20, 2004 at 14:01 UTC

    Actually I must admit there is not much you can do about it. We are three programmers at our company. I was the only one programming a project in Perl. And I made a very functional website in Perl. I offered them to start the next project in Perl. There were two main reasons why we have chosen Java: first, the other two programmers didn't want to learn Perl, second, the manager thought it'll be hard to find a Perl programmer if we leave the company some time in the future. We have to admit that Java is mainstream and very popular - it is gonna be very difficult to fight against mainstream and common sense opinion.

Re: Is Java really better than Perl???
by zentara (Archbishop) on Apr 20, 2004 at 14:43 UTC
    Maybe this will assist you. Just announced today: Inline::Java

    Hey, look on the bright side....now that you are forced to develop in Java, it will take more hours, that means more pay for everyone. Ask your boss about that.


    I'm not really a human, but I play one on earth. flash japh
Re: Is Java really better than Perl???
by gregor42 (Parson) on Apr 20, 2004 at 15:47 UTC

    I certainly understand and have experienced such business initiatives and I can empathize with you about the the emotional upheaval such situations can cause. However I find your query taking on the persona of one who is playing to the crowd.

    Please help me to formulate a strong argument against these senseless accusations and show him that Perl is a truly elegant language and can do whatever Java does in less time.

    Clearly you have taken a side in the argument based on pre-conceived notions. I happen to agree with your statement, based on development time alone. I develop in BOTH languages regularly. I can state emphatically that it takes less development time to develop code using Perl than it does to develop Java. In the office I work in now, we also do a lot of ColdFusion work. The same can be said there. We have performed studies based on the work we've done for clients that show that as a rule CF development takes on the average 1/3 of the time.

    So why do we bother using Java at all? Because in some instances it's more appropriate to do so. For example, if my target was to write an application for a cell phone. Much of it is dictated by factors you haven't mentioned.

    I'm not going to address the points you have outlined because those before me (particularly Abigail-II) have addressed them already with great skill.

    Instead I prefer to ask you about the things you didn't mention. For example, what does your company do? Do you write code for internal use or for clients? If for clients, are they custom jobs or 'shrink-wrapped' software? What is your target platform? Do your developers regularly re-use each other's code? That last question in particular is a decent yard-stick for language monotheism.

    I have to agree with what has been said before me in that the algorithms are more important than the implementation medium.

    I suppose that what gets me is that you posted a node in perl-zealot forum titled Is Java really better than Perl??? but failed to ask the question yourself. Perhaps doing so might have been 'flame-bait' but I think as an approach to the problem it would have been more scientific. Modern software development is no longer an art form, it is a science and so in order to prove your hypothesis you need to equally attempt to dis-prove it.

    If your company already develops software using both languages then you should have statistical data available for how long it takes to develop software. If your argument is based on time alone, then I would suggest staging another 'bake-off' using more of an 'Iron Chef'-like format. i.e. Have a preset amount of time, a surprise theme, and have at it. Let the results be based on their articulation of the theme, subtlety of execution, and display of skill. "Flavor" is of course, always the deciding factor.

    Let the science speak for you. Don't allow yourself to be drawn into a 'mine is better than yours' rhetoric, rather prove your point via professionalism. That is what impresses business people most.

    - Gregor42



    Wait! This isn't a Parachute, this is a Backpack!
Re: Is Java really better than Perl???
by coreolyn (Parson) on Apr 20, 2004 at 16:37 UTC

    Sorry I have to 'whine'

      2) Unsuitability of the language itself for large-scale development i.e poor IDE support, debugging support, GUI, Web work, etc - this was documented in the "Mid Range Language Strategy Document" last year.

    What the F does IDE and GUI's have to do with the cost of doing business?????? Ug..

    I'm a command line commando and proud of it

      What the F does IDE and GUI's have to do with the cost of doing business

      Oh, I can think of a few:

      • Cost of purchasing/supporting multiple IDEs/editors
      • Cost of training people to use multiple editors/IDEs
      • Cost of having to implement the company-wide SCM policy in multiple environments

        GUI's do not increase real productivity. Knowlege does, GUI's 'dumb down' learning. Eliminate the GUI's -- now there's real cost savings. 1 command line commando can accomplish the work of an entire department of GUI programmers.
Re: Is Java really better than Perl???
by Vautrin (Hermit) on Apr 20, 2004 at 18:21 UTC

    I think that exceptions are the reason many people want Java over Perl. If you code anything in java, if there's even a chance of it screwing up -- by throwing an exception -- the compiler will yelp and whine and tell you that you need to catch SomeException e. This forces bad coders to code for the worst case scenario in the way they normally wouldn't. However, I have always thought that the java exception paradigm is rather dumb in that Java doesn't know what worst case scenarios to look for, it just guesses. A human coder doing his job properly would put in place the checks that java forces, without taking into account the checks java forces which are unnecessary. Add to that the fact that java code can be ugly, and I understand why some managers think java is better. Java, in some ways, forces coders to do better work, because there are some perl programmers out there who won't do an or die($!) when they open a file, etc. However, again, the java compiler is dumb, and this can make a coder rely too much on the compiler to catch bugs -- which may make it even harder to debug the program.

    As far as the lack of an IDE goes, your manager is dead wrong. Perl doesn't have a traditional IDE like Eclipse, or Netbeans because text editors like Emacs and Vi have all the functions of a traditional IDE. Perl also comes with a debugger, and you can get a Tk based front end for that if you don't like the command like. Add to that the fact that Tk and GTK offer widget sets comparable to Java, and you have another trump to the "Perl is command line only" argument


    Want to support the EFF and FSF by buying cool stuff? Click here.
        Well, I guess there are IDEs. Perhaps I would have been better off saying that you don't need an IDE. Even when I code in Java or C++, I always use Emacs and have never needed Netbeans, or Microsoft Visual Studio

        Want to support the EFF and FSF by buying cool stuff? Click here.
      Checked exceptions in java are a very BAD thing, causing programmers not to think about what they catch, so often they catch Every exception, resulting in exceptions that essentially have an empty block as error handling code, or just get logged.

      Meanwhile, traditional programming means validating error codes. If you don't do that (check return codes), you are, simply put, not worthy to demand your salary.

      There should be quite a few articles on the evils of checked exceptions on Google ... java is one of very FEW languages that has them.

        Not that I like checked exceptions at all, but...

        Checked exceptions in java are a very BAD thing, causing programmers not to think about what they catch, so often they catch Every exception, resulting in exceptions that essentially have an empty block as error handling code, or just get logged.

        Meanwhile, traditional programming means validating error codes. If you don't do that (check return codes), you are, simply put, not worthy to demand your salary.

        Surely checked exceptions and return values have the same affect at this level. A competent developer will handle all the exceptions just like a competent developer would handle all the error codes. The error code approach offers no advantage over checked exceptions apart from the fact that it's easier to ignore error codes - which as you say is not a good approach.

        java is one of very FEW languages that has them

        I don't think anything apart from Java supports them - which is probably an indicator of their general utility ;-)

Re: Is Java really better than Perl???
by jacques (Priest) on Apr 20, 2004 at 20:56 UTC
    the honor of us Perl programmers are at stake.

    Your honor is at stake only if you let it be. If you really need this job, then stay and learn Java. That's what I would do. Life would be boring if opportunities to learn new things did not exist. Take this opportunity and run with it.

Re: Is Java really better than Perl???
by leriksen (Curate) on Apr 21, 2004 at 01:40 UTC
    Well, to take these in order

    1) would they rather use a knife than a screwdriver to undo a screw ? Choose the tool most appropriate to the task at hand - dont use a candle to melt steel and dont use an axe to slice bread. Most developers (rather than managers) will tell you that developers who know several languages are almost always better developers than mono-culture ones. And solutions that use several well integrated, task-oriented language componenents are better than one huge, monolithic, ill-adapted single language design.

    If you have four developers who are handy with Perl, Java, C++ and SQL, surely they can achieve vastly more than four purely Java developers.

    A building company that only has plasterer's could in theory build a house completely out of plasterboard, but would you really want to live there ??

    OK enough with the analogies

    2. Does C generally have a pretty IDE ? Is it suitable for large scale development? Perl has Komodo from ActiveState if a developers are so imcompetent that coding without a GUI is impossible. If a developer said you can't code seriously without a GUI, I wouldn't hire them.

    Perl has an excellent debugging/introspection available via the -d switch, the Devel::ptkdb GUI debugger is superb, debugging tools include the Deparse modules and Data::Dumper, Perl allows the examination of @INC/%INC and symbol tables, the strict pragma and -w switch catch 80-90% of stupid errors straight off, flexible logging via Log::Log4perl, you can design with extensive parameter checking with Params::Validate, the wonderful Test::Harness framework will save you a fortune in time, money and frustration. I could go on.

    Web-work - they can't be serious. I wont even to begin to detail the absolute myriad of rock-solid, flexible, powerful frameworks Perl provides for web development. Unless they want everything done in Flash, Perl is easily a superb Web development tool - and infinitely superior to developing for the web in Java.

    GUI work - OK, they have there first genuine point here - Java is better than Perl for GUI development.

    3. There's nothing you can do in Java you can't to in binary. That's not a good reason for doing everything in binary. Similiarly for choosing Java over Perl.

    As for speed - runtime or development time. I can't think of too many cases where a Java developer will spend less time than a Perl developer implementing the same functionality. It doesn't matter if it took 5 hours to run or 6 hours, if Perl took a week to write and Java took a month. If raw speed is a criteria - do it in assembler/C.

    4. Well if an implementation is reject just because it is written in Perl - regardless of whether it works and actually satisfies the design, your screwed.

    Why not have a coding bake off between their best Java programmer and their best Perl programmer. A set of 10 exercises to be implemented correctly in the shortest space of time. I bet the Perl guy would win. By days...

    hopefully others can provide links to the myriad of articles about how good Perl is.

    One last point that may break their 'perl is for scripting' mind-set - Perl is a PROGRAMMING LANGUAGE and an extremely powerful one at that - in fact one could quite easily argue that, featurewise, Perl is much more powerful than Java.

    +++++++++++++++++
    #!/usr/bin/perl
    use warnings;use strict;use brain;

      If you have four developers who are handy with Perl, Java, C++ and SQL, surely they can achieve vastly more than four purely Java developers.
      Not sure what you mean here. Four developers, one handy in Perl, another in Java, a third in C++, and the fourth with SQL? Or four developers handy in four languages? People good in multiple languages are harder to find, and cost more. It's not clear whether the company gets more bang for the buck that way. Furthermore, even if all your programmers can program in all languages, it's not clear at all it's good to actually write in different languages. And that's because of code reuse. You can't easily reuse your Perl module in your C++ program, or your Java class in your Perl program. That means, C++ libraries, Perl modules and Java classes will be developed providing the same functionality. You must have a pretty good argument to sell that to a manager (or to me - and I'm not a manager).

      There's nothing you can do in Java you can't to in binary. That's not a good reason for doing everything in binary. Similiarly for choosing Java over Perl.
      You don't understand the argument. It's not an argument to pick Java over Perl. It's an argument to not keep Perl.
      As for speed - runtime or development time. I can't think of too many cases where a Java developer will spend less time than a Perl developer implementing the same functionality. It doesn't matter if it took 5 hours to run or 6 hours, if Perl took a week to write and Java took a month.
      Of course it matters. If you're at the dentist, you want the drilling to be done over with quick, and you wouldn't appreciate if he says "it doesn't matter that the drilling takes an hour, does it? They assembled the drill in a week instead of a month!".
      If raw speed is a criteria - do it in assembler/C.
      Speed is almost always a criteria. It seldomly is the only criteria.
      Why not have a coding bake off between their best Java programmer and their best Perl programmer. A set of 10 exercises to be implemented correctly in the shortest space of time. I bet the Perl guy would win. By days...
      Well, they had a bake-off. And Java won. But a bake-off you suggest is pointless. You shouldn't pit the best programmers together - but the average, or even the worst programmers. Furthermore, development time isn't everything. Resource usage, speed, maintainability and reusability are vital as well. Besides, if you do 10 exercises, they will all be short programs, which will give Perl an edge. It doesn't measure the suitability for large projects though, which is likely to be more important.
      hopefully others can provide links to the myriad of articles about how good Perl is.
      Whether Perl is good or not wasn't the question. There are a myriad of articles to be found saying how good Java is - probably more articles saying so then you can find articles saying how good Perl is.
      Perl is a PROGRAMMING LANGUAGE and an extremely powerful one at that - in fact one could quite easily argue that, featurewise, Perl is much more powerful than Java.
      Shouting doesn't help. Since you say that it's easy to argue that Perl is more powerful than Java, could you give some objective arguments, without becoming emotional?

      Abigail

        If you have four developers who are handy with Perl, Java, C++ and SQL, surely they can achieve vastly more than four purely Java developers.

        Not sure what you mean here.

        Sorry , I meant each of them was quite competent in each langauge/domain. And whilst finding developers good in multiple languages is hard, my position stands that that these developers will be be better at development (as opposed to using neat features of one language) than a developer who knows one language.

        You don't understand the argument. It's not an argument to pick Java over Perl. It's an argument to not keep Perl.

        but they support that argument with the justification that Java can do anything Perl can - my position is that that is not a sufficient reason in itself to drop Perl

        Shouting doesn't help.

        I wasn't shouting, I was adding emphasis.

        +++++++++++++++++
        #!/usr/bin/perl
        use warnings;use strict;use brain;

Re: Is Java really better than Perl???
by g00n (Hermit) on Apr 21, 2004 at 04:13 UTC

    There is a lot of Java V's Perl *advocacy*. Usually resulting in leaps of Aristotelian logic as to why one language is superior to (all) others.

      *Top 10 reasons Perl kicks {insert favourtite popular language}*
    Has anyone ever written a list of questions to fire to people who want to advacate another language over Perl?

      There's nothing you can do in Perl that you can't do in Java

    I laugh when I see this. So you use Java for *everything*? Langauges are tools. Use the correct tool for the task at hand. To pick an extreme example try using Java regular expressions for a project. Then compare the results using Perl regex's. This is but one example.

      ...how him that Perl is a truly elegant language and can do whatever Java does in less time...

    This is a tall order. What problems are you trying to solve? Is your work server side? Database intensive? Web transaction based? If you problems fall within the *strengths* of Perl you may be able to create a more convincing argument.

Re: Is Java really better than Perl???
by flyingmoose (Priest) on Apr 21, 2004 at 04:52 UTC
    Ah man, so you have java zealots too, eh? Well I feel your pain. I do feel that Java is a fair (notice I did not say good) language to use when you are amongst a lot of incompetant programs that need high-chairs and seat-belts to keep them from hurting themselves. It is easy for someone without discipline to lose an arm and a leg in perl. *HOWEVER* despite Perl being dangerous at the syntax level, Java is dangerous at the design level. The typical style encouraged by Java, and yes, evidencided by Java's own SDK, is an OO design which is not OO, and is in fact misleading -- essentially dropping encapsulation in favor of getters/setters everywhere, and also it shows massive problems in the overuse of the "inheritance is my hammer" phenomenon. Though I doubt you can win the war every time, a few things to remind folks about is that...


    1) Perl is faster and lighter for smaller apps.
    2) Perl requires less development time
    3) Perl is not controlled by Sun, thus anyone can submit bugs and they might actually get fixed. BugParade is a joke.
    4) Perl is *much* better at file I/O and integration with the OS, while Java makes a point of removing functionality that is OS specific.
    5) Perl offers a wider range of IPC options through CPAN, while Java offers the propretiary, haphazard RMI as a major selling point. Also Java XML parsers are not automagical as is XML::Simple.
    6) Perl has CPAN. What does Java have?
    7) Perl solutions will likely have less lines of code and will be easier to maintain
    8) Java has a huge memory footprint for the JVM and this will get larger as you load more classes into memory. Perl doesn't have this problem on the same scale.

    The most ignorant statement I heard was from a manager (not at my company, an older one) that said anything that can be done in Perl can be done in a shell script. True, I guess, but he was probably familar with the works of baby-perl scripters, and didn't really see the beauty in the language.

    In all, I still think Perl is dangerous for larger apps, merely because it is loosely tied together and a little random. But I love that. With great power comes great responsibility, or some such.

    I don't know how you really live with Java zealots, though, that's the hard part for me. I see crippled software with widely exposed interfaces, bad OO design everywhere, and they think they are doing it right -- but hey, I'm the low guy on the totem poll, eh? So what if I have the C.S. degree and they are math/business/tech school folks, right?

    Good luck in this one, and may the force be with you. Java is not better than Perl. They are entirely different animals. Perl, in many things is better than Java. Java has a leg up in industry acceptance and is a better tool for CONFORMISTS. I'm only hoping Perl6 can be expedited and become a buzzword in itself, since the rigidity is greatly needed in winning the war.

    Folks say there is no war, pick what you want, but when it's Java jobs eliminating Perl jobs, well, that's less Perl. I for one write Java and C/C++ for a living, and Perl scripts when I can. I get little credit for my C/C++ and Java, but the few Perl scripts I've written for build engineering, automation, and so on usually leave jaws dropping. I'm incorporating Perl applications where I can -- but fighting the bias against Perl means I can't rewrite all of our broken software in Perl just yet....

Re: Is Java really better than Perl???
by pope (Friar) on Apr 21, 2004 at 09:54 UTC
    I don't know whether this is a strong argument or not, but it is obviously a strong word: Java's fate will end with the same one as Neanderthals': extinction! :-)

    Also show this one to your boss: Java's Cover, make sure he/she doesn't miss the responses to this Paul Graham's essay by Tim-Berners Lee and Trevor Blackwell :-) And this, and this should be enough to make your boss staring at your Java friend suspiciously :-)
Re: Is Java really better than Perl???
by runrig (Abbot) on Apr 22, 2004 at 16:20 UTC
    3) There's nothing you can do in Perl that you can't do in Java.

    ...except get stuff done faster. For certain values of 'stuff' and 'done' (those values being the ones I care about).

      3) There's nothing you can do in Perl that you can't do in Java. ...except get stuff done faster. For certain values of 'stuff' and 'done' (those values being the ones I care about).

      And for other people you can swap the "Perl" and "Java" around :-)

      (also if you take platforms into account there are lots of things you can do in Perl that you cannot do in Java, and lots of things in Java that you cannot do in Perl.)

Re: Is Java really better than Perl???
by Anonymous Monk on Apr 23, 2004 at 16:34 UTC
    If your programmers are too stupid to learn how to use a good text editor and issue commands on the command line what makes you think that an IDE is going to make them any smarter. IDE's are mental crutches and I wouldn't hire a "programmer" that need to use one.
      IDE's are mental crutches and I wouldn't hire a "programmer" that need to use one

      Am I the only person old enough to remember similar things being said about full-screen as opposed to line based editors ;-)

      The line between an editor and and IDE is a fuzzy one. An IDE isn't a crutch, it's a tool. They can be used well or badly.

      Sure I can write Java and Objective C in a plain text editor. Sometimes I do. However I'm damned if I'm going to stop using things like XCode and Eclipse which give me useful features like integrated reference material, automated refactorings, integrated distributed compilation, source control integration, test framework integration, etc. out of some misguided idea of programming purity.

      One of the many reasons I'm looking forward to Perl 6 is that the OO system has much better reflection capabilities which means that writing automated tools to do things like extract-method are going to be way easier than in Perl 5. The more things I can get my editor/IDE to do for me the better, that way I can spend more time on producing useful code.

      Of course real programmers just whistle down the phone at 400 baud.

        300, not 400.

        Anyway, REAL programmers whistle at 110 baud, while walking uphill both ways through the snow.

        --
        TTTATCGGTCGTTATATAGATGTTTGCA

Re: Is Java really better than Perl???
by TomDLux (Vicar) on Apr 24, 2004 at 02:04 UTC

    It's much faster to write an application in Perl than in C or Java. Who can do anything useful in a comand one-liner in C or Java? Who can write a simple web site robot in 100 lines of C or Java?

    Once the prototype is function, and benchmarking shows a deficiency, I consider that an approrpriate time to re-implement a component in C ... a native module or a chunk of Inline::C. If you're going to re-implement Perl code for speed, it makes little sense to use Java for that.

    On the other hand, Inline::Java might be useful for interfacing to other Java code, taking advantage of other people's code.

    After all, "Use Existing Code" always gets more done, faster, than "Not Invented Here."

    Perl for fast implementation, C for fast code, Java when suitable for external code.

    --
    TTTATCGGTCGTTATATAGATGTTTGCA

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2014-09-16 07:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (157 votes), past polls