SPUG: software libertarianism (was: Scope question)
dancerboy
dancerboy at strangelight.com
Fri Jun 14 18:43:14 CDT 2002
At 3:44 pm -0700 2002-06-13, Bradley E. Young wrote:
>jason,
>
>Changing scope (poor management) killed the project, based on his
>statements. The language didn't have anything to do with it.
Of course I don't actually know the details of what killed this
project -- most likely it was a combination of factors, with choice
of language being one of them, though not necessarily the most
significant. My point was that, if one is feeling uncharitable (as
apparently I was when responding to that post) one could easily
interpret that post as a list of *excuses*, blaming management for a
failure that had more to do with the developers. Yes, the OP
*claimed* that the death of the project was due entirely to
management, but "reading between the lines" one could easily come to
a different conclusion.
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.
>
>I still haven't seen anything that you can point to that offers even
>a whit of proof that Perl is less capable than, say, Java for large
>scale projects.
Based on the (mostly constructive) criticisms people have made,
here's my new, improved take on the Java vs. Perl thing:
It seems to me that there are essentially two different kinds of
solutions to any coding problem: there's the Correct way, and
there's the Clever Shortcut. (I'm not going to try to define exactly
what those terms mean; and there are, of course, gray areas. But I
think anyone who's been coding for any length of time will understand
intuitively what I'm talking about.)
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.
Now understand that Clever Shortcuts are not necessarily Bad: they
are *shortcuts*, which means that they do speed things up (usually
development time, but sometimes Clever Shortcuts are used to reduce
system resource usage instead). Whether to use a Correct solution or
a Clever Shortcut is really an optimization problem, based on the
following observations:
* The advantages of Clever Shortcuts (decreased resource usage,
whether those resources are system resources or development
resources) relative to the corresponding Correct solutions tend to
increase linearly with code size.
* Correct solutions and Clever Shortcuts are both apt to contain bugs.
* The difficulty in finding and correcting bugs in Correct solutions
tends also to increase linearly with code size.
* The difficulty in finding and correcting bugs in Clever Shortcuts
tends to increase *geometrically* (or perhaps even exponentially)
with code size.
So, for small applications, Clever Shortcuts are clearly
advantageous. For large applications, Clever Shortcuts become a
nightmare. And the larger the application, the less room there is
for the occasional Clever Shortcut here and there in the code.
The problem is, most developers (myself included) find it very
difficult to eschew Clever Shortcuts altogether. When faced with
some specific problem that seems trivially solvable with a Clever
Shortcut, but for which a Correct solution would be a real
pain-in-the-ass, most of us will give in to temptation and use the
Clever Shortcut "just this once". (One little global variable isn't
going hurt anything, right?) But with large projects, these little
deviations from Correctness have a way of adding up, until an
originally clean and tidy architecture becomes a jury-rigged mess.
Java is sort an answer to the Lord's Prayer, as applied to software
development: "lead us not into temptation, but deliver us from
evil..."
Now, if you can find a team of Perl programmers who are able and
willing to code everything using nothing but Correct solutions, whom
you can depend on never to indulge in Clever Shortcuts, then building
a large-scale application in Perl might work just as well as doing it
in Java. But 1) such developers are hard to find, and 2) what this
really means is that you need your developers to code in Perl *as if*
they were coding in Java. And if you're going to use Perl *as if* it
were Java, then... why not just use Java?
(And just to clarify: I never said that you *couldn't* code
large-scale application in Perl, only that it was a poor choice in
terms of the development resources needed. Of course it's *possible*
to code a large-scale application in Perl. You can code a
large-scale application in assembler, given enough time, developer
resources, and masochism. That doesn't mean it's a smart choice.)
-jason
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
More information about the spug-list
mailing list