SPUG: software libertarianism (was: Scope question)

[dancerboy]

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