perl used in large developments - I need help

[Bill Penrose]

Simon

I saw some discussion on Per or not to perl last month and though you
may be interested in the comment below. It comes from Bruce Eckel
http://www.mindview.net in his artice http://www.mindview.net/WebLog
Dated 3-23-03

Regards
Bill Penrose


Yesterday's entry has me thinking (again) about the issue of hurdles -
any obstacle, especially small ones, that causes resistance to doing
something. I'm convinced that these hurdles are cumulative. I took a
workshop once called "Kaizen" which is supposed to be a Japanese word
meaning "small steps" or something like that. The teacher began by
showing experiments with a stuffed cheetah and chimpanzees in Africa. If
the cheetah jumped out, then the chimpanzees panicked and ran away, but
if the cheetah was moved very slowly into the environment, the
chimpanzees didn't notice it. The teacher related this to the primitive
part of our own minds, so that if you tried to make any big changes
("I'll go on a radical diet and exercise program starting tomorrow")
then your mind panics at the enormity of the change and find some way to
avoid that change.

His solution was to introduce changes very subtly, like the slow-moving
cheetah. You might say "I'll floss once a month" and your brain says:
"Not a problem. I won't even notice a change like that." Or you might
try to meditate one minute a day, such a short time that it will have
very little apparent impact on your schedule. A popular new exercise
book advocates "8 minutes in the morning," an amount that would be hard
to argue against.

I think features in programming languages or computer programs in
general must be treated the same way. It's nearly effortless for an
expert in a language or program to acquire and use a new feature, but
for the vast majority of people the number of steps required make it
prohibitive, and you get a big disparity - the expert says "it's easy"
and doesn't understand why everyone isn't doing it, while the unwashed
masses puzzle over how they might even approach the issue.

As much experience as I've had with computers, I find myself resisting
hurdles, especially ones that accumulate. The weblogging situation is
one example; to use the slashdot version requires a certain level of
expertise and the number of options and settings is rather large and
mysterious. That sets up a level of resistance in my brain to doing it,
whereas with this system (A Zope STX page) I can just type.

I think programming languages are more subtle, because they are all
about learning a body of knowledge. You "just learn it and apply it."
Again and again I've heard people talk about how easy it is to do
something in a language, and because they are convinced of this they are
unable to see the small hurdles that accumulate to eventually create a
roadblock that prevents accomplishing something with that language. 

Perl is a perfect example of this - when I first encountered that
language, I had a love affair that lasted about 2 months. I think
primarily this was because of the interactive nature, but also because
of the terseness - you don't have to type much to get something done.
The bottom line is that you can get a lot done in a short time, and to
me that's what computers should be about. However, Perl's arcane syntax
made programs hard to read and maintain, and as a result limited the
scope of what you can accomplish with the language to relatively small
programs (I have heard numerous testimonials of significant failures
when trying to use Perl for larger projects). For me, the wall came when
I tried to use references and classes; these had clearly been hacked on
with no thought to usability and I think a major reason for the
popularity of Ruby is that it servers Perl programmers who couldn't do
anything with objects and references in Perl. Further observations and
conversations about Ruby have not convinced me to spend more time with
it; I think it might be a path of least resistance for Perl programmers
who want objects, but I'm still convinced that Python is the best path
for me.


-----Original Message-----
From: owner-melbourne-pm at pm.org [mailto:owner-melbourne-pm at pm.org] On
Behalf Of Simon Taylor
Sent: Thursday, 20 March 2003 10:50 AM
To: Melbourne Perl Mongers
Subject: perl used in large developments - I need help


Hello fellow perl mongers,

Our company has had a very interesting challenge given to us today.

We have been involved in tendering for a project to rewrite a large US
ERP application (currently written in FORTRAN and using c-isam data
files).

We lost the tender in January to a company that has since recommended
java (or 
c#) as the language of choice, and has also recommended rewriting the 
application from scratch. 

Our competing tender was based naturally, on perl, and on rewriting the 
application incrementally.

The winning tenderer's solution has now been dismissed as too expensive
and we 
are being asked to show why our solution should now be chosen. There are
no 
others tenderers involved. (If we win the project, we would do only a
portion 
of the coding ourselves, other firms would be involved, and would be
using 
perl because our design mandates it).

All the application-specific arguments aside, it is coming down to:

   * Why on earth are you recommending perl?  
   * Nobody knows perl, 
   * Everybody develops large scale apps in java, etc, etc.
   * perl's too slow isn't it?

and incredibly, 

   * who supports perl

What I desperately need now is pointers to good quality descriptions of
larger 
applications developed in perl.

I have good examples in Fastmail.fm and Radiator, but I'm also keen to
be able 
to table other applications, the larger the better. We know that lots of
organisations around the world "use perl" in powerful ways, but the same
sites 
"use electricity" as well, and just as with electricity, their uses of
perl 
are transparent to the outside world, and hard to identify.

This is an 800,000 line application used by Fortune 500 companies in the
US, 
it would be quite a win for the perl development community.  

Regards,

Simon Taylor
-- 
Unisolve Pty Ltd - Melbourne, Australia
+61 3 9568 2005