Hi there, in reply to his questions...=20
>not have a "father". What if=20
>those people lose interest.=20
>What if we have a problem=20
>and those kids are not=20
>interested in fixing it. We=20
>cannot afford to invest in=20
>something so risky.
What about all those VB6 applications everybody got stuck with VB.NET? =
What about Sun fiering 10% of it's staff? Very relative argument, risk
>can=20
>buy the same things for=20
>Java.
>Where can I buy support for=20
>those libraries on CPAN ?=20
>What about copyright issues=20
>? I'll need to ask our lawyer=20
>($200/hour) for every=20
>library we download.
You can buy, yes. And have your staff waiting in line for tech support. =
Jar's also have licenses.
>Perl is=20
>an old langugage, does it=20
>have objects anyway ?
The point being?
>So you say it=20
>might not fit? I want to=20
>decide on our language of=20
>choice NOW ! And yes, BTW=20
>what you pay is what you=20
>get.
A bad implementation can allways happen, regardless of language. And if =
you're not 100% sure whatever the choice, Perl has this advantage over =
non-free competitors. Btw: what you pay is what you get? Have you heard =
of Vignette :))
>Hardware is=20
>cheap, it is not relevant.=20
>Does Perl have such a wide=20
>choice of Application Servers=20
>?
Hardware is cheap? Good for you, my friend :) Perl and 9iAS don't go =
together. I can live with that, can't say it makes me sad :)
>Perl=20
>scripters can't even read=20
>each others code.
Well, most of the time it's Open Source, so yes we can ;)
>Perl is an=20
>interpreted scripting=20
>languge. It is known to be=20
>slow.
Although not like some years ago, JVM's are still slow. C is faster. =
Well, there are great modules for caching at CPAN your lawyer should =
know of, like storable and mason. You can allways tune your applications =
very easilly and effectively in Perl
>Installing=20
>50 modules from CPAN is a=20
>nightmare.
Although I don't agree, it's done only once, although 50 is a big =
number. There's a CPAN module that helps you do the job. If you can't =
already do it through some package manager, of course
>Does it run on mobile phones=20
>and on PDAs ?
Porting your J2EE applications to J2ME is not an easy task. Is this a =
requisite?
>So what are the pros ?
Listen, my advice to you is: think very carefully about your real needs =
and everything else will follow. There is a number of pretty decent =
languages, and Perl is one of them, and so is Java. First just find out =
what your real needs are before you decide. Otherwise you're just having =
a 'yet another vi vs. emacs' academic discussion.
If you have the freedom of choice, choose wisely.
Cya
|
