Subject: Perl vs. JavaScript ASP with IIS

From: Shlomi Fish <[email-masked]>
Date: Mon, 11 Feb 2002 08:52:01 +0200 (IST)

I once over-heard a Technion student who was hired to write a web
application. He did it in Perl and was very thrilled about it. He said,
among else, that in Perl it is possible to write in one line, what will
take 50 or so lines in C. (this has become quite a shop-worn concept, but
he said it).

Some time later, I heard him say that they eventually abandoned perl in
favour of JavaScript ASP, because Perl did not run too well on IIS. So he
said he had to convert his entire code to JavaScript (Perl -> JS == Ouch!)

I believe they made a very bad decision from the following reasons:

1. ActiveState sells a mod_perl-like Perl subsystem for IIX called PerlEx.
It costs quite a bit, but sounds very nice.

2. JavaScript is not available at all for UNIX (unless you count
ChillySoft's JS which is not entirely compatible with MS') Perl is
available in both places.

3. Perl has an added cost for NT. ASP has an added cost for UNIX and
Linux. However, Linux/BSD software can have no added cost at all, and thus
a hacker may not be able to afford the added cost there. NT, OTOH, costs
money in the first place.

4. Some things in Perl (like Regexps) are written in an optimized C code,
which will require looping or the such in JS. This may make the code much
faster in many cases.

5. Perl is obviously a more powerful language than JS. And has much more
APIs available (via CPAN). And again, the equivalent JS ASP APIs have an
added cost.

6. You can always buy better iron. Or choose to run it on a faster
computer.

What I said about Perl applies to PHP, and to lesser extent Python and
Java. I don't see a reason why they dumped Perl in favour of ASP JS which
is highly proprietary, picky and limited. Obviously, they chose Perl in
the first place, so running it on NT was not an issue.

I have many other anecdotes about web technologies, but I'll postpone them
to later on.

Regards,

	Shlomi Fish

There is no IGLU Cabal! They had to write a web application in an API
(which chose to remain nameless) in which one has to call CreateFile with
6 or 7 arguments just to open a file. By the time they were finished,
someone wrote a 30-line perl script that did exactly the same thing.

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"

---

From: Chen Shapira <[email-masked]>
Date: Mon, 11 Feb 2002 10:55:16 +0200

> said he had to convert his entire code to JavaScript (Perl -> 

If he had more in his ASP other than creating objects from COM, calling
their methods, loops and i/o, he deserved what he got. If he programmed
right the first time, it was probably quite simple, as the important APIs
didn't change.

> available in both places.

ASP isn't availble on UNIX without chillysoft. COM isn't too common in UNIX
either.
Portable ASP must be very wrong and unmaintainable ASP.

Use JSP for cross platform stuff.

> which will require looping or the such in JS. This may make 

There's a REGEXP engine for ASP.
Pretty damn good too.

> APIs available (via CPAN). And again, the equivalent JS ASP 

I agree that Perl has lots of power through CPAN.
But if you write ASP, you have the power of COM objects. Lots and lots of
them are availble.
In fact if you are unhappy with performance, you can easily replace JS/VB
code with C.

About the power of Perl vs. JS: Don't get me started, but I'll just mention
that in ASP, less powerfull is usually better. ASPs should be as simple as
possible and contain mostly calls to external COM objects.

> I have many other anecdotes about web technologies, but I'll 

I'm eagerly waiting :-)

> someone wrote a 30-line perl script that did exactly the same thing.

I know it was a joke, but just for the heck of it, here's how I create a
file in ASP:

var fso = new ActiveXObject("Scripting.FileSystemObject");
var a = fso.CreateTextFile("c:\\testfile.txt", true); // true indicates
whether to rewrite
a.WriteLine("This is a test.");
a.Close();