[BNE-PM] What do you use Perl for?

[Tony Obermeit]

Thanks for your comments, you have raised some interesting points.

I would also say that my original comments have demonstrated there are 
technical as well as non-technical reasons to drive the decision.

>>(1) I didn't want to ship my source code.  With java I am able to ship 
>>only compiled .class files.  This gives me a significantly higher level 
>>of confidence that a bug hasn't occurred because someone hacked the 
>>source code.
>
>I would reply, compilation != encryption, and I'm happy for anyone to have 
>my source. Yes this causes "friction" with management, so I do see your 
>point ...

My perspective on this is purely from a support point of view.  I have a 
packaged application that I have developed and I am trying to minimise risk 
of problems in as many areas as possible.

>As for modifying ... if they modify it they get what they deserve? Just 
>run a digest over the source directories, if it comes up different, tell 
>them to put it back. Or, just make the source files read-only!

 From a support perspective, they may get what they deserve but I still end 
up using valuable support resources and time determining the cause of such 
a problem.

>>(3)  I had challenges getting dbi/dbd::oracle working in a linux 
>>environment, with java, jdbc just seemed to work in any environment.
>
>I had just the opposite experience. That one just comes down to what 
>you're used to, I guess.

:-)

>>Java was much easier, I could ship a single .jar file that included the 
>>entire compiled code of the application, including the web server, the 
>>jdbc drivers and my application, that made it easy to install the 
>>application, copy a single .jar file to a directory and run with a single 
>>command java -jar jarfilename.jar.  There can be issues if the version of 
>>java on the target system is older than what you expect but the same 
>>applies to perl.
>
>Yes, but I often find that running a Java program or installing a Java 
>library is a lot of painful fiddlework with PATHS and JAVAPATH. With Perl 
>I just go:
>
>$ cpan
> > install Parse::RecDescent
> > quit
>$
>
>... and I'm done.

CLASSPATH is the root of all problems with java configuration.  It took me 
a while to get used to that, now, whenever a java application won't run as 
expected, I first ensure that CLASSPATH is set up correctly.  I even wrote 
a utility to help me debug my classpath.

>>With non-web applications in java the java GUI is not pretty, your 
>>comments below about java guis that are slow and large are quite applicable).
>
>And ugly, and *incredibly* hard to make simple stuff behave correctly and 
>consistently. Perl/TK, OTOH, is amazingly easy for GUI work.

I agree, and I hear the learning curve for swing is signficant as well.

>>They are both quite similar to use.  I haven't looked at how to do 
>>database connection pooling in dbi but it is quite easy now in java with 
>>jdbc2.  It can take more code in java to get some things done in perl but 
>>the object orientation in java is better than it was in perl.
>
>No, I'd say the object orientation in Java is not better in Perl. Try the 
>Class::Contract module, which gives you class invariants, abd true pre and 
>post conditions (and the pre conditions can refer to the previous state of 
>the object!). You can't do that in Java!

I'm hoping that pre and post conditions will come in to java in the future, 
some interesting work is being done in this regard under the title of 
Aspect Oriented Programming and a java implementation (AspectJ - 
www.aspectj.org) is available.

>(Java still doesn't have multiple inheritence - and don't tell me I don't 
>need it!)

I wouldn't presume to tell you that, I will tell you, however, that I don't 
need it... :-).  An interesting perspective on inheritance that is being 
stated by a number of the OO gurus is that when designing we should favour 
Object Composition over Inheritance which in my view diminishes the 
arguments for multiple inheritance.  Aspect Oriented Programming gets 
around some of the issues one would solve with multiple inheritance by 
providing "aspects" that stripe different functional areas of an application.

>>Overall, I would say the servlet api provides better capabilities than 
>>Apache + mod_perl but I believe a dedicated perl developer can build just 
>>as fast (if not faster) applications using perl with mod_perl.  One 
>>limitation with that is being tied to Apache.  With the advent of a 
>>number of pure java web servers, BEA, Orion, for example, being tied to 
>>apache can be a limitation.
>
>Do any of these Java web servers show up on http://netcraft.com? I think 
>Apache's the clear winner, and by implication much more trustworthy than 
>any of these other things. It comes down to the "only N engineers" 
>argument that applies to all proprietary development. And what if the 
>company vanishes, forces you to "upgrade", or silently desupports the 
>product chasing the latest over hyped bandwagon (Web services, anyone)?

I'd say it doesn't really matter if these servers show up on netcraft.  If 
you want to, implement servlets using Apache, that gives you all the 
strengths you mentioned and you have the choice of jserv or tomcat. I'm 
just saying that with servlets you aren't as limited as you are with 
mod_perl/apache, mind you, you can always drop the mod_perl and go for 
straight cgi but then I'd say servlets will likely perform better.

>>Organisations like IBM, Oracle, BEA, Borland and Sun have made 
>>significant investment in java.
>
>But if you can do exactly the same thing in 1/10th the time, and not have 
>to pay for an "Enterprise" server (whatever that is this week :) then I 
>think you're better off.

I agree, but keep in mind you can do plenty of java without paying for any 
Enterprise servers, the open source support for java is huge.

cheers

Tony