Re: two good poems; Wether perl any good?

[Raju Mathur <raju@xxxxxxxxxxxxxxx>]

>>>>> "Sandip" == Sandip Bhattacharya <sandipb@xxxxxxxxxxx> writes:

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

    Sandip> [snip]
    >>  > > 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.

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

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

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

    >>  > 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.

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

Sandip, you're way behind times.  CGI is dead as far as I'm concerned:
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.

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

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

    >> 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

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

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 ;-)

    >>  > 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.

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

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

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

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.

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

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.

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.

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

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.

    >>  > 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?

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

Please note the ``as practised''.  I still stand by my statement, that
the clue-o-meter drops to below zero when placed near most so-called
OO programmers.  For the ones who do know OO, I repeat, they don't
need Java or C++ to implement 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.

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

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.

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.

    >> > > 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.

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

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.

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

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'll have to do a bit more than dismiss Perl with ``Perl can't be
compared with Java'' without being able to give any justification for
your statements.  I see two languages, one of which has corporations
worth nearly $200 billion (Sun and IBM) pushing it and spending
millions, if not billions of $$ per annum in promoting and marketing
it, while the other has $0 going into its marketing and just a team of
volunteers developing it.  The one language is slow, inefficient,
doesn't live up to its promises, closed and already forked, while the
other is fast, efficient, single-stream, open and delivers whatever it
promises to deliver (otherwise you get your money back ;-) Quick
searches through the 'net reveal more software developed using the
second platform than the first one, even though the first language has
innumerous certification courses and training schools while the second
is just imparted from one hacker to the other in secret rites.

Looking at all this, if I had to question the viability of either
language in the long term, I'd question the first one rather than the
second one, wouldn't you?

    Sandip> Regards, Sandip

Regards,

-- Raju
-- 
Raju Mathur          raju@xxxxxxxxxxxxx           http://kandalaya.org/