Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

RE (tilly) 1: Java vs. Perl from the CB

by tilly (Archbishop)
on Nov 13, 2000 at 07:10 UTC ( [id://41253] : note . print w/replies, xml ) Need Help??

in reply to Java vs. Perl from the CB (no CB log included)

Gee, just goes to show me that you should never say anything in public that you don't want seen in public. :-)

Just to expand on my basic point. There is a fundamental trade-off between bureaucracy and individual productivity. However bureaucratic constraints are critical to having productivity scale across many interacting people. The trade-off I mentioned in language design is therefore seen across a broad range of human activities. In languages it shows up as organizational work. Declarations that must be made. Interfaces that must be defined. Things like type-checking. Every one of these slows down the individual programmer, but helps scaling to larger programs with more people.

Perl and Java are at opposite ends of that spectrum. Intentionally so. This is a statement of fact, which can be backed up by looking at specific design decisions, quotes by people who like the languages, and quotes by people who designed each language. Saying this is not a statement of bias.

It is important when making decisions to be able to recognize this kind of factor and decide accordingly. Choose the right tool for the job and all that.

Now for the flame-bait.

There is a flip side to that saying which is less often brought up. In addition to choosing the right tool for the job, you must choose the right job for the person. And what that job is depends for me on what the tools I will need to use are designed for.

Java is a language that has been designed (and sold) partly based on the PHB dream that you can replace programmers with interchangable monkeys. Perl by contrast is well-designed to take on tasks where programmers must be allowed to be competent and think for themselves.

So even though I agreee that there may be many jobs for which Java is a better fit than Perl, I prefer to work on jobs which Perl is a good fit for.

Besides which I have read The Mythical Man-Month, I notice random statistics, and I take them into account for my life. The relevance of this takes some explanation.

For obvious reasons, a disproportionate share of programming jobs out there are in larger projects. However the larger the project, the more likely it is that it will be a disaster. For projects that cost over a million dollars, this outcome is far more likely than not. Having been near (though luckily not really in) one multi-million disaster, I have little desire to be near or in another.

Therefore even while I can cheerfully explain all of the ways that Java is better for a large project, I would just as happily not go near such projects. And again I find that I prefer being around the kinds of jobs which Perl is used for. Things involving a small team of good programmers, taking on projects of a managable size...

Replies are listed 'Best First'.
RE: RE (tilly) 1: Java vs. Perl from the CB
by BastardOperator (Monk) on Nov 13, 2000 at 19:58 UTC
    Not being a programmer by trade myself (SysAdmin), could you give some examples of the projects to watch out for (i.e. larger projects), and those where Perl is a better fit?

    I have always wondered why there are so many Java jobs out there. I'd always chalked it up more to the hype of Java (which is probably still very true), but this really opened my eyes to the fact that the reason that Java is so sought-after may be exactly because it's great for larger projects with less skilled programmers.

    Java seems like a pretty decent language to me, but again, I don't have experience with software projects. The fact that it always whined when I didn't catch an exception, while helpful, was enough to annoy me. My last question, I had actually been thinking about learning Java, what would you recommend as a language to learn that has potential to carry a resume, as Java would now, has business appeal, as Java does, but which doesn't assert "B&D", as Perl does not?
      You are asking the million dollar question.

      For a sense of what you want to avoid, pick up the graphically titled Death March by Ed Yourden.

      How common are these? Well a 1997 study found that 55% of projects were at least 50% over budget, 50% needed at least twice the estimated time, and 30% were delivered with under half the desired functionality. (I have heard stats like this before, but my reference this time is citing an article that does not appear to be online.) And that is counting by project. Considering that disasters tend to be larger than non-disasters, this understates your odds of being in one.

      So how do you recognize a likely candidate? Well by a lot of things, but size is an excellent predictor. I don't know if they still do, but at one point Sun had an internal rule imposed by the CIO. Projects were limited to a maximum of 10 developers, a maximum of 1 year, and a maximum cost of $1,000,000. Any project exceeding those targets would be cut off because the risk of disaster was getting too great.

      Note though that Perl does not miraculously solve this risk of disaster. In fact at least one monk I know of is currently in the middle of a death march. Instead what Perl does is aims to allow you to get as much done as possible within parameters for your team which are relatively low-risk.

      One thing I need to make crystal clear. The risks that I am stating are for projects managed within the bounds of how most software projects are managed. There are ways to manage large software projects. IBM in particular has a series of projects which they decided ahead of time could not fail, which simply did not. I cannot track down the exact quote, but the person who was in charge of designing the AS/400 says that if development teams cared about quality they would not have all of the bugs. Well considering that the industry average uptime for an AS/400 is 99.9%, he may have a point. (When they went from 32 to 64-bit, your programs just ran a little slower the first time you ran them.)

      Now about your last question. Well I am the wrong person to ask that of. I have no interest in worrying about my resume. Three years ago I was just beginning in computers. In two I get to leave New York City. In between I have a job I like programming Perl...