Perl falls victim to shifting trends

[vladb]

The unit of the company that I happened to be a part of has a long-standing relation with open source technologies and Perl in particular. To this point, we’ve managed to successfully utilize the powers of Apache and Perl to run our web servers. Perl has also proven to be an excellent tool for internal server-side processes (such as monitor scripts, ftp daemons etc).

However, all this is about to change, unfortunately to myself and other co-workers who’ve come to like Perl for the things it does best. It’s been decided in the higher flanks of our company, that Java technology should be adopted instead for all our development needs. Thusly, instead of writing a templating script in Perl, we are now required to do so in Java. I suddenly feel being swept by the tidal wave of shifting trends. From where I stand, I can’t quite reason or concur with the pointy-haired boss why Perl wouldn’t be a perfect fit for virtually any web development project. However, I have to oblige with this new directive, unless, of course, I would rather wish to quit the company (a rather unlikely prospective at this point). These recent happenings remind me of an article titled Revenge of the Nerds (authored by Paul Graham, who by the way has also been mentioned in a couple other meditation posts recently). Specifically these first passages:

The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it.

Suppose, for example, you need to write a piece of software. The pointy-haired boss has no idea how this software has to work, and can't tell one programming language from another, and yet he knows what language you should write it in. Right: he thinks you should write it in Java.

Why does he think this? Let's take a look inside the brain of the pointy-haired boss. What he's thinking is something like this. Java is a standard. I know it must be, because I read about it in the press all the time. Since it is a standard, I won't get in trouble for using it. And that also means there will always be lots of Java programmers, so if the programmers working for me now quit, as programmers working for me mysteriously always do, I can easily replace them.

Fortunately for myself, I have a strong grounding in a number of languages (Pascal, C++, etc), including Java. Although, I very much like coding in Java, it wouldn’t be my first choice for many tasks that we currently do in Perl, and do so well as a matter of fact. I’m wondering if anyone of you had to go through similar change and how did you deal with it? Lately, I feel like there’s an ever shrinking opportunity for me to contribute to this monastery due to the change, which is also rather unfortunate (for me at least :). If this change is widespread, than this may have a negative affect on the Perl community at large as there will be fewer and fewer practitioners of this language.

_____________________

# Under Construction

[perrin]

I wrote a little bit here about my experiences with this sort of thing. There's not much you can do when this starts happening at a company. You can try to wait it out and hope that your PHB will leave or get fired, you can argue your case with a higher power (which will mark you as a troublemaker in the eyes of your PHB), you can go with it, or you can leave. If you don't feel that the decision is likely to get changed, my advice would be to try it out (i.e. give their decision a chance and see if it does make anything better) and then leave if you aren't having fun.

The strongest argument that manager types understand about this sort of thing is that it will cost a lot more to use Java. Potentially millions more when you account for commercial app servers, IDEs, extra hardware (commercial app servers tend to be very slow), and much longer development times. Open source Java tools can be an enjoyable experience, but the expensive commercial ones tend to be painful and slow. If you want to fight it, that's probably your best area of argument.

[Abigail-II]

The strongest argument that manager types understand about this sort of thing is that it will cost a lot more to use Java.

That is a strong argument, but not at all easy to prove. Just coding the thing in Java might be more enjoyable than the research and the meetings you have to do to prove that it's more expensive in Java. If you even can prove it.

Abigail

[simon.proctor]

I seem to remember ranting about something similar not too long ago. I still feel now, as I did then, that its basically down to the fact that virtually no-one will get sacked for recommending Java.

Plain and simple.

However, what companies will have to wake upto is the fact that implementing Java costs a lot more than they realise. It also takes, on average, a lot longer. So whilst in the short term things may look a little bleak, I wouldn't worry too much. Just treat this as an opportunity to keep your CV upto date :P.

From my own personal experience, where I work we have to do everything in ASP or Java. You have no idea how headbangly frustrating it is to have someone tell you you can't use Perl cos they installed a Matts Script and it got hacked. And then they want to replace it with one that you found 22 holes in (without trying).

However, on the plus side, some of my Perl tools are proving so useful that there's a secret underground forming of people needing, using and utilising Perl. Its been slow going but things are slowly coming around (much to save my sanity).

I realise this may not help you, as your company is moving away from Perl but I think it at least indicates thats there's life in the old dog yet.

Of course once you have all that web development experience in Java, you can say ta very much and then get a new job. I would :).

[rinceWind]

It might be an idea to introduce your management to the concept of metrics. In the mean time, put in place the means of gathering the information required for the metrics.

This is a good way of turning a technical problem (having a programming language imposed on you) into business language that pointy haired bosses understand.

What I am talking about:

• Size of application: How many lines of code? How many pages of documentation? Estimated effort required for Java rewrite in man-days.
• Maintainability: How stable will the application be in Java? in Perl? If it ain't broken don't fix it. What is the Mean Time to Fix problems (mttf)? What is the cost of maintenance in terms of head count?
• Flexibility: How easy is it to add new functionality, and meet changing business requirements? How often do business requirements change? How much development-lag is there in each business driven enhancement?

You may find that this approach will help with whatever programming language you are using. It may help you get hard evidence that the company should stick with perl.

[toma]

As the new Java applications are created, users will need to use the results from them. The developers of the applications will get bogged down in their own schedules and priorities, leaving behind the needs of important segments of their own user base.

From these users will rise a super-user, who uses perl to solve his or her own problems. A clandestine server will appear, a beacon of rebellion against the unusable mansion of corporate-mandated cruft.

Official response will be silent. The revolution will not have conference calls! Users will migrate to the new machine, and the operation of the company will be transformed.

The isolated inner circle of unresponsive programmers will be driven out by an angry mob armed with torches, pitchforks, and perl! The mob will move into the mansion, and the cycle will begin again.

It should work perfectly the first time! - toma

[dws]

The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it.

Your challenge when faced with bosses like this is to find out what they do understand. And, more importantly, what they fear. Then reframe your arguments to play to that fear.

I once managed to dissuade a Sales VP from pushing a stupid idea by planting the suggestion that his idea might jeapordize the bonus that would get him a new sports car.

It's all about finding the right button.

[Spenser]

I know exactly how you feel.  I just had the crap knocked out of two years of Perl and mySQL development by a passing whim from higher up. See this panic posting pleading for advice to stop an ASP.net and C# wave.  It started and succeeded in less than a month.  I argued against it and as a result I seem to be on the fast track out the door.  I will be surprised if I still have this job come September.

I don't think that this is an epidemic, though.  I just think that the logic and merits of Perl can't always stack up against the marketing arm of Microsoft.  All it takes is a programmer who likes MS languages to tell an executive that MS is the way to go and he forgets years of logic a Perl programmer presented him, not to mention a proven track record and the free price of Perl.  Of course, you're talking about Java, but the argument is still valid.

Maybe what we need to do is start a marketing effort for Perl to combat MS programming languages and Java.  Linux has done quite well because of the direct comparison the public and the press sees between Linux and MS Windows.  But when it comes to comparing one programming language to another, who cares besides us?  Perhaps the thing to do is to talk Perl up in a more focused way and get the public to see the difference--if that's even possible.  Perhaps we should write newspapers and magazines, go after publicity and other such things to build a more informed business public.  How one would do that, I'm not sure, but I would love to hear other people's ideas and to participate in such an effort.

-Spenser

That's Spenser, with an "s" like the detective.

[astrobio]

Much of this shifting trend (inconclusively) stems from a perception that Java is easier to work with on diverse development platforms (windows/unix/mac).

While not particularly true in practice (or going opposite to this in some Windows XP instances), that argument has shaped much of this trend in our own company.

The IDE on perl is after all a good text editor mostly.

Best counter-argument to Java: 14,000+ CPAN modules.

If the job is worth doing at all, someone on CPAN has started it.

[dpuu]

Where's that B::Java module when you need it? :-)

Seriously though, there is a lot you can do with perl to make Java less tedious. I find that a lot of stuff can be done with code generators when creating tedious code. But beware of going too far: sometimes its better to create a perl script as a wizard than as continuous part of the build flow.

--Dave

[barrachois]

Something similar has happened to me recently - though my shop doesn't write code, we teach WWW engineering.

For the last several years we've been using both Perl and Java as our two primary languages. And typically the final projects of our students have used the two in roughly equal proportions, with a smattering of other choices.

This last year, however, very few students chose to work in Perl. I'm not sure I understand the reason for the change this year, but the perception among many seems to be that Perl CGI is not as popular or marketable as Java servelets. Moreover, the other faculty would like (with some justification) to have more depth and less breadth.

Thus it seems that in the coming year we're not going to have Perl as part of the curriculum. Which is kinda sad.

[defyance]

After reading this node, and its replies, I had to show one of our more avid Java Developers in the company, to see what he thinks. I also couldn't stop myself from posting his response here for you all to see. I totally expect to loose XP for this, just thought I'd throw in an opinion from "the other side" to make things more interesting, and to hear your responses.


P.S. I had written consent from the author, so this was posted with permission (link removed).


The problem with most of those arguments is not what they address, but what they fail to address.

1) Java is faster than Perl in a multi user environment.
2) Java is less resource intensive than Perl in a multi user environment
3) Java threads like nobody’s business… which makes it ideal for enterprise system programming (Utilizing the capabilities of a big MP box doesn’t require special code.)
4) Java’s code re-use abilities are infinitely better than Perl
5) Java is a pure OO language (even more so than C++)… which means you have inheritance, encapsulation, and polymorphism.
6) Java’s security features are the best of any language… bar none. Each member of each class can have one of four security levels.
7) Java incorporates Java Swing, a highly advanced GUI toolkit.
8) Java 2 Enterprise Edition has exceptionally powerful messaging and event control capabilities.
9) Networking in Java is as easy as creating a socket object and piping it through a buffered reader or writer…. That’s it.
10) JDBC allows very rich RDBMS interaction…. Far richer than Perl’s SQL module…. Not to mention connection pooling.

There was a bit of misinformation there. SunONE Application Server is free on Sun hardware… and sun hardware is the biggest bang for the buck for web app environments. Also, Apache’s Tomcat engine is free.

Java does not require an IDE for most projects. The best code I’ve written has been in vi. This is because of Java’s package architecture and JavaDocs utility. (JavaDocs allows you to markup source code to automatically create GOOD documentation. e.g. <linktoexamplejavadc.html> )

As for Perl, remember it’s an acronym. Practical Extraction and Reporting Language. For ‘practical’ extraction and reporting, it’s fabulous... It makes great parsers and is handy for dealing with the odd text file. But for systems programming and application development, it can’t compare to C++ or Java. It’s the wrong tool for the job.


Your regular expressions have been included since Java 1.4.0
Resistance is futile.
You will be caffeinated.

perl -e '$a="3567"; $b=hex($a); printf("%2X\n",$a);'

[Anonymous Monk]

Please send the following response back.

The problem with most of those arguments is not what they address, but what they fail to address.

I would say the same about your response. For instance a key theme in the responses which you just ignored is that Perl allows programmers to be more productive. There is a reason for that. Java decided that it is more important to allow 10x the number of programmers to work together. Perl tries to make programmers 10x as productive. The Java approach is great if you want to sell lots of seats, or if you want to build a great empire under you. The Perl approach is great if you need to actually get stuff done.

1. Java is faster than Perl in a multi user environment.

   Not according to my benchmarks. YMMV. And certainly will if you compare a particularly slow Perl environment (eg CGI or AxKit) versus a good JSP platform (like Resin). Ditto in reverse if you compare Tomcat version 3 to real mod_perl handlers.

   Otherwise they are reasonably close. Which brings it down to the programmers. For instance if your Java programmers need to build up a string incrementally and make the mistake of using String and concatenation, Java will run like a dog. (Instead they should use StringBuffer and .append() to it.) Now theoretically the same mistakes can be made in Perl. But from what I have seen, people don't seem to do it nearly as often. Why not? Because the default way of doing it in Perl usually is pretty efficient, Perl has fewer APIs to wade through so you have less to keep in mind about potential gotchas, and you write less Perl code so you have less room to accidentally slip up.

2. Java is less resource intensive than Perl in a multi user environment

   I could respond to this as I did to the previous one, but I won't. Instead I will introduce you to my friend Moore, and suggest that the salary of a programmer you no longer need due to improved productivity can pay for a lot of upgrades.

   Besides why the fixation on resources in a multi-user environment? Most computers out there seem to be massively overpowered desktops with one user. Most servers seem to be department servers with massively greater capacity than they need. If I go to a friend who routinely throws around terabytes of data, what does he do? Oh right. He buys dedicated boxes.

   Massively multi-user servers seems to be a pretty specialized market. So why fixate on it?

3. Java threads like nobody’s business… which makes it ideal for enterprise system programming (Utilizing the capabilities of a big MP box doesn’t require special code.)

   And heavy threading results in lots of potential for race conditions. Which Java admittedly mostly, but not completely, managed to avoid for years by only offering blocking APIs so that people would be encouraged into a model of always spawning a thread for I/O.

   Of course eventually that overhead became bothersome enough that the maze of "almost the same but slightly different" APIs were expanded with another (incompatible with the old of course) API for non-blocking I/O. Which finally allows Java to get more scalable I/O, but also leaves it with the worst of both worlds.

   Incidentally a historical note that you probably don't have the perspective to appreciate. When Sun originally came out with Java and trumpeted it as cross-platform, the leading Unix platform was HP-UX. HP-UX only had kernel threads, and started to choke at around 50-60 of them. By contrast Solaris had very good multi-threading support, but since the standard Unix model was fork/exec, nobody used it. Strangely not long after Java came out hyped to the gills, people began writing cross-platform benchmarks in Java. Guess who lost those badly?

   Coincidence? You decide.

   Pervasive multi-threading all of the time is not always good just because Sun tells you that it is. Nor is it necessarily true that you want a big MP box. Spec out a 4 CPU box versus a cluster of 8 1 CPU boxes some time. Which is a better price/performance point? If your problem is at all parallelizable, the latter...

4. Java’s code re-use abilities are infinitely better than Perl

   Then why is the largest freely available collection of reusable libraries is CPAN? And in my experience the quality is much better than most proprietary libraries. (For one thing there is not the proliferation of half thought through but broken APIs that you see from some other places that I might mention.)

5. Java is a pure OO language (even more so than C++)… which means you have inheritance, encapsulation, and polymorphism.

   You may be pardoned for not knowing better if the only thing that you can compare Java to is C++. But Java is not pure OO. The commonly given example is that integers are not real objects. Since that one has been beaten to death with great pleading by Java proponents for the special exceptions built in to the language, I will give an unusual one. In Java you can choose to have class methods. But those methods aren't anything other than functions with a long name. You can't get do anything polymorphic in them, such as get hold of an object representing the class. Hence the need for Java Enterprise Beans to create "Home" objects for what should be built in to the language.

   If you want to learn what a pure OO language is like, then I would suggest learning Smalltalk or Ruby. There everything (yes, including integers) is an object. Be warned that I know many people who have extensive experience in both Java and Smalltalk. But not one prefers Java to Smalltalk. This transition may be uncomfortable for your world view, it is definitely safer to hold your hands over your ears and chant Sun's marketing slogans.

6. Java’s security features are the best of any language… bar none. Each member of each class can have one of four security levels.

   Complexity does not equal quality. Java's ACL model is not necessarily good just because it is there, nor is your software necessarily secure just because your language has the feature listed on a checklist. (Even if many PHBs mistakenly think otherwise - and then wonder how someone managed to nick their credit card database.)

   Personally in a complex application I far prefer using a capability security model. And all that you need for that is a good object model! Better real security, less work. (To understand the fundamental problems with an ACL model like the one that Java uses I would suggest a search for the Confused Deputy problem.)

7. Java incorporates Java Swing, a highly advanced GUI toolkit.

   Apparently everything that Java does has to be good in your world because it is in Java. In more realistic assessments even friends who like Java admit that Swing is not very fun to use in practice, even when the performance and bugs aren't a problem for you.

8. Java 2 Enterprise Edition has exceptionally powerful messaging and event control capabilities.

   You are in a maze of twisty little APIs, all alike...

   One of the worst characteristics of Java is the tendancy to introduce new APIs rather than fixing the bugs in the old ones. J2EE is a continuation of this source of unproductivity.

9. Networking in Java is as easy as creating a socket object and piping it through a buffered reader or writer…. That’s it.

   Unless you turn out to need unbuffered access. Or non-blocking. Then you have to use a different set of unrelated APIs that use incompatible objects. And let's not get into how much code you have to write to actually do anything with the network.

10. JDBC allows very rich RDBMS interaction…. Far richer than Perl’s SQL module…. Not to mention connection pooling.

    s/rich/complex/

    With DBI you can do anything that you can with Java. (Yes, including connection pooling.) And often far more easily. Also do not forget to look at the various wrapper modules to simplify things.

There was a bit of misinformation there. SunONE Application Server is free on Sun hardware… and sun hardware is the biggest bang for the buck for web app environments. Also, Apache’s Tomcat engine is free.

At a guess I have been around the block a few more times than you have. So I am going to give you the best advice that I know.

Sun is toast. Oh, they are alive, kicking and powerful now. But their days are numbered and it would not be wise to make long-term plans on them.

If you want to understand the common industry pattern which dooms them, I can highly recommend The Innovator's Dilemma by Clayton Christensen. Here is a brief synopsis of the pattern:

You have an established industry with established companies and existing customer bases. A new innovation comes along which cannot do what customers need, but conceivably will in a few years. We call these disruptive innovations for reasons that will become apparent. The established players frequently evaluate it (heck they often invent it), and find that they can't use it.

However small startups (or sometimes spinoffs from larger companies) take the technology and try to create markets for it. These markets are small and unprofitable, but they are enough for these companies to establish themselves and continue improving the product. Eventually the product improves to the point where it is usable by the low-end of the original market.

At this point a key dynamic develops. The upstarts are in a business with much tighter margins, and are producing a qualitatively worse product. The established players are used to selling into markets with much higher overheads (and those overheads are for things like support that their main customer base needs), and so cannot figure out how to sell to the low-end at a profit. The result is a distinctly one-sided battle for the least profitable established market.

If it stopped there, it would be great for the established vendors. They lose their least profitable business and get to focus on their best customers. This is great for profit margins! But it doesn't stop. The disruptive product keeps on marching upmarket into more market segments, pushing the established vendors farther up the foodchain. (Where they are often eating up people on another iteration of the cycle.)

Whether we are talking about the replacement of sail by steam, steel mills by mini-mills, or the workstation market, this battle has had a predictable conclusion. The established vendors get decimated.

This is the challenge that Sun faces with Linux. They know that they are in trouble, and are losing money. They just lost big chunks of the financial industry. They are trying to figure out how to sell Linux at a profit (they won't - their business model has too much overhead). They have lost a lot of customers and have yet to accept that those people aren't coming back.

They still have opportunities. For instance they can continue pushing into mainframe territory. They can continue killing telco equipment. They have other markets that they can enter.

But their core business is on a one-way track out of the markets that they are in now.

I know you probably don't believe me. But in a few years you can look back on these words and think that I was a prophet. Or you can get that book and learn more details of the dynamic that Sun is trapped on the losing side of.

Java does not require an IDE for most projects. The best code I’ve written has been in vi. This is because of Java’s package architecture and JavaDocs utility. (JavaDocs allows you to markup source code to automatically create GOOD documentation. e.g. &ltlinktoexamplejavadc.html< )

Right. Java is text, and any text editor will work.

But an awful lot of Java shops deploy development environments that autogenerate lots of code from a basic framework. Fairly quickly this can put you under a lot of pressure to use the IDE. (I will agree that code written without the wizards is probably better though.)

As for Perl, remember it’s an acronym. Practical Extraction and Reporting Language. For ‘practical’ extraction and reporting, it’s fabulous... It makes great parsers and is handy for dealing with the odd text file. But for systems programming and application development, it can’t compare to C++ or Java. It’s the wrong tool for the job.

Actually Perl isn't an acronym, that is a backronym.

Furthermore raw Perl is actually bad at parsers. REs are good for finding patterns, not breaking them up in a structured way. If you want to parse then you either have to use another language, roll your own, use a module like Parse::RecDescent, or wait for Perl 6. (Which has completely rewritten how REs work so that they will be good for parsing.)

As for application development, if you are my competitor I hope that you continue believing that. Then again I have had the experience of being on a small team that built in 3 months the equivalent of what a much larger Java team had managed in 2 years. (Ironically when we went to demonstrate it for them, they had a problem showing us theirs because Swing had managed to crash by itself just sitting there.) A year later we came back and in another project duplicated what they had planned to do over the next few years. I don't know what they are doing now...

Let me give another example. A few years ago Paul Graham was running a web-based startup. There he learned that the best way to track other people's development tools was to look for their job ads. As he explains in Beating The Averages, one of the things that he learned is that any competitor who was using Java could be discounted. They weren't an issue. Their development cycle was going to be so heavy and slow that he could duplicate any good ideas that they happened to have within a few days. (His startup was very successful, and was sold to Yahoo! in 1999.)

Your regular expressions have been included since Java 1.4.0 Not quite. Everyone calls their REs "Perl 5 compatible" after they add a few extensions that Perl was first to come up with. But Perl generally has other extensions that the other people don't. Also see this conversation for an amusing example of how Perl still makes actually using RE's easier.

Resistance is futile. Most advocates aren't quite that obvious about admitting to their groupthink.

You will be caffeinated. Indeed. My choice has penguins written all over it. Though these guys will do in a pinch. Oh, you weren't talking about real caffeine? Sorry then, not interested...

[laughingboy]

> Actually Perl isn't an acronym, that is a backronym.

Interesting. I've always known that I've been programming in Perl and not PERL. But I always assumed that the name came from "Practical Extraction..." or maybe "Pathologically Eclectic..." Does anyone know the story of how Larry chose the name Perl, if it's not an acronym?

It might even be worth passing this info along to the maintainers of the lexicon, since its entry for Perl is under the same misimpression I was...

laughingboy

[rbc]

AWESOME post nameless brother!

[valdez]

Thanks Anonymous Monk. Ciao, Valerio

[Aristotle]

6) Java’s security features are the best of any language… bar none. Each member of each class can have one of four security levels.

Sorry, but Perl's tainting mechanism (I bet he hasn't even heard of that one) is much more useful than Java's sandbox. Perl mistrusts data, Java mistrusts code. If I'm playing on a server, the latter is useless.

Makeshifts last the longest.

[runrig]

Java is a pure OO language ...

As for Perl, remember it’s an acronym...

HAHAHAHAHAHAHA...<thunk>(/me falls over)

++ for making me laugh (-- for the bruises..just kidding :-)

Update: BTW, do not tell them that it really stands for Pathologically Eclectic Rubbish Lister, it will only add fuel to their fire...really though, there is just no convincing some people, so just try to quietly do twice the work in half the time (where appropriate), and some will come around eventually...

[perrin]

I want to say something about the security issue because Java supporters seem to bring it up a lot. Neither Java nor Perl programs have buffer overflow vulnerabilities, except when the main interpreter or a used library has one. The kind of security problems that show up are mistakes like not properly checking input that is used as part of a file name or using session IDs that can be guessed. These are problems with trusting client input too much, and both languages are equally vulnerable to them.

If a method needs to write to a file, you can't use Java's security model to prevent filesystem access. The security model that Java offers is mostly about sandboxing and running untrusted code, which has nothing to do with real server-side website exploits.

[Anonymous Monk]

I have been asked the following question and after reading your comments, thought you might be able to help... Why might you choose to migrate web applications from an Apache mod_perl to J2EE environment, and what would be involved in doing it? please reply to [e-mail] at your earliest convinence. Ta

[BUU]

After reading the above text, i believe the consenus is that YOU DON'T

[Anonymous Monk]

Here in Australia the majority of programming jobs are mainly going to Java, C++ and .NET developers. It would seem that Perl has lost its edge in terms of future prospects. I love Perl. But times are changing. I just hope Perl can stand up, realise what's happening and and offer something that no one else can. Andrew Dumas

[Anonymous Monk]

Nothing really new to add - just confirming the opinions already express. I'm turning into a PHB, having done Perl development for the last few years, and now being in charge of the new wave of Java development at my company. I am involved in both sides of the argument and can see both the advantages and disadvantages of each. To me it has always boiled down to "the right tool for the right job" and Perl has been a pretty good tool. Unfortunately, most management decisions aren't based on such simple logic. We will keep using Perl for most of the supporting systems, monitoring tools and other related tasks. Our main production code will be Java for the reasons mentioned above - "Java is standard", and "there are many more, easily replacable, Java programmers than there are Perl programmers". What I am finding, from experience, is that 1) It takes a lot more hardware to to run an equivalent site under Java than it does under Perl, 2) Java programmers cost more than Perl programmers, 3) Not everyone that claims to be a Java programmer, is really qualified for the job, 4) everything seems to take longer to develop using Java, and 5) Good programmers are hard to find. A disturbing trend, but that is the direction things seem to be moving.

[jens]

Thanks for that fantastic link to Paul Graham's Lisp speech!

It's an excellent discussion of high-level languages used for Rapid Application Development,
and the competitive advantages of Lisp vs Perl vs Python.

You might also be interested in downloading his book, On Lisp, for free!

--jens

[rbc]

I feel your pain brother!

But it could be worse ... your pointy haired boss
could be forcing you to use .NET!

[higle]

I feel you, man. The company that I work for has become die-hard determined to use the SilverStream Java application server platform for all of its Intranet/Internet projects (after sinking millions into licensing, training, and infrastructure first, and testing later).

All of our Intranet and Internet applications run slower than molasses in January now. The development time on a project stretches on for months beyond initial deadlines because, with every new application, there are tons of unforseen hitches and glitches that have to be ironed out by the vendor, our Unix admins, or the harried programming staff.

This causes obvious problems, but also provides a few benefits for me. I'm lucky enough to be allowed to use Perl for most everything that I do (it's a long story as to how I got around the SilverStream mandate). This makes me look like a superhero to the higher-ups, because I can take on a project (by myself), code up a working prototype in a relatively short while, and be done with all coding/testing/documentation in a fraction of the time that it takes for the same thing to happen in SilverStream. I'm not even that great of a Perl programmer (though my quest for learning continues).

I used to be alone in my Perl quest, but I'm converting a number of our other programmers to The Truth. The sad fact, though, is that SilverStream will not go away anytime soon. But I'm trying my damnedest to shove Perl and its many splendored ways down our PHB's throat!

: )

  higle

[pizza_milkshake]

i just ran into something similiar today. I have been implementing a series of financial calculations for my company (they are run periodically to aid our financial guru in analysis). Today after a corporate meeting, the boss says I need to do em in Java. After finally finding a "legitimate" excuse to further and refine my knowledge of perl I need to ditch it because no one else knows perl (not that they know Java very well either :/). I'm very bummed.
perl -MLWP::Simple -e'getprint "http://parseerror.com/p"' |less