> -----Original Message-----
> From: owner-spug-list at pm.org> [mailto:owner-spug-list at pm.org]On Behalf Of
> dancerboy
> Sent: Friday, June 14, 2002 16:43
> To: spug-list at pm.org> Subject: RE: SPUG: software libertarianism (was: Scope question)
>> BTW, it's somewhat unreasonable to complain that a project was killed
> by "changing specs". Specs *always* change! Part of one's job as a
> developer is to create an architecture that's flexible enough to
> accommodate changing specs. Yes, there are reasonable, minor spec
> changes and unreasonable, radical spec changes. But part of my point
> is that working in a language like Java can make it much more likely
> that you'll be able to accommodate even radical spec changes in
> large-scale applications.
It is however, absolutely reasonable to expect that projects are killed by changing scope. In the consulting work that I've done, I've found scope control to be the largest factor that foretells project outcome, i.e., controlled scope ~= successful project. I don't mean this to necessarily imply causality, but it is a leading indicator.
You have yet to outline which specific facilities Java grants that make it more flexible, more adaptable to "radical spec changes". Hopefully, you'll forgive my "Show Me" attitude, but I haven't experienced these massive flexibility enhancements.
I have, however, seen some weird stuff in Java. Just off the top of my head:
Java sucks at list handling. Yay! 4,750 classes that handle arrays, and each of them contains precisely two (2) methods that you absolutely must have, so you convert like mad from one to the other. (N.B.: the 4,750 is a slight over-exaggeration, but the 2 methods is not an under-exaggeration)
Java sucks at structured data handling (LoL and HoH in Perl). Nuff said-- even C-octothorpe puts the pimp-smack on it.
Lots of little things, that should be simple, like file handling, aren't.
Too many classes to handle the same data types. Constant conversion from one class to the other, often requiring 1 or more intermediate class conversions.
Together, all these things (and the ones I haven't listed) provide a -50% productivity increase.
> Java is designed to encourage Correct solutions. Most Clever
> Shortcuts are difficult or impossible to code in Java. Perl, on the
> other hand, is the Clever Shortcut language par excellence. It's
> *very* easy to code Clever Shortcuts in Perl. However, Perl is also
> reasonably good at Correct solutions as well, *if* the developers
> choose to use it that way.
I'd like to see a "Correct Solution" to list handling in Java. Har.
I especially love that arrays (not the class, just native ones) are not classes, but they do have the class variable length. So much for the papal "Correctness".
Comparing the two languages, I'd say that I've seen more bad Java code than I have Perl code. Java continually feels more "hackish" (for the above reasons, e.g., list handling) than Perl to me.
> And if you're going to use Perl *as if* it
> were Java, then... why not just use Java?
Because perl offers better data handling capabilities, and most modern applications are all about manipulating data, or viewing data. I don't feel any need to back Perl's data handling (vs. Java) up, least of all on this list.
Brad
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
For daily traffic, use spug-list for LIST ; for weekly, spug-list-digest
Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org