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
Re: J2EE is too complicated - why not Perl?
by etcshadow (Priest) on Dec 07, 2003 at 04:50 UTC
|
Interesting questions: to answer the question of whether perl is suitable for banking, insurance, etc. applications: YES! I, myself, am an architect of a big, complicated healthcare administration (insurance and much, much more) application that is built on perl. Apache::ASP/mod_perl to be specific (as well as lots of plain-old-perl scripts running from crons and command lines for administrative purposes), on an Oracle backend.
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] |
|
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?
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!
Wanted!
| [reply] |
|
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:
- typedefs / class defs => table defs
- (non-pointer-) primitives => (duh) primitives
- pointers / references / included derived types => foreign keys
- structs / instances => rows
And I know that's kind of elementary, but I'm still spelling it out for the sake of completeness.
Last of all RDBs give you things for free, that you're likely to end up wanting, regardless. To name a few:
- Visibility into your application's state, and the ability to manipulate it. A sql client is like the world's coolest debugger!
- The ability to make arbitrary reports on your data. For any kind of real business application, this is invaluable. If you weren't using some kind of database for your data, you'd end up having to write a reporting framework, and you wouldn't be able to do it as well.
- Performance: I know a lot of new programmers think they can do better... but again, even if you could, it would be a hell of a lot of work you don't want to have to repeat, when, with an RDB, all you'd have to do is build an index.
- I'm sure there's some better example... but it's late and I'm getting tired
- Update: How could I forget: atomic transactions!
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] |
|
|
|
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] |
|
| [reply] |
|
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
|
You might be interested in reading about the
P5EE project, which aims
to come up with a standard solution for such things.
"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).
| [reply] |
|
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] |
|
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] |
|
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'.
____________________
Jeremy
I didn't believe in evil until I dated it.
| [reply] |
|
|
|
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] |
|
|
|
|
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:
- An entity that provides enterprise information system-specific functionality to its clients. Examples are: a record or set of records in a database system, a business object in an enterprise resource planning system, and a transaction program in a transaction processing system.
Just for clarification (according to Sun --Caution! Never stare at Sun directly!!) An Enterprise Information System is defined as:
- The applications that comprise an enterprise’s existing system for handling company-wide information. These applications provide an information infrastructure for an enterprise. An enterprise information system offers a
well-defined set of services to its clients. These services are exposed to clients as local or remote interfaces or both. Examples of enterprise information systems include: enterprise resource planning systems, mainframe
transaction processing systems, and legacy database systems.
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] |
|
.NET =D HAHAHAHAHAHA....
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.
- A programming language will not make coders write good code, no matter how strict the language is.
- A programming language will not make coders write documentation, no matter how easy it is. And for those of you with experience you know how easy it is in Perl.
- A programming language will not make coders communicate with each other any better.
It will stay that way until they invent the mind reading programming language (which still leaves #3 in doubt), and by then it won't even matter because it will take only one person to write something.
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] |
|
One thing missing in this discussion is that if I write a commercial application in Perl, how do I sell it without exposing the code?
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.
Here is a cool idea:
Why not write Sun's pet store project in Perl and bench mark it?
| [reply] |
|
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] |
|
Here's an experiment you can do to see the difficulties involved in bringing Perl into the enterprise:
- Write some standards (i.e., use strict, -w, include pod comments, etc)
- Write a simple application (irrelevant as to size/functionality)
- Have someone add new functionality to your script utilizing the same standards
- Have a third programmer review and implement the results
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] |
|
Are you aware of how little standardization in coding actually exists in J2EE? When I was writing Java code at a recent job, I had to work on some other people's code that was just horrendous. The Sun coding guidelines really just scratch the surface, and most people don't even follow those unless you make them. Things like exception handling, use of recent language additions, choice of libraries, etc. make it fairly difficult for Java programmers to just share code without lots of talking and agreement on standards. Perl certainly allows a much wider range (e.g. beginners can write ugly code with globals and no warnings), but within a group of experienced coders with good style and agreed standards it is no harder to share Perl code than it is to share Java.
| [reply] |
|
|
By this standard, Perlmonks wouldn't exist if you were correct. People post code here all the time (sometimes hideous), AND get answers and understanding in a relatively short period of time.
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
|
| [reply] |
|
|