Hello:
I understand what you're saying but the fact remains: STRICTLY speaking,
Perl is NOT an interpreted language (such as the BASIC language I learned in
high school, many, many years ago). Sure, there is an interpreter, but
there is also a compile phase (which is the point you sorta made in your 2nd
paragraph). Now, I make no claims at being an expert on this, but if your
argument is that the authors of Perl in a Nutshell are wrong, then say so.
And if that's the case, then I will research it some more.
On a different subject: as to what a script is, and to stir the pot a bit,
let me quote Tim Hill, the author of Windows NT Shell Scripting (published
by MTP) and a professional software developer (among other things):
"This is a book about Windows NT scripting. In Windows NT, a SCRIPT is a
record, in a text file, of a sequence of shell commands. (A SHELL COMMAND is
approximately the same as a command typed into a command prompt window.)
Once created, a script can be executed as if it were an executable
program...thus a script, in its simplest form, is just a way of saving
typing...[scripting] has evolved into a full programming language" (pp.
7-8) (Emphases, in caps, are the author's and not mine.)
Conclusion: Perl is a high-level language; and it is both a scripting
language as well as a programming language (since it has the characteristics
of both). In other words, you can have your cake and eat it too. :)
Dean Theophilou
P.S. I've always considered Assembly to be a low-level language, C to be a
mid-level language, and Pascal and Perl to be high-level, but that's simply
my own personal way of categorizing.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 17, 2001 3:11 PM
To: Dean Theophilou
Cc: Jon Acierto; [EMAIL PROTECTED]
Subject: Re: PERL IS NOT A HIGH LEVEL LANGUAGE
> "Dean Theophilou" <[EMAIL PROTECTED]> said:
> Technically, Perl is NOT an interpreted language. The Perl interpreter
> converts the program into byte code before executing, just like C. This
is
> a paraphrase of p. 31 of Perl in a Nutshell, by O'Reilly. I suggest you
get
> the book, since it was written by real-world (as opposed to "teachers")
> professional programmers.
A C compiler generates machine specific assembly code which is loaded to
create an executable program which can run independent of the compiler. e.g.
the language parsing, code generation step is performed once. Perl parses
and
generates code each time the program is run. So parsing and code generation
overhead is part of normal perl execution. That is why a perl "executable"
is
just the script itself.
There are ways to generate perl "object" code, but for most application
the reduction in overhead is hardly worthwhile. Also having the perl
parser and code generator around at runtime is useful for executing
dynamically generated code e.g. eval() and do(). It also allows very
late symbol table binding, since the symbol table is carried with the
execution environment in perl. This is generally not true with C,
where variables are bound at compile/load time.
Please remember the compile->load->execute paradigm was developed at a
time when memory and cpu cycles were a scarce resource. It works well
when you have to run a program many times (e.g. a heavily used utility
like the Unix shell) with little runtime overhead.
--
Smoot Carl-Mitchell
Consultant
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
