There is an interesting discussion thread on theserverside.com related to the complexity of J2EE.
It seems that many J2EE developers are disgruntled. Some blame J2EE for the exodus of jobs from the USA due to customer dissatisfaction. It seems that many J2EE developers feel that they where better off before moving into J2EE and evaluate J2EE as a failure. Some defend the complexity of J2EE as a necessary evil for things such as transactions, authentication etc.
I remember reading that Perl was supposed to fade away and that Java would become paramount. Yet it seems that Perl continues to thrive and grow as Java seems to be failing on the server as it has on the desktop.
My question is how suitable is Perl for high-end (like Banking, Insurance etc)applications. Is there an application server like approach available for Perl and how do Perl developers manage transactions and authentication and other activities thought to be only managed by J2EE and proprietary solutions such as SAP.
janitored by ybiC: Grudgingly formatted for legibility using balanced <p></p> to replace foul <br> tags
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: J2EE is too complicated - why not Perl?
by etcshadow (Priest) on Dec 07, 2003 at 04:50 UTC | |
Anyway, to the more interesting question about application frameworks like J2EE and similar things for perl, and the general question of complexity of things like J2EE... Well, my basic standpoint on this sort of thing is: of course it's complex. It's a complicated problem (more complicated than it seems to novices or, often, to stereotypical "suits" or "PHB"s, which fortunately the management at my company are generally not). Many of these problems include (at some level) some of the most difficult (often technically impossible at some level) problems in practical information theory: atomic transactional processing, distributed transactions, guaranteed delivery, cryptography, object-relational mapping, and many others. Some of these can be fairly cleanly abstracted. The cryptography can (ususally) be easily abstracted (often quite transparently) behind ssl/ssh/https. Atomic transactions can (if you know what you're doing) be abstracted into a relational database... but it can't always be transparently abstracted. That is, the programmer has to understand that there is an atomic transaction going on, and that it is being handled by the relational database. Some of these problems cannot be easily abstracted. Object-relational mapping, for example, is generally very hard to abstract, and frameworks that claim to do so transparently for you generally suck. They either kill your performance completely, or require you to work harder than you would have to if you were doing the object relational mapping yourself (as apropriate). Anyway, my point is this: hard programming is hard programming. There's often no getting around having to understand the difficult issues, even if you have tools that do a lot of the work for you. The real thing that J2EE did wrong was to try to sell the lie that it made difficult programming the province of low-grade coders, and that it somehow made applications written by shitty programmers automatically good and correct and robust. Ultimately, they took the approach of trying to dumb down difficult concepts, as opposed to trying to simplify complicated tasks, and that is why J2EE is on the decline. ------------ :Wq Not an editor command: Wq | [reply] |
by BrowserUk (Patriarch) on Dec 07, 2003 at 05:03 UTC | |
The real thing that J2EE did wrong was to try to sell the lie that it made difficult programming the province of low-grade coders, and that it somehow made applications written by shitty programmers automatically good and correct and robust. Ultimately, they took the approach of trying to dumb down difficult concepts, as opposed to trying to simplify complicated tasks, and that is why J2EE is on the decline. Bravo! I would have given you 2 ++s for that paragraph alone if I could:) I do have a question though. Object-relational mapping, for example, is generally very hard to abstract... I don't disagree with that statement, but I do wonder about the efficacy of doing "Object-relational mapping" in the first place. I realise that RDBMSs are well-tried and easily (if not always cheaply) available, and most OODBMSs are little more than a less than complete veneer over an underlying RDBMS, but is inconceivable to have an object store that doesn't rely upon mapping to a relational DB engine? | [reply] |
by etcshadow (Priest) on Dec 07, 2003 at 07:12 UTC | |
I realise that RDBMSs are well-tried and easily (if not always cheaply) available, and most OODBMSs are little more than a less than complete veneer over an underlying RDBMS, but is inconceivable to have an object store that doesn't rely upon mapping to a relational DB engine? That's a great question. I tend to think that relational databases really are a great tool. The thing that makes them so good is that they are both very powerful and very capable. This stems from the fact that, conceptually, they map quite well to the constructs we need in software and that the hardware demands. Relational databases organize data in a way that allows it to be efficiently managed on real physical data stores (hard disks and hard disk arrays). Think about how a full-table-scan translates to a sequential read off of a spinning disk. Think about how a table with a fixed structure can easily be translated into a fixed-width record and to blocks and sectors on a disk, and so on and so forth (lots more examples... but for the sake of being concise, I'l leave it there). The point is that the structure itself does a wonderful job of abstracting away the hardware, but in such a way that doesn't hide any of the best capabilities of that hardware. In short: they make a great abstraction of the physical persistence layer to your application. Likewise, what they provide to your application for the purpose of persistence is about the best that can be provided without trying to do too much (and, thereby, doing it poorly and/or making life hard for programmers). If you're not convinced that doing more for applications than they do would be problematic, just look at how much of a mess most object-relational mapping frameworks are. Also (on that note) if the object relational mapping were done at the persistence level, yielding you an object-store rather than a data store... well, then you'd be in a situation like CORBA, which is also proof by counterexample. There's two halves to saying that it does the right amount, though, and above I only defended the first half, that it didn't do too much... so let me explain why I think that it does enough, as well. Well, think about the data in your applications. In a C-ish world, you have structs, in a java-ish or C++-ish world you have objects' instance data, which is very much like a struct (note: I do not say that an object is like a struct; I say that an object's data is structured like a struct). And what's in a struct? Well, either "primitive" data-types, derived (non-primitive) data types (i.e. other "struct"-like entities). Depending on the details of your language of choice, you may have pointers or references included in your primitive data types or maybe that's how you store other derived data types... but take it as a given that you also (perhaps inclusively) have references or pointers involved as well. A relational database gives you table definitions, which are like struct typedefs, or like class definitions, or what have you... but the point is that they parallel how you declare your application's data structures. In those table definitions, you put primitive data types (numbers, character strings, dates) and you put references to instances of other (or the same) derived data types (i.e. tables). These, in the RDB world, are of course called "foreign keys". Anyway, summary of that long paragraph is that RDBs give you what you need to model your application data in the form of: Last of all RDBs give you things for free, that you're likely to end up wanting, regardless. To name a few: So, to the question, as you framed it: is it conceivable to have an object store that doesn't map to a relational DB engine. Sure it's possible, but I haven't seen much in the way of reasons to do it. The best example I can think of (which I acknowledge as an emerging possibility) are objects in languages, well, like perl... in which you don't necessarily have a fixed object "structure" as you do in java or C++ or C, etc. That is, that the objects are so amorphous that you can't nail down any kind of meaningful "structure" that covers every instance of the class. However, I tend to think of these free-form objects as typically having some kind of structure, it may just be a deeper structure than first appears. Also, there's the issue of subclasses which contain different instance data (and thus define a different structure) than their parents. To that I say: there's almost always a structure that represents the super-set of the structure of all of the relevant, related classes... define your table structure around that, and let the columns you don't need be null. Anyway... this is a cool discussion, but I'm tired now. ------------ :Wq Not an editor command: Wq | [reply] |
by BrowserUk (Patriarch) on Dec 07, 2003 at 15:20 UTC | |
by autarch (Hermit) on Dec 09, 2003 at 06:25 UTC | |
| |
Re: J2EE is too complicated - why not Perl?
by allolex (Curate) on Dec 06, 2003 at 22:07 UTC | |
Ah. For once I have all the answers ;) It seems that many J2EE developers are disgruntled. Well, the nature of Perl is to keep people gruntled. It might not be very couth to say it, but Perl is really a programmers' language at the very least for its superior expressivity. Some blame J2EE for the exodus of jobs from the USA due to customer dissatisfaction. Yes, J2EE is responsible for that and more, while Perl has contributed to resolving problems of world hunger (It's paying my bills) and promoting world peace through programmer satisfaction. The customer doesn't care, just as long as things work right and don't cost too much. It seems that many J2EE developers feel that they where better off before moving into J2EE and evaluate J2EE as a failure. Yes and yes! And why did that discussion thread page only render correctly the second time I loaded it? Could it be that those Java Server Pages (probably using a full J2EE stack to do some simple parsing and formatting) are overloading the poor machine? Some defend the complexity of J2EE as a necessary evil for things such as transactions, authentication etc. I remember reading that Perl was supposed to fade away and that Java would become paramount. People have been announcing the death of Apple for 25 years and it still a superior product. Yet it seems that Perl continues to thrive and grow as Java seems to be failing on the server as it has on the desktop. My question is how suitable is Perl for high-end (like Banking, Insurance etc)applications. Is there an application server like approach available for Perl and how do Perl developers manage transactions and authentication and other activities thought to be only managed by J2EE and proprietary solutions such as SAP. I really like what you are saying here. If you look for SAP modules on CPAN, you can see that Piers Harding has been, well, hard at work. (I think he owns all of the SAP modules). You should have a look at his site. It think Perl's advantage in this area is the amazing amount of modules on CPAN.
-- | [reply] [d/l] |
by DrHyde (Prior) on Dec 08, 2003 at 10:09 UTC | |
We've been using SAP::Rfc at work, and it's jolly good indeed. We're using it to replace the SAP Business Connector which is written in Java and about which I have muttered here before (see Correcting the SAP Business Connector). | [reply] |
by ajt (Prior) on Dec 08, 2003 at 12:29 UTC | |
As the first member of the above "we" to use Piers Harding's SAP::Rfc, I can say that using Perl in favour of a Java product has been a breath of fresh air We have a project that uses an Apache/Perl front end running on a Linux box to talk to a SAP/AIX system, via a Java based XML middleware tool called SAP Business Connector (BC). Some of our problems are not the fault of Java, but even then it's an evil product to use. It's very slow. The visual development interface makes easy tasks easy, and complex tasks impossible. So it's good in a demo, but hard in practice. It's XML processing is painfully slow when compared with Perl's, Perl is constantly waiting for data from BC. It takes for ever to develop and for ever in use! It's hard to debug. While you can step through the flows, you can't easily print it out and read it on paper, or even see it on the screen, where you can see graphically only a tiny chunk of "code" at a time. Last week we need to implement a new feature. The SAP BAPI was written in a morning, but converting it's interface into XML was proving very hard, so instead we used SAP::Rfc. We had a command line prototype within 15 minutes, and after a day's playing I wrote a 120 line Perl script that takes user input, talks to SAP, and spits out a fully formed HTML page. It's SO EASY TO USE, and I like XML/XSLT! I would not advocate Perl as the solution for everything, but buzz word compliant technology does not guarantee success either! | [reply] |
Re: J2EE is too complicated - why not Perl?
by holo (Monk) on Dec 06, 2003 at 21:57 UTC | |
Is there an application server like approach available for Perl and how do Perl developers manage transactions and authentication and other activities thought to be only managed by J2EE and proprietary solutions such as SAP. From an J2EE online Tutorial down at java.sun.com: Normally, thin-client multitiered applications are hard to write because they involve many lines of intricate code to handle transaction and state management, multithreading, resource pooling, and other complex low-level details. ... Because you do not have to develop these services yourself, you are free to concentrate on solving the business problem at hand. This can be done in pure perl using packages and POE components. I have never done so myself since I use modperl to maintain compiled packages ready to answer requests. Probably, there are other methods to perform the same job and probably they are a lot better than their Java counterparts. The problem here is just political. You can not expect a firm to trust and use perl; since it is not backed by the institution that produces it (what institution ?). That is usually the same "marketing" problem of all OSS projects. Apache is one of the greatest OSS beasts around that made it to the top because it has no serious competitors. On the bright side, perl has one advantage over non-OSS competitors (as long as they remain non-OSS). A non OSS software bundle is sustained by a company. If that company fails to support it properly, their product's marketability may weaken. On the other hand, Perl has no real roots (just imaginary ones) Perl has an unlimited number of people (and small companies) that devote time to improve it. If one individual person (or company) ceases to do so, there are numerous others that keep up the effort. The laws of evolution state that only the best survive. Roaches are not able to defend themselves against us, the cunning humans, but are very adaptable. No matter how many you kill, or how much insecticide you use, they always survive. Ever seen a mighty, ferocious dinosaur running around the house ? ($roach->strength > $dinosaur->strength) | [reply] [d/l] [select] |
Re: J2EE is too complicated - why not Perl?
by mattriff (Chaplain) on Dec 06, 2003 at 21:42 UTC | |
"Standard" being a relative term. TMTOWTDI, and as the project says, they aim to provide "one great way to do it." As for how suitable Perl is, I can say that at work we've used Perl exclusively for implementing things such as a domain registrar system, and just about everything else we do. Perl's suitability, like Java's, is largely a matter of perspective. I gather a lot of "suits" have been made to believe it must be Java for it to work, and I'm sure Java does have its advantages in certain situations. I'm fortunate not to work with any suits, so I have no first hand experience on that matter. Other companies who maybe are more open-minded have had great success with Perl (i.e. Ticketmaster).
- Matt Riffle VP Technology, pair Networks, Inc. (although, I speak only for myself; code is untested unless otherwise stated) | [reply] |
by simonm (Vicar) on Dec 06, 2003 at 22:26 UTC | |
You might be interested in reading about the P5EE project, which aims to come up with a standard solution for such things. Sadly, from what I can see, this effort has stalled. (Two list messages in eight months?) I'd be glad to be corrected if anyone knows of where any ongoing activity around P5EE is taking place... Update: See this message for a status report from April. | [reply] |
Re: J2EE is too complicated - why not Perl?
by pg (Canon) on Dec 07, 2003 at 05:26 UTC | |
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. | [reply] |
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. | [reply] |
by jepri (Parson) on Dec 07, 2003 at 15:17 UTC | |
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'. ____________________ | [reply] |
by exussum0 (Vicar) on May 25, 2004 at 15:46 UTC | |
by jepri (Parson) on May 25, 2004 at 15:53 UTC | |
by eduardo (Curate) on Dec 07, 2003 at 07:09 UTC | |
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. | [reply] |
by perrin (Chancellor) on Dec 10, 2003 at 22:22 UTC | |
by eduardo (Curate) on Dec 12, 2003 at 23:42 UTC | |
| |
by pg (Canon) on Dec 07, 2003 at 07:14 UTC | |
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. | [reply] |
Re: J2EE is too complicated - why not Perl?
by coreolyn (Parson) on Dec 08, 2003 at 18:50 UTC | |
As I'm an Enterprise Architect for a large financial corp, I wish I had enough time to vent on this one, but I have to get back to some production Java issues *cackle* First off I have to answer chromatic's question because he's answered so many of my own and I can't believe I'm capable of providing him an answer of any sort: What exactly is an "enterprise level requirement" and why would I have one? According to J2EE 1.4 spec a Enterprise Information System Resource (closest I could come to the question) is defined as: Just for clarification (according to Sun --Caution! Never stare at Sun directly!!) An Enterprise Information System is defined as: Now to the original question J2EE is too complicated - why not Perl? This is easy.. Perl is unmaintainable in a large enterprise. (5000+ employees.) Of course it appears Java is unmaintainable in a large enterprise too, however, millions are invested into it therefore, "It's gonna work dammit or your fired!". What's scaring the hell out of me is .NET. Just this week I saw two non-coders develop 2 fairly sophisticated apps that utilize web services in less than 7 days just by following the right-click on error method of programming. Intel platforms are cheap and apparently monkeys can create applications with it. Now we all know that as soon as MS upgrades they'll all break, but what will management think of it? Well guess who the monkies were... I love Perl up down and sideways but have a hell of a time working on anyone else's Perl code (monk level/CPAN level quality excluded). The truth is that I'm tickled pink whenever I run into someone in the organization that even knows what Perl is. There are issues like Perls speed and memory management (Can't get them to upgrade from 5.005), but these are not what keeps Perl from the enterprise. "It's the management stupid!" | [reply] |
by petesmiley (Friar) on Dec 08, 2003 at 22:16 UTC | |
oh sorry.... Ya know, these are the same people that decide that using the canned security in .NET and windoze is perfectly acceptable. But I guess some people have to learn the hard way. By the way, don't get the idea I've let this keep me from learning a little of it myself. As for Perl in the "enterprise" (I never saw that part of Star Trek), I still agree with chromatics question. As for the definition, why isn't it simple? His was. As for reading other peoples code and working in large groups, I would be willing to make a cheap bet. There is no project so big that you need so many programmers. I honestly believe many projects are over-engineered and the programmers under skilled. I have never had the opportunity to work in large groups. However, that has never kept me working on large projects. Here are the reasons that I think (I could be wrong ;) there are very few differences between languages when it comes to big problems.
If you think about it, a language can only make these things worse by resisting the need of being intuitive. Skill, simplicity, documentation, and communication are all failing points of not only programming projects, but also businesses. smiles | [reply] |
by podian (Scribe) on Dec 09, 2003 at 22:13 UTC | |
I was asked about it in my company when I wanted to write a tool. Even though we gave the tool to our customer, we did not sell it.
May be there is a way and I do not know it. I thought compiling it to native code is not supported yet. Why not write Sun's pet store project in Perl and bench mark it? | [reply] |
by petesmiley (Friar) on Dec 10, 2003 at 17:37 UTC | |
Re: J2EE is too complicated - why not Perl?
by cybear (Monk) on Dec 10, 2003 at 20:32 UTC | |
- cybear Ok, my turn. PERL is more that sufficient for enterprise-class computing. The only people (that I've encountered, no offence implied) that disagree are "Enterprise-class" software salesmen, I mean salespeople. I have a suite of FTP applications, writen in PERL whenever I was allowed to use PERL, that handle upwards of 1 million files, 1 billion megs of data, each year. Guess what parts break. The parts that are NOT PERL. My question is: has anyone come up with an effective way of getting MORE PERL in their enterprise. When I mention PERL my resident Java programmer starts writhing in pain and my managers eyes glaze over. | [reply] |
by coreolyn (Parson) on Dec 10, 2003 at 21:05 UTC | |
Here's an experiment you can do to see the difficulties involved in bringing Perl into the enterprise: Track all time required to communicate to successfully complete the experiment and multiply times the number of programmers in a large organization. I don't like having to be negative on this subject, but Perl is what Perl does. If a language doesn't enforce standards you have to rely on the coders... This is like trusting your business to M$. I do not doubt that there are shops where this is a silly experiment, however out of some 1500 programmer/analysts in the corp I am of only a dozen or so utilize Perl, and I don't think any of us like each others particular style and we all dread touching each others code. | [reply] |
by perrin (Chancellor) on Dec 10, 2003 at 22:45 UTC | |
| [reply] |
by coreolyn (Parson) on Dec 11, 2003 at 17:21 UTC | |
by petesmiley (Friar) on Dec 10, 2003 at 21:53 UTC | |
The only other reason I can think of for what you are aying is, there aren't enough highly skilled Perl developers. I somewhat doubt this. There are plenty of examples of large Perl projects out there. In a way you could even say that CPAN is one of them. Maybe it's just that it's not as industy/money driven as other languages so companies never ask for it. There's no gargantuan company called Pun running around and shelling out the big bucks to convince companies to use Perl in large projects. As for liking other programmer's code, you are going to tell me that java programmers relish touching each other.s code ;) Forgive me if I'm doubtful. Maybe it's that java programmers aren't given a choice by the people who buy into the language. Or heaven forbid by the language itself. I would hate to have to write anything serious in java by my lonesome. If I was in an all java shop, I would have to work on other java programmer's code, like it or not. If I was in a Perl shop, I would have to work on other Perl programmer's code, like it or not. I've also never had the opportunity to work in a company full of Perl programmers. Have you? How can something be proven to everyone if most will not even try it? I believe there is a proper way to do it with Perl. Maybe there are people out there who have mastered it, and we're just not asking the right questions. I have a feeling it goes a little beyond telling them to "use strict;". smiles | [reply] |
Re: J2EE is too complicated - why not Perl?
by dragonchild (Archbishop) on May 25, 2004 at 16:15 UTC | |
http://www.perl.com/ also has a bunch of success stories. ------
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested | [reply] |