From the keyboard of ········@fmrco.COM:
: A Comparison of Scripting Languages (and C)
Perl supporter though I am, I would realy add Icon, TCL, scheme, REXX, and
Python to this list -- at the least. Comparing Perl to shells is a sure
guarantee that it will come out ahead. Comparing it to more sophisticated
interpreters would be a more useful thing, I think. Shells never tried
to be general purpose languages, nor really did awk, although C did.
The others named try harder at being such.
:Functionality: Perl: Csh: Sh: Elisp: AWK/NAWK: C:
:-------------------------------------------------------------------------------
:Associative array/list Yes No No Yes Yes No
:Compilable 1/2 (4) No No 1/2 No Yes
:(4) - Perl compiles code, internally, into an optimized syntax-tree.
: this allows Perl to work much faster than other scripting languages.
: Perl also has an optional feature that allows dumping that syntax
: tree and the interpreter, and creating a standalone
: executable from the dumped image. Thus, Perl can "compile"
: in the sense that it can generate an executable that does
: not need an installed version of Perl to work.
No, perl is *not* (currently) compilable. It builds the same kind of parse
tree building as awk does. Note that the AT&T awk-to-cc xlator (or
whatever's it's called) *will* compile awk.
:DBM database support Yes No No No No Yes
:Debugger Yes No No Yes No Yes
:Emacs debugger support Yes No No Yes No Yes
and more importantly :-), vi debugger support. [i have a perldb that
does what emacs debugger mode does vis-a-vis jumping to the right
file and line at each step.)
:Emacs mode support Yes No No Yes No Yes
someone out there has a vi hotkey setup for perl, although i don't bother
to use it.
:Errors w/ line #s Yes No No No 1/2 Yes
:Full V8 patterns Yes No No Yes Yes No
:Functions Yes 1/2 Yes Yes Yes Yes
you might consider also whether the functions can have local auto variables,
local static variables, whether they can be called recursively or
indirectly, whether all types can be passed to them.
:Handles binary data Yes No No Yes No Yes
:IPC Yes No No Yes No Yes
:List handling Yes Yes No Yes Yes No
:Math library Yes No No Yes Yes Yes
:Networking Yes No No 1/2 No Yes
:Optimization Yes No No Future No Yes
unclear on this
:Pattern optimization Yes No No No No No
:Shared memory Yes No No No No Yes
perl does shared memory? really? are you thinking of sysV shm stuff
and larry's funky p format for pack/unpack to get at real pointers?
:Shipped with SunOS No Yes Yes No Yes Yes (1)
:(1) - The C compiler will NOT be shipped with Solaris2.0 (Sun's SVR4 OS).
unsubstantiable rumour indicates that this may soon occur.
:Source available Yes 1/2 1/2 Yes 1/2 1/2
i believe that both bash and tcsh give you full sh and csh functionality
respectively in complete source.
:Support available (2) Future Yes Yes Yes Yes Yes
:(2) - Support for GNU products is available from Cygnus Support. Perl will
: be supported by Cygnus, when/if there is enough interest.
:Support for Sybase Yes (3) No No No No Yes
:(3) - There is a package available that compiles into Perl, called sybperl,
: that allows access to a sybase database.
:Unix system calls Yes No No 1/2 1/2 Yes
:
:
:Key:
: Yes - Implemented.
: No - Not implemented.
: 1/2 - Partial implementation, or only some versions.
: Future - Planned implementation for the future.
:
I believe it would be only fair to include the following features in
your table. Note that perl doesn't (yet :-) have a fair number of these,
and I've probably forgotten some things where the other semigeneralpurpose
interpreters do well.
I've only listed the yes/no for perl, others will have to fill in the rest.
'E' means emulated only, as in awk and perl's multidim arrays, or provided
by a library.
* GUI library (like tk)
? speed (hard to measure)
E automatic datatype conversion for binary data written by C programs
E infinite precision arithmetic
E multidim arrays
E recursive datatypes
E set types, with operators (not just assoc arrays)
E structured datatypes
N easy parsing (like yacc)
N embeddable in C code
N object oriented features (classes, methods, ...)
N run-time binding to specialized C code
N strict typing
N threads
Y access to arch-specific syscalls
Y anon functions/code frags
Y both static and dynamic scope
Y cobol/fortran/basic-plus style pictures for report generation
Y convenient for command line one-liners
Y documentation: man page, book, refcards, interactive tutorial, classes
Y dump parse tree (btw: i don't care for perl implementation)
Y easy scanning (like lex)
Y eval
Y exception handling
Y files as data types
Y good unix interface for pipes/filters
Y it's own newsgroup :-)
Y no limits on sizes of data types (string length, array elts, ...)
Y packages with protected namespace and module-init code;
Y private functions
Y require/provide
Y rich list handling primitives
Y rich string handling primitives
Y rich table handling primitives
Y runs on UNIX, VMS, DOS, MacOS, OS/2
Y static binding to specialized C code
Y sw dev support tools: equivs of lint, profiling, xref, tags,
Y test suite
* I don't really count curseperl for the GUI library. I think
there are some libs out there for dealing with X, so maybe this
should be an E.
--tom
--
There are probably better ways to do that, but it would make the parser
more complex. I do, occasionally, struggle feebly against complexity... :-)
--Larry Wall in ····@jpl-devvax.JPL.NASA.GOV
Tom Christiansen ·······@convex.com convex!tchrist
In article <······················@news.eng.convex.com> ·······@convex.COM (Tom Christiansen) writes:
: I've only listed the yes/no for perl, others will have to fill in the rest.
: 'E' means emulated only, as in awk and perl's multidim arrays, or provided
: by a library.
:
: * GUI library (like tk)
I do have a rudimentary version of Motif bindings running on my screen
currently. I've got various buttons there that are connected to Perl
scripts. And there's nothing much that prevents you from driving tk
from Perl... :-)
: ? speed (hard to measure)
: E automatic datatype conversion for binary data written by C programs
: E infinite precision arithmetic
: E multidim arrays
: E recursive datatypes
: E set types, with operators (not just assoc arrays)
: E structured datatypes
: N easy parsing (like yacc)
: N embeddable in C code
: N object oriented features (classes, methods, ...)
: N run-time binding to specialized C code
: N strict typing
: N threads
Note that much of the above will be supported in Perl 5. I already have
an embeddable version running on my machine, and I'm currently flattening
out the interpreter so I can thread it more easily. Should run faster
too. Data structures and objects are high on the priority list. Dynamic
binding should be pretty easy to add in (where supported by the OS).
The trick, of course, is to make the above available without compromising
Perl's current usability. There are already way too many languages
out there where you have to learn the whole language before you can use
any of it.
(There's already a Perl yaccpar out there, by the way, so an N on that
is a bit pessimistic.)
Larry
In article <······················@news.eng.convex.com> ·······@convex.COM (Tom Christiansen) writes:
> :Associative array/list Yes No No Yes Yes No
I have a nice associative array/symbol table library for C that allows any
structure you care for to be associated with the array, and whatever initial
value you want (or null). It's fairly small and quite convenient.
--
Peter da Silva `-_-'
$ EDIT/TECO LOVE 'U`
%TECO-W-OLDJOKE Not war? Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp. Sugar Land, TX 77487-5012 +1 713 274 5180
In article <···········@ferranti.com> ·····@ferranti.com (Peter da Silva) writes:
>In article <······················@news.eng.convex.com> ·······@convex.COM (Tom Christiansen) writes:
>> :Associative array/list Yes No No Yes Yes No
>
>I have a nice associative array/symbol table library for C that allows any
>structure you care for to be associated with the array, and whatever initial
>value you want (or null). It's fairly small and quite convenient.
>--
>Peter da Silva `-_-'
>$ EDIT/TECO LOVE 'U`
>%TECO-W-OLDJOKE Not war? Have you hugged your wolf today?
>Ferranti Intl. Ctls. Corp. Sugar Land, TX 77487-5012 +1 713 274 5180
Is it available to "... the rest of us??"
Care to post it? (pretty please??)
--
Bill Meahan (WA8TZG) | I taught my daughter's cat a trick!!
···@wa8tzg.mi.org OR | I say to her, "Velcro! Ignore me."
uunet!mailrus!sharkey!wa8tzg!wwm | And she DOES!! For hours at a time!!
"Home for Cybernetic Orphans" | What a smart cat.
I would also add "abc" to the list... It's free, it's supported and
well documented, and it is fairly powerful (supports recursions,
infinite precision math, rationals, sorted datatypes...)
Instead of listing "sh" I would list "ksh" as the shell of choice.
--
Gene Spafford
Software Engineering Research Center & Dept. of Computer Sciences
Purdue University, W. Lafayette IN 47907-1398
Internet: ····@cs.purdue.edu phone: (317) 494-7825
From: Wayne Throop
Subject: Re: Perl info for FAQ...
Date:
Message-ID: <5106@sheol.UUCP>
> ·······@convex.COM (Tom Christiansen)
> Message-ID: <······················@news.eng.convex.com>
> Perl supporter though I am, I would realy add Icon, TCL, scheme, REXX, and
> Python to this list -- at the least. [...]
> I believe it would be only fair to include the following features in
> your table.
> [...]
> N object oriented features (classes, methods, ...)
> [...]
I'd say "classes, methods, inheritance" before elipsis-ing the rest.
Also, I'd add the separate lines
N multiple inheritance
N simple support for persistent objects
It was, in fact, these three things that are lacking in scripting
languages that led me down the slippery slope of constructing my own
instead of using an existing one. (I was ignorant of python at the
time.) (In retrospect, I'd probably prefer extending some existing
language, but temptation is ever present in this. Sigh.)
--
Wayne Throop ...!mcnc!dg-rtp!sheol!throopw
From the keyboard of ·······@sheol.UUCP (Wayne Throop):
:> ·······@convex.COM (Tom Christiansen)
:> I believe it would be only fair to include the following features in
:> your table.
:> N object oriented features (classes, methods, ...)
:
:I'd say "classes, methods, inheritance" before elipsis-ing the rest.
:Also, I'd add the separate lines
:
: N multiple inheritance
: N simple support for persistent objects
:
:It was, in fact, these three things that are lacking in scripting
:languages that led me down the slippery slope of constructing my own
:instead of using an existing one. (I was ignorant of python at the
:time.) (In retrospect, I'd probably prefer extending some existing
:language, but temptation is ever present in this. Sigh.)
I've also thought that perl's associative arrays became persistent
objects when bound to DBM files, but this is a special case.
Is MI really all that necessary in a language? I've read the C++ MI vs SI
arguments until blue in the brain. I recall that even Bjarne said not to
use MI until you've been comfortable with SI for a few years, which seems
excessive. If it's that dangerous, why have it, and if it's that useful,
why wait several years?
--tom
--
Tom Christiansen ·······@convex.com convex!tchrist
It's there as a sop to former Ada programmers. :-)
--Larry Wall regarding 10_000_000 in <·····@jpl-devvax.JPL.NASA.GOV>
From: Wayne Throop
Subject: Re: Perl info for FAQ...
Date:
Message-ID: <5121@sheol.UUCP>
> ·······@convex.COM (Tom Christiansen)
>> N object oriented features (classes, methods, inheritance ...)
>> N multiple inheritance
>> N simple support for persistent objects
> I've also thought that perl's associative arrays became persistent
> objects when bound to DBM files, but this is a special case.
But don't associative arrays have limits when bound to DBM files?
I thought there were some limits built in to DBM entries that aren't
inherent in perl associative arrays (though as you can see, I haven't
studied this in detail). Anyway, if perl had classes and inheritance
that applied to entries in associative arrays, I'd probably count the
DBM support as counting as persistent objects. (As it is, they're
"just" persistent arrays.)
> Is MI really all that necessary in a language? I've read the C++ MI vs SI
> arguments until blue in the brain. I recall that even Bjarne said not to
> use MI until you've been comfortable with SI for a few years, which seems
> excessive. If it's that dangerous, why have it, and if it's that useful,
> why wait several years?
Well... I wouldn't want it because it's *safe*, particularly. And, as
the arguments go, you CAN always duplicate anything MI can do with SI
plus "contains" (for anything else that might have been MIed), or by
arranging that the things you'd multiply inherit be in the base class,
or other techniques. And there's not much doubt that MI can be abused.
But from one perspective, MI is basically a shorthand convenience, sort
of like not having to declare variables ahead of time if you don't want,
and having string and numeric types interchangeable a-la awk and perl
and others, and other such features. Such features are appropriate in
scripting languages, even if they might not be in more.... "static" or
"serious" or whatever you want to call "non-scripting" languages. Thus,
even if you follow Bjarne's position and think it's a Bad Idea (or at
least a Dangerous Idea for the Novice) in C++, this doesn't necessarily
imply that it's a Bad Idea in perl, or tcl, or whatever.
But I must admit, I happen to think MI is a Good Thing (or at the very
least a Necessary Evil) even in non-scripting languages where you want
things nailed down a bit more formally. The case that convinced of this
(I'm a convert from the SI-only camp) was objects that had methods that
formed a contract for storage (read, write, copy, clone, etc) another
for version control (put, get, use-version, etc), and another for
constructability (basically, just "build"). There were multiple
implementations of "storageness" (in a file, in a db, in memory, etc,
etc), and multiple implementations of "version-ness" (using full copies,
using sccs, using raw diffs, etc). These various implementations didn't
form a heirarchy, and each implementation often depended on interfaces
implemented by the other implementations chosen. Thus, using
inheritance to mix in several implementations of a partially implemented
type was the simplest and least confusing way to model the situation.
Of course, some people just see this as a reason to have "implementation
inherits" and an "interface inherits" relationships as separate things,
instead of MI. Or at any rate, SOME other mechanism than MI. But
simply using MI to assemble a class from a library of classes was by far
the least mind-bending way to deal with a set of independent contracts,
and multiple, orthogonal implementation sets of each contract. It most
accurately modeled the intuitive view of things, such that the resulting
objects really were "is-a" file, and "is-a" versioned object, both at
the same time.
Your mileage may vary. The above seems a pretty rambling discussion of
"Why-MI" in scripting languages, but I can't see any obvious way to
improve it and still explain my MI jones just now. I'll post it and see
if y'all can't shoot holes in it for me to think about.
( If one wants to further discuss MI per se, as opposed to further
discussion of comparative features of scripting languages,
it might be polite of one to change the Subject: and Followup-To:
lines to reflect this intent. )
--
Wayne Throop ...!mcnc!dg-rtp!sheol!throopw
From the keyboard of ·······@sheol.UUCP (Wayne Throop):
:Such features are appropriate in scripting languages, even if they might
:not be in more.... "static" or "serious" or whatever you want to call
:"non-scripting" languages.
Hmm... perhaps let's call them usually-interpreted versus usually-
compiled-into-machine-language.
Originally, a script was something like a command file as you
might find under JCL. This changed into shell scripts, which
started adding more sophisticated flow control and other features.
In today's parlance, it often means anything that doesn't go to
all the way to native machine language, meaning we have BASIC
scripts, Pascal scripts, LISP scripts, Perl scripts, etc.
Still seems funny to me. They're just interpreted *programs*, and no
less "serious" than ones that we grind into machine language.
--tom
--
Tom Christiansen ·······@convex.com convex!tchrist
/* This bit of chicanery makes a unary function followed by
a parenthesis into a function with one argument, highest precedence. */
--Larry Wall in toke.c from the perl source code
·······@sheol.UUCP (Wayne Throop) wrote:
> But don't associative arrays have limits when bound to DBM files?
> I thought there were some limits built in to DBM entries that aren't
> inherent in perl associative arrays
Most dbm implementations can `fail to insert' when you have too many
key/data pairs that hash together. Rumour has it that the new
berkeley db package doesn't suffer from this, but when I once to tried
to compile perl with its ndbm access method, i couldn't get it to
work -- the perl regression test failed big time. (Has anybody
ever got this to work ? I sure would like to know!)
The usual way to get around the limits of dbm is not to store the key/data
pairs themselves, but to store the data in a separate file, and to
just store a pointer to that file in the dbm. This kludge completely
destroys any useful notion of perl dbm assoc arrays as persistent
objects :-)
--
Ronald Khoo <······@demon.co.uk> <······@ibmpcug.co.uk> <······@robobar.co.uk>
BTNet: +44 71 229 7741 | Brambles are the order of the day.
From: Bjarne Stroustrup
Subject: Re: Perl info for FAQ...
Date:
Message-ID: <23102@alice.att.com>
·······@convex.COM (Tom Christiansen) says
> I recall that even Bjarne said not to
> use MI until you've been comfortable with SI for a few years, which seems
> excessive. If it's that dangerous, why have it, and if it's that useful,
> why wait several years?
I think I'm being misquoted. What I usually recommend is to avoid language
features until you see the point of them and feel comfortable with them.
Too many people feel that if a feature is in the language then their
current program will somehow be better if they use it. That is wrong:
Most small to medium size programs have no use for ALL of the major
components of a language.
I also say that it may take years before a programmer meets a problem
for which a given feature support the most appropriate solution.
I don't consider MI as presented in C++ dangerous.
In article <······················@news.eng.convex.com> Tom Christiansen <·······@convex.COM> writes:
Is MI really all that necessary in a language? I've read the C++ MI vs SI
arguments until blue in the brain. I recall that even Bjarne said not to
use MI until you've been comfortable with SI for a few years, which seems
excessive. If it's that dangerous, why have it, and if it's that useful,
why wait several years?
The greatest use I've made of MI is to support mixins. And as the
Annotated C++ Reference Manual says on page 202: "In particular, it
was not obvious how to combine the C++ strong static type checking
with a scheme flexible enough to support directly the 'mix-in' style
of programming used in some Lisp dialects." (Draft ANSI Common Lisp
is apparently a Lisp "dialect" in this context.) Thus, some of the
difficulty programmers have with MI is actually attributable to the
limitations of the substrate language.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.