Re: two good poems; Wether perl any good?

[Sandip Bhattacharya <sandipb@xxxxxxxxxxx>]

WARNING! WARNING! This is a loong post. Raj managed to touch a tender
side of me. ;) I had to react to every point he said. ;)


On Wed, Feb 21, 2001 at 03:23:15PM +0530, Ambar Roy merrily said:
> Hi,
> 
> > I'm rather tired of this ``Do Java without thinking'' refrain I keep
> > hearing all over the place.  Here're some facts which anyone who is
> > planning to switch platforms should consider:


I agree there. Java has too much overhead for trivial applications, as
well as problems with system specific applications. Perl/PHP are great
for quick hacks. 
> 
> >
> > 1.  Java is slow.  In fact, it's so horribly slow that running just a
> > couple of Java apps can bring a high-end server to its knees.  And
> > we're talking about serious RISC-based servers here, not piddly little
> > Pentium-III PC's.

Uh huh ... what ARE you running? We have scores of Java web
applications running on our dual-CPU Xenon servers. NAS runs a JVM
inside it, and it does a real good job of it.

I am only talking of server side apps here. Java frontends are
agonizingly slow - I admit.

> 
> > 2.  Java is a resource hog.  I've created similar pages in JSP (which
> > allows you to embed Java into HTML pages) and Embperl (which allows
> > you to embed Perl into HTML pages).  The Java version ate up all the
> > RAM (256MB) on the system, while the Perl version was happily chugging
> > away in 64MB or less.  Even more entertaining was the result of ab
> > (the Apache benchmark, it's part of your Apache package) on the two
> > pages: the Embperl page was about 10-20 times as fast as the JSP page.

Ok. wait. Two points.
a) Do you or don't you agree that the CGI process model is all wrong?
I agree that a Servlet/JSP container has a significant overhead. But
say talk about 1000 hits a minute. a Perl CGI app(i have no idea how
EmbedPerl is implemented) is going to be loaded 1000 times into memory
along with the perl interpreter per minute.
In comparison, half compiled servlet/JSP codes in memory are *reused*
in every request. Which one do you think should run best? If it
doesn't now, it is because servlet/JSP implementation is still not
optimal. But the process model makes more sense than CGIs.

b) Your testing probably needs more rigour. Try sending 100
simultaneous requests to a servlet and a CGI and then see how much
resources they take. And yes, when testing JSPs, make sure that they
have been compiled by the server before subjecting them to the
test. This is generally done by running the JSP/servlet atleast once
before using them in a test.


> This is something that depends on what servlet/jsp container you use. I
> agree that with tomcat you can not scale jsp serving to any levels! embperl

Tomcat is still now a REALLY sub-optimal servlet container. It IS
getting better, but till then open-source folks don't have much
options. Enhydra - another option, in it's present avatar is too
container dependent.


> is no resource hog, and so isn't php i guess. but with jsp u can get very
> good designs and if written properly jsp gives very easy to maintain pages!

To tell you the truth, JSP/PHP/Perl are as bad as each other in terms
of design. Embedding code within frontend is an EXTREME pain if have
to maintain a site throughtout the year. Try maintaining a site in
either of these options, where the HTML design changes every two
months?

Whom would you employ for frontend changes - most likely a
designer/html person for making the frontend changes, and a programmer
to copy paste the code in the right places. And then the poor
programmer has to go through the whole code to check whether part of
his code had not been missed out/deleted in the whole process ... all
this for a frontend change!!! This is pathetic!

An alternative is to use templating system - Perl already has a fast
template library, PHP has fasttemplate/PHPlib while JSP is still
pathetically wanting .. it should not have been born at all!! Just
servlets with a templating system would have been enough!

> 
> > 3.  Java is not open.  Sun controls what goes into Java and sues
> > anyone who doesn't conform.  As far as I can make out, the primary
> > motivation for MS' bringing out C# was because Sun sued their pants
> > off regarding their (MS') Java implementation, and they needed an
> > alternative.  Of course, C# will be even more closed than Java, but
> > that's another story.
> > I would not bet my company's future on any product which is
> > proprietary and owned by a single organisation.  Sun has scuttled
> > efforts in the past to create an open Java consortium, and shows no
> > signs of accepting the same today.

Point taken. Sun controls the core and extended Java API. M$'s issue
was far more serious though. Java code is far more portable(not 100%)
than any other serious enterprise language that I can think of.M$
effort would have killed Java of its very USP. Gosh! Till date I
haven't managed to successfully compile a C/C++ program on two
different OS without changes to the code. This is when we have
standards like ANSI etc. Of course it IS possible a large body of code
that cross compiles, but C tempts you to get system specific a
lot. With Java you CAN'T. Some people find it bad. But then I would
readily accept a third party package in Java than a similar one in
C/C++. 

But Java is here to stay. The amount of library functions and third
party packages that Java has to it's disposal, makes it one of the
richest of languages right now. Ignoring it, is like ignoring business
concerns in face of moral concerns. It is your call, but most
businesses don't think of it that way.

Sun doesn't have a stranglehold on the "product" though. Just the
API. If you want a "free" implementation look at the GNU
Classpath project, Kaffe, Jikes, Japhar, and other Java
implementations. 

Yes, API is significant. But Java has too much peer pressure for Sun
to tinker about it much. 

> 
> > 4.  Java isn't as portable as it seems.  For instance, the last time I
> > tried to run the proof-of-concept Java Web Browser on a Linux box, I
> > found to my dismay that it needed Winduhs-specific DLL's.  No Java Web
> > Browser for Linux without system-specific libraries?  Where's the
> > portability?

You are making a mistake here. The JVM is ALWAYZ system specific. It
is the environment that it gives to Java *applications* which is system
independent. The Java Web browser needs windows specific DLLs so that
the multithreading requirements of Java applications running inside
itself is optimised by using windows native multithreading support. On
linux, this very JVM would try to use pthreads to provide
multithreading. On the other hand applets itself can be used
both on the Java web browser of windows as well as linux without changing.

> 
> > 5.  OOPS are highly overrated, at least as they're practised.  Most of
> > the so-called OO programmers I've seen wouldn't know a well-written
> > class if it came and hit them in the nose.  OOP implies reusability,
> > while all today's OO programmers seem to be able to do is split up
> > large functions into smaller ones in seperate files, thereby creating
> > ``classes''.  Where's the re-usability? where's the documentation?
> > where's the encapsulation? where's the facility for subclassing?

This is a different argument. For enterprise level applications, OO
based projects are inherently more maintainable. The implementers
inefficiency is no argument against OO concepts.

> >
> > Oh, I admit there're a lot of well-written classes available on the
> > 'net for reuse -- for instance, the various JDBC drivers.  But if it's
> > volume you're looking for, the CPAN (Comprehensive Perl Archive
> > Network) beats Java archives hollow: thousands of modules, most of
> > them properly encapsulated and explicitly meant to be subclassed.

OO is not just inheritance. Interfaces (among other things) are as
important. Perls implementation of OO goes only half the way. Also
have you taken a look at the complete Java Core API(i am talking of
just the core) completely? It has countless classes in the CORE Api
already, and with the extension packages Serial Communications,
Embedded API, JavaMail, Servlet, EJBs,  and scores others ... i don't
see where Perl comes in? Perl satisfies a part of it using extra CPAN
modules.Perl is not meant for enterprise level or 
serious business world apps. It has it's own place and it excels
there. It IS a wonderful langiage ... don't get me wrong!


> >
> > In other words, OO is a skill, not a function of a programming
> > language.  An OO programmer doesn't need Java or Perl or C++ to write
> > OOPS in -- s/he's equally comfortable writing them in COBOL, C or even
> > assembly.

OO in C? Assembly? COBOL? OO CAN'T be practiced in it's entirety in
every language! It definitley needs help from the language construct
itself. Try doing inheritance in COBOL! or C! 

> 
> 
> > To sum up, Java is a lot of hype and not much deliverable.  If you
> > want a job in the US, sure go ahead and learn Java since it's the
> > Flavour of the Day.  However, if you're serious about building systems
> > which run, run fast and run without stopping, look beyond Java for a
> > more open, more stable, more mature and more efficient.

In todays world, scalability, maintainabilty(with readability), design
friendliness is as important. I am not saying that Java is the best
solution. But apple should be compared to apples. Comparing Java with
ASP/C++ is understandable.. but not Perl (in serious business server
side apps)


Regards,
 Sandip

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