Time passes, Version 2 is slipping one week per week near the deadline, even though promises were made to the investors to have a "new site online soon". Lead Java guy goes over to the Perl guys (still maintaining version 1) and says "can you mock up these new looks on your existing codebase?" Perl guys code the entire thing in a long weekend, and "version 2" goes live. Live, not just mocked.

Java guys all get the axe.

Amazing. This stuff needs to get out there more. Too bad I don't have permission to reveal more details.

Although it's a useful example, it doesn't necessarily show an advantage of Perl over Java -- it shows an advantage of modifying an existing system, as opposed to restarting from scratch.

Depending on the exact details, it could also show that bringing in programmers who aren't familiar with the underlying business processes can hurt the development of new systems -- sometimes (most times?), it's better to take the time to training current employees in new technologies, than to bring in a contractor or outsource it.

(and I say that, currently doing long term contract work ... and I still don't understand most of the data that I deal with, 3 versions and 18 months later)

Well, with 30 developers in one project, one sure deal-breaker is not-enough savvy project management.

I'm not saying that good project management can rescue a surreal ship date no matter what, but bad project management with 30 people involved is never, ever gonna work out, regardless of the language used.

The way you describe how the slip date is handled is a red flag, and I've also seen it up close a saddening number of times. No small slips would be a nice pattern to apply here (and the book, Organizational Patterns of Agile Software Development is one of the most encouraging books I've ever read about software project management).

/J

Update: changed the pattern url to a more recent one

Language is just one detail of a project. A project in Java failed does not prove or indicate Java is a bad language. In this case, I would rather say that this proves in-house developement are usually cheaper and easier to control than using outside consultant.

In this case, I would rather say that this proves in-house developement are usually cheaper and easier to control than using outside consultant.

Huh? What makes you say that? There were no outside consultants used! Both the Java team and the Perl team were in-house.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Amazing. This stuff needs to get out there more. Too bad I don't have permission to reveal more details.

It would be interesting if you could set up a meeting between a Perl advocacy group and businesses with Perl success stories like that, given the right price/agreement the company might agree to have the story published. Perhaps this is a bad example because it sounds like the company's management made a mistake by hiring the Java team in the first place, but I'll bet that you (and others) know some good stories that would reflect well on a company.

Just a random thought before bed. :)

The entire set of backend service tools at Amazon.com was in Perl and C (almost no Perl facing customers but tons facing employees). The tools were disparate, separate, and sometimes overlapping so they were difficult to learn and maintain. Someone high up decided Java would fix this. 18 months later there was a GUI replacement tool (mostly replacing just Perl and wrapping existing C) that was 18% code complete compared to the original base. What was there was buggy and often too slow to be practical (long conversations to distract customers while you waited for data to come back). Still it was hailed as a huge success by management.

The old tools were still around because of the incomplete nature of the GUI and even new, untrained employees gravitated back to them because they worked consistently and in much deeper ways. Even though it was the only sanctioned way to do the work, the Java tool had about an 80% abandonment rate.

Many, many millions of dollars (training, retraining, lost hours, developers' time, new hardware, in fighting, work on an open list of 500 bugs, etc, etc), and lots of confused, frustrated, or plain angry employees, later the entire thing was sent to the scrap heap and recoded as a web app in Perl (again, just replacing Java parts mostly and still wrapping C).

I understand it's all now being redone again in Java, though this information I only know from an overheard conversation so it could be erroneous.

These kinds of decisions are often from work-flow illiterate senior managers who cannot get good information through the bureaucratic layer cake. They make terrible choices and blame the technologies for their failures because that's easier than admitting a good bit of your managers, technical PMs, and maybe even you and a few of your developers are incompetent and should be culled or repurposed.

There are many middle managers who believe that the best way for them to improve their reputation is to make significant changes as soon as they're put in charge.

Good managers understand that their job is to facilitate the work of those people under them, shielding them from stupid requests by other management, and inspiring them to get the best possible work out of their charges.

Most good ideas come from the lowest underlings -- mostly because there's more of them, so they have an advantage in numbers, and they know their part of the system and its failings in their eyes.

(and I know you said 'senior management'. By my consideration, there's four basic levels of employees -- executive level (VP, CIO, board of trustes), middle management, team leads, and the folks who do most of the work. As such, most 'senior management' falls into my 'middle management' class.)

A good manager is like a good system administrator -- you almost forget they're even there, because their part of the system run so smoothly. Other people assume they're not working hard, because they're not seen to be struggling like the incompetent managers. They're humble, letting their team take the credit when things go right, but should things go wrong, they take the blame on them. (but they're good, and know what's going on, so they never let things get bad enough that other people know something went wrong).

When you find a manager like this, don't screw things up like I've done, and tell their bosses how stupid their ideas in front of everyone else at meetings.

I'm not sure I agree. Actually, I'm pretty sure I don't.

Modern JVMs are faster than the 1.1 or 1.2 JVMs, yes. But CPU speed has also more than doubled since then. More like 5 or 6 times speed boost. And memory is dirt cheap - I started with Java 1.1 on 168MB RAM. I'm now running perl on a machine with 4GB RAM. I'd wager that Moore's law has taken care of more of Java's speed problems than Java has.

Java still has a significant object overhead, even compared to perl's far-from-zero overhead. This puts an upper barrier on how fast the JVM can go. And you just can't do that much interesting in Java without objects.

What really gets me is the Java startup cost. Perl can compile, optimise, and execute some activities faster than Java can load, initialise itself, and execute a pre-compiled .class file. And then Perl has mod_perl to take care of that problem. Oh, no, sorry - that eliminates what little startup cost there is for perl, at least for a subset of the problem. Yes, you can do the same for Java. Memory usage shoots right up, though...

My last point is that the amount of abstraction you need to get a job done in perl is quite different from Java. Yes, in perl, you can go whole hog. In Java, you often don't have a choice but to go all the way.

I'm still way more productive in perl than my Java-writing peer. And he knows it. In the end, it doesn't matter to him because he still is getting paid, which is really the bottom line to him.

Perl's development speed is faster, but from what I've seen of Java, trying to code 00 Perl in the style most Perl programmers use seems to be quite a bit slower. Compare the speed of Lucene versus Plucene or XProlog versus AI::Prolog. Perl loses hands down. These started as straightforward ports which is part of the problem, but their coding styles don't seem significantly different from what I see many Perl programmers use.

On the other hand, I hear people claim that when Perl is coded in a more idiomatic style, it competes quite handily, but I'd like to see benchmarks against real-world applications rather than samples.

Cheers,
Ovid

New address of my CGI Course.

Comparing Java servlets with mod_perl handlers gives very close results. I don't think the slowness people often experience on Java sites has to do with the actual language as much as the choices made when developing in it.

But, I think the main point was that it's faster to develop the system in Perl. And it is usually going to be more flexable and thus easier to maintain in Perl than Java.

I'd tend to agree with this point, but will concede that it depends on the quality of developers on both sides of the fence; it's possible to write crappy perl that's not maintainable, it's also possible to write GREAT java that is as flexable and maintainable. I believe the latter will take a lot longer, and involve more highly skilled people to write than it will a good (GREAT?) perl version.

-Scott

it depends on the quality of developers on both sides of the fence

Paul Graham had a point about Java programmers compared with (in this case) Python. :-)

I do know great people that use Java, but still... I think he has a point.

(I'm no Python fan, so Graham probably doesn't care about my opinion. :-) I guess I could get used to the white space craziness, but it bores me. A nice lisp version might tempt me if I can choose language.)

Let's not spread FUD here: Java is not slow.

I think it's more a misunderstanding than it is FUD. When technical people hear "fast" or "slow", we tend to think in terms of how efficiently a technology will perform. But when business people use those words, they tend to mean "how soon can I have it?"

Well-coded Java might outperform well-coded Perl in some cases, but Perl (or Python or Ruby) will often get you there a lot quicker, without spending time wrestling with language that wants to put you into a straightjacket for your own good. Sooner and slower usually beats later but faster.

In this case, I'm pretty sure the OP was referring to execution speed, not development speed.

What FUD do you mean? Whenever I happen to stumble on a page with a Java applet while browsing the Net my computer basically just stops responding for several seconds. Whenever I start the stupid IP Phone application we have here it stops responding for 15-30 seconds. Not just that it takes 15 seconds for the app to appear, nothing else gets to do anything until Java loads and initializes and does other things I don't want to know about. Yep, FUD. Pull the other one.

Jenda


XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

We are not talking about Java applets here. This is about sites with a backend coded in Java and no Java on the frontend. That is the primary market for Java and has been for years. Applets were a short-lived fad.