Re: two good poems; Wether perl any good?

[Sandip Bhattacharya <sandipb@xxxxxxxxxxx>]

Hi Raj!
 
Before folks start thinking of me as a Perl doomsayer let me clarify:
Perl is a great scripting language. 
1. It's language support for regular expressions (unlike PHP with
specialised regular expression functions,Pythons "compiled regular
 functions", Java's third party support of RegEx) makes it the
unbeatably best option in programs involving parsing and stuff.  

2. It's motto "there is more than one way to do it" is evident in it's
language construct. You can write code that resembles C or Java code
in readability or you can go ahead and compete in obfuscation
contests. Lack of readablity in Perl is an often touted
disadvantage. But it is totally in the hand of the perl programmer
whether he writes beautiful looking code for other folks to
understand, or he just gets the job done - maintanability be damned.

However some of my points still stand.

> I'm talking about server-side apps too.  Forget about server-side,
> I've seen standalone Java apps killing high-end servers.

JVM startup times have always been a point against Java. Standalone
java programs called number of times would obviously bring *any*
computer down with each instance needing the whole JVM to come
up. Server-side is right now the only place where Java has a fighting
chance with the JVM taking time only when the server comes up.


> products like Embperl allow you to *embed* Perl into HTML and
> compile-once run-many.  There's no question of a fork-exec since the
> Perl interpreter is loaded into memory with the web server, and you
> end up getting an Apache with Perl as an embedded language.  Embperl
> == JSP with the J replaced by P.

Ok. I see. embedperl = mod_perl+PHPness. Goodness! why did Perl have
to fall in this trap of JSP/ASP?
Embedded code in HTML in one of the nastiest, unmaintable coding model
that folks could think of. Great, so now you can have an site up and
running in much shorter time. What next? In a typical Web Application
project, the client makes you change design 3-4 times before
finalising the project for release. What would you do in this case?
Hunt, cut copy, paste the new HTML code in all the embedperl pages
hoping that you don't onerwrite any perl code in the process?
EmbedPerl is just a RAD tool giving you an "impression" that you
finished  coding early. Give me mod_perl + FastTemplate.pm any
day. I will live longer.

> 
> Been there, done that.  I used ab with simultaneous requests ranging
> from 20 to 500 for both tests.  JSP dies, Embperl keeps chugging
> along.

I have subjected my servlet code running on Tomcat to 100-500
simultaneous requests with each request needing a MySQL Database
connection. Tomcat DID almost bring the system down after the count
reached 400.

HOWEVER, on NAS on an NT with Oracle  with database pooling, the
machine didn't flinch even after 500 simultaneous requests.


> I've seen commercial JSP implementations in action, and wasn't
> particularly impressed by them either.  If Tomcat is sub-optimal and
> commercial ones are optimal, God help JSP ;-)

For a person who earns his bread by writing Java code everyday, I
personally dislike the JSP model. I prefer discussions on Servlets
howver. ;)

> Perl is the most portable language I've seen.  Programs run without
> change on Unix, VMS, Winduhs, OS/2, Linux, you name it.

I have some points to make here.
1. I had sometime back been given the assigment to port a large amount
of Perl code from Linux/Apache to NT/IIS. After searching, I found out
that the latest "recommended" version of Perl for windows in
ActivePerl from ActiveState with PerlIs.dll ISAPI module. Have you
ever been to this site, Raj? It gives you a binary perl package, that
you have to install using the M$ installer(You have to download the
installer first ;), M$ has a separate installer for Win9x and
NT). This package uses the ActivePerl PPD installer for all it's
work. You CAN'T use the CPAN module, because you can't use any CPAN
package. In windows nobody assumes that you would compile and install
a CPAN package, since you need a development environment(read VC++
etc) for that. So all you have is a lot of compiled Perl modules. Wait
there is more. The compiled Perl modules have to be downloaded from
the ActiveState site only! If your package is not there, well you can
sit twiddling your toes till they come up with one. 
I don't see much portablity nor OpenSourceness in all this unless I
have done things all wrong.(Which I might have since I am not exactly
a Perl guru). Somebody care to enlighten me on this?

2. Most of the Perl code are actually half perl, with half the code
   being shared C modules which have to be compiled when you install
   them, and loaded on the fly using Dynaloader.pm. While most of the
   Java code is pure Java, with minimum native 
   depndency (except the JVM of course). If we start writing half the
   Java code in native form using JNI, I am sure they would be much
   faster. Take a look at any perl package while it is being installed
   - and keep a count on the number of C files each needs to
   compile. 
   e.g. I want to connect to a Mysql database:
    a) Perl: I try to install DBD::mysql. It fails saying that it can't find
             mysql.h and libmysqlclient. I install MySQL and
             MySQL-devel. It is happy. It merrily compiles a dozen C
             programs linked against libmysqlclient.a and calls them
             via native invocations using Dynaloader. I shudder to
             think if I attempt the same in windows. compile? in
             windows? mysqlclient.dll? VC? I give up. I rather download
             a activeperl DBD:mysql package(which i had done) which has
             been compiled in with mysqlclient code. No , the argument
             here is not that Windoze doesn't have a development
             environment or not . The argument here is of the strong
             link of perl to native code. If portability means that of
             enduser programs and not even third party packages it is
            a different  question.
    b) Java: I just download a type 4 Pure Java mysql driver, drop it
           in the  classpath and I am ready to go. I can use the
           *same* driver in all platforms without *any* extra effort
          other than putting it in the classpath.

 Java and Perl differs here. So does PHP. Java programmers try their
 best to do everything using ONLY Java(you always have the option of
 using native code though). Perl mostly extends using libraries
 which are actually are native code with a Perl interface. PHP doesn't
 allow native code. All PHP extensions HAVE to be implemented in pure
 PHP.

> 
> I'm not ignoring it, I'm denigrating it ;-)  As far as libraries and
> III-party packages are concerned, I'd like to see some statistics.

Java 1.2 has 59 packages containing 1457 classes implementing 14618
methods. And these are only the public and protected
classes. Bloatware? I don't think so. Take a look at the classes and
tell me which ones are unnecessary? Of course, I admit, Java 1.2
includes the whole GUI toolkit which could have been made separate
(like the swing toolset earlier). But if you wanted to make a
standalone Java GUI app, you would need it all.

And about Perl being small. the core Perl package has very few stuff
that you can actually use in a large application. Add the Perl/Tk
interface, and the n different modules that I have to install
everytime I set up Perl on a remote server for our developers and it
is a different story.

> Ah, the infamous fork-bomb!  If you have to fork a language to make it
> open, you may as well not use it in the first place.

Forking? No - choices - Yes. How I wished a year back that i had an
alternative to ActivePerl on windows. 

Secondly, the language is the same. There are choices that you have
with regards to the implementation. You already have that in Perl. You
have the Perl distrib from the Core group and a separate package from
ActiveState. Has the Perl language forked? No. Your programs run the
same way in both. But you have a choice of the interprator under which
your program runs.

As the Samba creator commented when SAMBA split up into two parts -
Samba and Samba-TNG, "A world with only one choice, is a very boring
world indeed". ;)


> 
> Sure Kaffe's a good piece of software (AFAIR it still won't run the
> Oracle Java Installer, though).  However, what makes you think Sun is
> sitting on its fat a** waiting for Kaffe to reach enterprise
> readiness?  Knowing Sun, they have their programmers working all night
> right now on extensions and enhancements to Java to make sure Kaffe
> never reaches 100% compatibility with ``The Java Specification as
> Written By God, aka Scott McNealy''.  In other words, forked projects
> waste valuable resources and you have a high chance of ending up with
> two sub-optimal products instead of one optimal one.

Kaffe is too small and primitive to be Suns concern. Sun is too much
involved in taking Java in every nook and cranny of Computers before
M$ reaches there. 

> 
> Nope, I'm referring to DLL's which were not part of the standard JVM,
> but which were required to run the Web Browser.  In other words, the
> so-called platform-independent Java app required some very app- and
> platform-specific libraries to run.

Are you basing your whole concept on Java on the basis of just this
browser? For goodness sake which is this piece of software which is
causing you so much heartburn ? :D

> 
> Could you elaborate on how Perl isn't meant for enterprise level or
> serious business world apps?  Apart from the statement, ``20% more
> businesses use Java then Perl, so Java is an enterprise-class
> framework for development'', of course -- no circular arguments
> please.

Distributed objects, Transaction management, Component technology,
Native toolkit(perl depends on external toolkits).
I could name much more, but this is an unequal comparison. I could
include much more , but they have been implemented in C and given Perl
interfaces, and called Perl implementations.

> 
> If you're referring to the fact that Java has more classes in the core
> than Perl does, no problem, just make your own ``Bloatware Perl'
> distribution which includes core Perl and all the 6500+ CPAN modules.
> I personally wouldn't do it, but if it satisfies the requirement of
> ``number of modules in core'' you're most welcome.

I agree. We could have had just the Java.lang package and have asked
the developers that when you need it , "download/compile/install it". 

But I am okay with what I have now. 90% of the things that I would
like to do is already here - GUI programs, encryption/decryption,net
related, cryptography, 2D graphics, applets, and many many more. If I
need anything more I can just download the Java compiled code, drop it
in the path and start using it rightaway - no compiling and stuff, w/o
regards to the platform that I am running it on.

> 
> Stdio is a derived class of the kernel file I/O functions.
> Inheritance is nice with languages explicitely designed to support it,
> but it's no big deal to implement it in III-generation languages
> either if you can think clearly.

Macros/wrapper functions are not exactly derivations. I agree, that
you CAN to a limited extent, apply OO constructs to languages. But
given an OO design, you would have to bend yourself trying to
implement it.

You are more likely to bend the design to support the language, rather
than bend the language to go ahead with the design.

> 
> You know, I could substitute NT for Java and Linux for Perl in that
> last statement, and it'd sound like exactly the sort of thing MS would
> have said a couple of years ago :-) Now, of course, they're busy
> bringing out ads which try to kill Linux -- not that it has made any
> difference to Linux growth.


You know, somebody had once told this, "Don't start optimising, until
you have to. It is better to write good code first."

I will start worrying about Java performance issues(i admit they are
there) when they actually start affecting the application in
question. My livelihood is server-side applications. Till now I
haven't seen any performance issues. For low end applications, I
recommend Tomcat, middle level - JRun, High End - NAS. 

For GUI based apps, I would rather recommend C/C++ than Java right
now. The performance/resource  issues are too delimiting to ignore.

Regards,
 Sandip
-- 
-------------------------------------
Sandip Bhattacharya 
sandipb @ bigfoot.com
http://www.sandipb.net
-------------------------------------