Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re: J2EE is too complicated - why not Perl?

by pg (Canon)
on Dec 07, 2003 at 05:26 UTC ( #312865=note: print w/replies, xml ) Need Help??

in reply to J2EE is too complicated - why not Perl?

Actually it is not even quite right, to view Perl and Java as competitors. Although in some areas, the two languages bump into each other from time to time, for most of the areas, it is quite clear why you should choose Perl not Java, or the other way around.

Perl is very useful for what it is good at, but I don't see any sign that Perl can support enterprise level requirements easily and comnfortably. Perl is mainly still a rapid development language for various tool-level needs.

As for J2EE, although it is quite complex, majority part of the complexity is actually hidden from application developers. J2EE provides the foundation, and application prorgammers just keep adding blocks on top of it. The fact that it can be used by lots and lots of people, clearly speaks for J2EE - the complexity exposed to end users is really not too bad.

(I have had some experience with J2EE, in fact my main work at this moment is a J2EE-based application, implementation phase. My feeling is that, to first set up the development environment and deployment/running environment is really complex, but once it is set up, writing code is not really a big deal, as long as you have a fair experience with Java.)

One nature of Perl is that, it is a very strong LANGUAGE, but it appears that people rarely get into research or implementation of ARCHITECTURES based on Perl or for Perl.

Everything has what it is good at, force it into areas that does not belong to it, does not do any good. Not be able to support enterprise solutions, does not make Perl less useful. On the contrary, the fact you and me are using Perl from day to day, speaks for Perl loudly.

  • Comment on Re: J2EE is too complicated - why not Perl?

Replies are listed 'Best First'.
Re: Re: J2EE is too complicated - why not Perl?
by chromatic (Archbishop) on Dec 07, 2003 at 06:35 UTC

    What exactly is an "enterprise level requirement" and why would I have one?

    I'm serious. I read and hear the word "enterprise" all the time and it seems mostly like self-congratulation. I know what it used to be -- servers that talked to servers -- but it certainly seems to mean something very different now.

      As a sysadmin for a government department for the last two years, I have come to the conclusion that 'Enterprise Software' actually means 'multiply the price by ten and remove the installation manual'.

      I realise this response will be taken as Gen-X-hip-cynicism by some readers, but after looking at the contracts some departments have signed and the monies paid for Enterprise Software, I hope that there were kickbacks involved because I don't want to believe that anyone could be that foolish.

      My personal 'enterprise level requirements' are software that is easy to install and doesn't crash more that once per month.

      Actually, thinking about it a little more, enterprise level software might be 'software that you can install in under two weeks, and that takes longer to crash than the minister takes to get bored with it'.

      I didn't believe in evil until I dated it.

        Enterprise software for me tends to mean, very flexible and very scalable. Let's take perl and php sans mod_perl and the php cachers out there. As a "web language", it's not enterprise level. But even then, perl has its advantages in how flexible it is. Flexibility gives it more power, 'casue in today's day and age, less flexible software, like dbase, isn't helpful. We need replication. Relational capabilities. Live backups.

        Peoplesoft is big because of this. They have a mamoth piece of software that's flexible to a point, and they have consulting services to further that felixibility. Apparently, it's also quite scalable too.

        Have you looked into vendor assistance in what contracts you are about to forge? Like a 1 month, reduced cost setup thing?

      For me, an example of an "enterprise level requirement" is a need for an accepted series of design patterns and underlying technologies for supporting software transactions accross multiple machine boundries with completely different transaction methodologies.

      For example having an atomic software transaction which needs to update a series of databases (perhaps Oracle and MS-SQL, as an example) as well as fire off some CICS transactions and to be incredibly nasty, an update to an LDAP system. This is where going with an IBM J2EE stack makes sense, and this is where they "shine" as an enterprise application framework. From monitoring the livelyhood of your system with a Tivoli installtion, to perhaps using MQ for asynchronous message beans (oh, it seems that the mainframes are busy doing reports for 1/2 of the day, and we need an infrastructure that provides transparent asynchronous transaction execution) to being able to leverage it with a bunch of webbie programmers by giving them a custom tag environment to work within from within JSPs, and knowing that this environment is multi server failover "guaranteed" due to Websphere server clustering.

      That's the sort of thing that's "enterprise" to me. 99% of the work in the software world is sure as hell *not* enterprise :) (At least in my humble experience...) Oh, and to finish off, yes, I do know that all of this is doable with Perl... hell, I'm sure it's doable with emacs lisp :) It's just that Perl doesn't have a quijillion dollar corporation betting their reputation on continuing to iterate through these tools and make them better and more suited to similar "enterprise" needs.

        Just curious -- have you ever actually written Java code to do the kind of thing you're talking about here (transactions across heterogenous systems), and if so, how difficult was it? One thing that occurs to me is that the high-end vendors who sell these database systems typically also sell some kind of two-phase commit option that will work across competitors systems, so that could be an option for systems built using Perl.

      Personally, I take "enterprise" application as application used in an organization that has a medium to large size, and the application is used across the organization, to support its main business functionality. The failure of the application usually has a serious impact on the organization's main business.

      Although complex business requirements usually end up with having a complex system to support it, it is not the complexity of the system we used to measure whether an application is "enterprise". (That's the result, but not the origin.)

      For example, the supply chain system I am working on now, I consider it as an enterprise solution. If it fails, the company cannot order from vendors, thus has nothing to sell and make profit.

      During the implementation of the project, I made some tool to generate DCO/DAO's for myself, this tool is obviously not an enterprise solution, even if I share it with other developers.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://312865]
and the rats come out to play...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (7)
As of 2017-04-24 17:46 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (443 votes). Check out past polls.