Title:	Interpreted Languages
Date:	October 24th, 2000
Self Righteous:	2
Opinionated:	3
Simply true:	9

From: David Madison
Subject: Perl is Satan!  was: Re: Netwinder/ARM performance
To: [email protected]
Date: Tue Oct 24 15:10:28 2000
X-Mailer: DaveMail [version 6.0]

Aaron Lehmann said:
> I strongly believe that any interpreted program will not be a good
> test for general hardware performance.

Let me start off with agreeing fully with Aaron on this point.

Now to the disagreement!   ;)

> So, with the execption of ease of testing[1], what advantages do
> interpreted languages have?

Ease of development is pretty important.  I use to be a speed junky,
writing all my code in the tightest C I could.  Then I realized I
wasn't getting much done, and I started to do some development in Perl.

The difference in output was staggering - I've been able to develop
some tools in hours that would have taken days in C.  And maybe they
run a bit slower.  Maybe I could detect that if I used 'time' on
the commands and I could see that the CPU used a few more microseconds.

But the fact is that if the perl code is written well, it *can* be
scaled, and it *can* run "fast enough".

Fast enough is the important part here.  Does it accomplish my job
quickly enough for me?  If it bogged down my system, that would be
something to complain about, but I haven't seen that yet.

You can look at it as a simple equation.

Time to develop + ( Time to run * Number of times run )

Perl can, in many cases, cut development time by more than half, while
only increasing run time by a few percent.  And you can often erase
the right side of the equation if this code is being run in the background.

Basically it comes down to this.  I bought a computer so it could do some
work for me.  If it gives me a tool (perl) that allows it to take away
some of my workload, then so be it.

> A lot of web sites use perl code and many of them interpret this
> code every time they recieve a hit. Yuck.

Perl code can be 'compiled' (though this is really just preinterpreted).

> I will be able to run it without the extra dependencies and overhead
> of some silly, redudnant interpreter program.

Most C programs are dynamically linked to at least the standard library,
so they have the same kind of dependency.  Think of Perl as a library.

Sure, you can statically link, but I can do that with Perl and produce
for you an x86 program from my perl script.  But I don't need to do
that, because perl is part of just about every standard distribution.

-- 
Dave Madison        http://GetDave.com

In an separate discussion about perl I heard the common perl complaint that perl has too many ways to do something (as if this is bad?).

My response (to Rob Landley, tromello.org):

> ...I wouldn't be too fond of a command line that encouraged you to have
> eight different spellings of "cat", either...  :)

You better stop using your shell.  Here are some examples, using bourne shell:

% cat somefile
% lynx -dump somefile
% more -`wc -l somefile | sed -e 's/ *//'` somefile
% head -n `wc -l somefile | sed -e 's/[^0-9]//g'` somefile
% i=1 ; while [ $i -le `wc -l somefile | sed -e 's/[^0-9]//g'` ]; do head -n $i somefile | tail -n 1; let i=i+1;done
% perl -pe 1 somefile
% sox -bsr 100 -t raw somefile -t raw -
% convert -size 1x1 gray:k gray:- | head -n 370
% i=1 ; while [ $i -le `wc -l somefile | sed -e 's/[^0-9]//g'` ]; do read l; echo $l; let i=i+1;done < somefile
% echo "f=open('somefile','r'); a=f.readline();\nwhile (a != ''): print a,; a=f.readline();" | python

I'm rather proud of the sox and more commands.  :)

Just because there are 8 different ways to do something doesn't mean there are
8 *good* ways to do something.