I chuckled at a couple of quotes in Java performance improvements touted, specifically one from Cliff Click:
As your program grows in size, the lack of strong typing basically kills your ability to handle a very large program and so you don’t find the million-line Perl program.
I’ve met Cliff, and he’s very smart, but I have to disagree on two points. First, no one who’s used anything with a better static type system than Java consider’s Java type system “strong”. (If you can still get a NullPointerException from a generic-enhanced collection, Java has a ways to go.)
Second, the reason that there aren’t many million-line Perl programs is that the people who are capable of writing and managing million-line Perl programs have better ways to organize their projects than glomming a million lines of Java into a single shared-everything instance. That’s setting aside the qualities of encapsulation and abstraction that Java-the-language doesn’t have, preferring instead to push that problem to tool vendors and AbstractFactoryFactoryInjectors which consume vast swaths of XML to get around Java’s static code fetish. I can only imagine how much larger the Java code would be without all of those XML files.
I also recommend James Robertson’s take on things, from Earth to Sun.
I’m curious to hear how many million-line Java applications exist in the world and what they do. I suspect that they’re primarily web applications that speak SOAP or REST over strict SOA or HTTP boundaries — just the sort of boundaries beyond which it doesn’t matter if your code is Java, Perl, C++, or the Korn shell. You know, because they’re completely network bound.
I've always found it irritating how some people from the Java crowd sustain that all that XML is so wonderful because it frees you from writing code. How do I free myself from all that XML?? Somehow these people have gotten into a trance about making things more and more configurable, but they'll never use it all. Hibernate is just a pain, for instance; having all my database code in procedures has made my Java projects a lot simpler (and I call call them from Perl as well!).
An HTML typo apparently omitted this text (following the initial quote) from the author's (original) post:
"I've met Cliff, and he's very smart, but I have to disagree on two points. First, no one who's used anything with a better static type system than Java consider's Java type system "strong". (If you can still get a NullPointerException from a generic-enhanced collection, Java has a ways to go.)"
Thanks, Conrad. I've updated the HTML.
I'm helping maintain 300 kLOC of Perl code for configuration management of AIX, Solaris, and Linux systems. I wonder how many LOC this would be in Java? ;-)
It's using XML, too, BTW. But not for internal communication.
More and more US naval military systems are being developed in Java because of the standardization of the Navy’s Open Architecture Computing Environment (NOACE). NOACE applies to all future software systems on Navy warships. Ada is quickly being replaced by Java in this sector. A delivered combat control system can easily top a million lines of code and that's just one segment of a ship's total computing environment.
Lack of typesafety is a major drawback of any scripted language. This makes maintainability relate linearly to the number of lines of code in the system and is a huge problem as the number of developers increases.
That being said, typesafety can be a real nightmare. Look at all of the Design Patterns pertaining to object creation that have to be implemented to replicate Perl's ability to load classes at runtime.
I would have though the Perl community would have gotten over their insecurities by now. IMHO, being honest about Perl's Cons will go a long way in dispelling many of the Perl Myths.
ServerHerder, are you sure that type safety (or even type correctness?) is the maintenance problem if you have hordes of developers who can't communicate? Typesafe != Correct, and if you rely on developers to get your system's types correct, you're going to have problems.
Oh, and that buggy code I wrote is in a language much more concise than Java and an example much more constrained than your average million line application. How precisely is Java going to catch those errors? Magic?
I'm not saying that typesafety makes code bullet proof. My point is simply that Perl lacks type safety and type safety is a HELP when creating and maintaining frameworks.
It's better to find out at RUN TIME that your object doesn't support the given method than to have the compiler identify that? Maybe I'm missing something OO'ish about Perl, but I don't think that a run time call to $obj->can('Method') is the best way to do this.
Type safety helps communicate information about an Object, Method or function call to developers. This is not helpful? New devs should Just Know that this method returns a List of Lists or Foo::Bar objects? Once they do, they should then Just Know what Foo::Bar objects are capable of? Oh yeah, I forgot, they should just read the Foo::Bar Pod ... I'm sure that's both complete and up-to-date.
If you can't trust your developers to write accurate documentation and keep it up to date, why are you paying them to write software?
In a decade of writing Perl and other languages without static typing, the only time this has bitten me was when I either failed to read and comprehend the documentation or I had a local bug somewhere within five lines of my problem. With the kind of discipline I expect from professional developers working in any language, this just isn't a problem with regard to bugs.