On Tue, Apr 06, 2004 at 10:25:47AM -0200, Gabor Szabo wrote:
> ... and the VP will respond something like this:
>
> >
> > - Perl is an Open Source language with world wide support of a large
> > enthusiastic community independent from 3rd party corporate
> > interests
>
> It does not have a "father". What if those people lose interest. What if
> we have a problem and those kids are not interested in fixing it.
> We cannot afford to invest in something so risky.
What if these microcomputers all stop working on 1/1/2000?
Yes, there's a risk. In theory it's a huge risk, but in practice, it's
effectively mitigated. Perl has gone crises of confidence before, and
yet it still thrives. There are currently 5 (!) actively maintained
branches for Perl today, only two of which are for long term development
and experimentation.
Furthermore, Perl is much better suited for the long haul than other
open source languages. If you were to choose, say, VB.Net, Lua or
Groovy for your infrastructure, who knows if the language will continue
to grow over the next 10 years? With Perl, there's not only a large,
active base of developers, but also The Perl Foundation who acts as a
steward over Perl to support development over the long haul.
> > - It's no spring chicken. Perl has been around for many years, and
> > it's used because it's good, not because someone sold it as
> > vaporware very well
>
> Perl is an old langugage, does it have objects anyway ?
C++ is an old language, about as old as Perl. Does *it* have objects? ;-) [1]
> > - Perl is quite lightweight and tipycally does not need big hardware
> > or expensive application servers to run, like Java does
>
> Hardware is cheap, it is not relevant.
Hardware is most certainly relevant. On the one hand, you can throw
memory, disk and CPU at a single box to scale up an application. At
what point does that become cost prohibitive? 16CPU servers? 64CPU
machines, 4GB of RAM per CPU?
Eventually, for scalability and reliability, you need to move to a
server farm. If you need a server farm just to run your (big, bloated)
application, you're going to come to some nasty, thorny systems
management issues that are very costly to solve properly.
By choosing a more lightweight platform, you postpone those hard
problems that are expensive to solve. You can still throw memory, disk
and CPU for scalability, but with much better ROI. You can migrate to a
server form for reliability, scalability or both, but at a time of your
choosing, not your application's.
> > - If finding Java programmers is easier, then finding bad Java
> > programmers also is. Quality and quantity differ.
>
> Perl scripters can't even read each others code.
You can hire one of two types of programmers - those with shallow
knowledge of a programming language, and those with deep knowledge of
the craft of software development.
Shallow coders will have trouble reading each others code, regardless of
the language. Deep coders will be able to read code written by anyone,
in many languages. Shallow coders are cheaper, but build buggier
systems due to their lack of experience. Deep coders write less code,
code faster, are more disciplined and make fewer mistakes.
Who do you want to hire? If you hire deep coders, then reading other
people's code is not a problem, regardless of the language you're using.
> > - A bad OO Java architecture has tipycally tragic performance
> > problems and is hard to reengineer. A poorly implemented Perl
> > architecture is more easily tuned and fixed
>
> Perl is an interpreted scripting languge. It is known to be slow.
Perl is compliled, just like Java. The three major differences are that
(1) Perl bytecode is not saved to disk, (2) eliminating the separate
compilation phase makes Perl easier and quicker to develop, and (3) it
is easier to optimize slow parts of a Perl program by running compiled C
code than it is in Java.
> > - Perl also runs everywhere
>
> Does it run on mobile phones and on PDAs ?
Does your application run on mobile phones and PDAs? I thought not.
> > Of course there are pros and cons. I can tell you that by my
> > experience that Java sells better as a concept (it helped to sell
> > lots of computer mags in the past) But at the end of the day, Perl
> > applications are usually much more flexible for changing and
> > tunning. The simple thought of EJB and EJB-QL makes me be sure of
> > this.
>
> So what are the pros ?
- Faster development
- Quicker turnaround
- Smaller teams
Z.
[1] OOP is a phase. Before it we had "Structured Programming", and
after it, we have "Aspect Oriented Programming". There are some big
minds in the OOP world that are thinking about what's next after
objects. Much of what they forsee has been present in Perl for
at least 10 years.
