>I haven't had a chance to teach our intro class with it yet, but I
>think a language like "abc" is closer to what I want there than C++
>(or Perl).
I agree; I can't imagine teaching a class with either of those
languages. I can't see how anyone but an expert can guess how his C++
program is going to behave, and Perl is only clear and easy to
understand for those with prior experience with sed, awk, shell, etc.
> Significant features include:
> * It's interpreted
> * It uses a syntax-directed editor -- the student cannot enter a
> syntactically-incorrect program
He cannot enter one at all? Or does it just become very obvious by
bizarre indentation? I can't live without my Emacs modes for any of
the languages I use. Syntax-directed editors are a must.
> * No type declarations are needed -- context determines type
As in Perl? I like the Lisp/Scheme/Dylan/Python approach; variables
aren't typed, but objects are. A context-determines-type situation,
while often useful for semantic density, can confuse someone reading
someone else's code.
> * It uses unlimited precision, so there is no need to discuss the
> problems of word size or machine representation (what other
> language will give the correct answer to "write 2**10001" in
> about 1 second?)
Off the top of my head, Python (one implementation freely available),
Lisp (CLISP, GCL, FEEL, XLISP freely available), and Scheme (scm,
vscm, elk, STk and more freely available). It also takes much less
than one second real time for most of those to give the answer on my
486dx33:
winners:
STk: 0.23 sec
clisp: 0.35 sec
scm: 0.47 sec
elk: 0.57 sec
vscm: 0.65 sec
losers:
python: 2.28 sec (only .24s to calculate; like GCL, bad printer)
GCL: 12.00 sec (it only takes .10s to calculate; GCL's
bignum printer is a big loser)
Please don't think I'm trying to make any claims about this
benchmark; I'm just showing the friendly readers that good bignum
performance is a fairly common thing.
> * Sets are a native data type (there are only five: numbers,
> strings, compounds (records without field names), lists, and
> tables (sort of associative arrays).
All the languages I mentioned have all those, although with all the
schemes except STk you need to use Aubrey Jaffer's excellent SLIB
add-on library to get hash tables. Er, actually, I'm not sure why
you'd want "compounds", but you could definitely simulate them easily
enough if you had to have them.
What's equally important is that, with the possible exception of
Common Lisp, all the languages I mention have an equally restrained
set of types. Just enough to get the job done, but not enough to
confuse.
>Best of all, it's free and available for Unix, Macs, MS-DOS and Atari
>STs. (Look on ftp.uu.net in languages/abc, or on ftp.cwi.nl in
Well, with all the quality freely available products out now, "free"
isn't as exciting as it should be. In addition to being free, each of
the products I mentioned has other attractive features.
Python has a rapidly expanding user base and a fairly high
signal-to-noise newsgroup. It's also a newer (sort of OO) language by
one of the creators of ABC (Guido Van Rossum). I find Python much
more readable than ABC. It also provides many of the facilities that
Perl users have come to love, like fairly low-level interfaces to the
native OS, regular expressions, "persistant" associative arrays in the
form of NDBM files, a socket interface, Tk interface, etc. Lately
I've written some projects in Python that I might previously have
coded in Perl; Python has a "cleaner" and more modular feel that lends
itself to programming larger projects. Of course, I'm still a Perl
zealot and use it almost every day.
Back to our main topic, Common Lisp is very well documented and widely
used. I don't need to list its features (and I don't have room). It
may be too much for a teaching language, but it's definitely easy to
learn and use.
Scheme is also well documented and widely used, with the added
advantage of having several modestly sized implementations available.
Both Lisp and Scheme have their own helpful newsgroups, and both are
standardized (Scheme by IEEE, and the ANSI Common Lisp standard is
close to passing). Also, STk has a very nice Tk interface; it has
two, in fact, one modelled after the standard TCL/Tk model and (a much
nicer) one that uses a CLOS/Dylan-like object oriented model.
Dr. Ousterhout must scream every time he sees Tk ported to a new
language; his goal of a single extension language (TCL) simply won't
work because of language religion. On the other hand, Tk is so
successful because everyone hates programming in X.
MIT, among others, considers Scheme to be a suitable language for
beginners, and I agree. Unfortunately, I don't get to use Scheme as
much as I would like to because the bare-bones language spec. doesn't
cover many facilities that I need in my everyday programming, like
regexs, hash tables (alists just aren't fast enough sometimes),
sockets, etc. That's both a strength and a weakness. Many
implementations supply their own versions of these facilities, so as
long as you find one that you like and stick with it, you can get by.
I thought this particularly relevant in the face of the "Tower of
Babel" thread; languages like Perl and Python are very useful
languages for Unix scripting, text manipulation, and non speed
critical programs , while a language like Scheme fits neatly into the
"learning language" pedagogical realm. Perl is the sysadmin's Common
Lisp: intricate, enjoyable, occasionally inscrutable, and full of
tricks.
-- Robert
In article <······················@hrothgar.mindspring.com> ········@mindspring.com (Robert Sanders) writes:
: > * No type declarations are needed -- context determines type
:
: As in Perl? I like the Lisp/Scheme/Dylan/Python approach; variables
: aren't typed, but objects are.
You can put Perl 5 in that list too.
Larry
On Mon, 25 Jul 1994 16:09:26 GMT, ·····@netlabs.com (Larry Wall) said:
>> I like the Lisp/Scheme/Dylan/Python approach; variables aren't
>> typed, but objects are.
> You can put Perl 5 in that list too.
Although it's a sin to disagree with Larry in comp.lang.perl, I just
don't think I get this one. Perl5 variables are typed exactly as
Perl4 variables are; the only difference is that scalars may also hold
a special kind of scalar called a "reference." That isn't quite the
same. Sure, you can do some of the same things with it, but in Perl5
the machinery is just a little too public.
$$sref to use a reference to a scalar, @$ref to use a reference to an
array, and %{$ref} to use a reference to an assoc. array just aren't
pretty to my delicate eyes. Of course, those are only for builtin
types, but even the use of refs to class instances isn't pretty.
Let's say I implement an arbitrary precision class in CLOS or STk,
Dylan, and Perl5. Here's how addition will look in each of these
languages (a and b are both instances of MP):
CLOS: (+ a b) or, assuming I leave the standard + function alone,
(add a b)
Dylan: a + b
Perl5: $a->add(b) or MP::add($a, $b) # unless the overload patches
# make it in one day
Since we're talking about teaching languages, clarity is an important
point. I don't think it will come as a surprise to anyone that Perl
isn't the clearest language in this example.
What I like most about CLOS, Dylan, and some Schemes with object
systems (i.e. STk, scheme+tiny-clos, etc.) is that objects take care
of themselves. I find that the generic function approach to OOP is
more in line with my view of it than the methods-belong-to-classes
path that C++ and Perl5 have taken.
-- Robert
P.S. NO MORE ROT13 JOKES! It's not Larry's fault if his home keys
are all punctuation. :-)
-=> Regarding: Re: PERL as a first programming language?:
-=> ··@nexus.yorku.ca (ozan s. yigit) sez:
> lwall:
>> I think people will latch rather quickly onto the Perl5ism ...
> what choice do they have?
Perl4? Worked pretty well heretofore... Shell? BASIC? Python? one of 10 other
languages?
--
< ···@cis.ufl.edu >| Please feel free to respond to anything I
< (904)373-0906 >| say: I have strong opinions, but a wide-open
< 1936 N.W. 2nd Avenue >| mind.
< Gainesville, FL 32603 >| BUT KEEP THE FLAMES TO E-MAIL! (geez!)
-"My marriage is on the rocks, but only because we can't find a blanket."
<a href=http://www.cis.ufl.edu/~asr/asr.html>My Home Page</a>
Well, all this discussion is well and good, but has anyone used Perl
as a first natural language? As in, teaching a child to speak it natively,
before, say, English? Unfortunately, I don't have kids, so I haven't
been able to pursue this myself, but I'm sure someone has. But the advantages
are obvious...
--
Steven
"I'm afraid I'm not personally qualified to confuse cats."
From: Logan Shaw
Subject: Re: PERL as a first programming language?
Date:
Message-ID: <Cto00n.IzI@taligent.com>
In article <······················@hrothgar.mindspring.com>, ········@mindspring.com (Robert Sanders) writes:
> > * It uses unlimited precision, so there is no need to discuss the
> > problems of word size or machine representation (what other
> > language will give the correct answer to "write 2**10001" in
> > about 1 second?)
>
> Off the top of my head, Python (one implementation freely available),
> Lisp (CLISP, GCL, FEEL, XLISP freely available), and Scheme (scm,
> vscm, elk, STk and more freely available). It also takes much less
> than one second real time for most of those to give the answer on my
> 486dx33:
>
> winners:
> STk: 0.23 sec
> clisp: 0.35 sec
> scm: 0.47 sec
> elk: 0.57 sec
> vscm: 0.65 sec
> losers:
> python: 2.28 sec (only .24s to calculate; like GCL, bad printer)
> GCL: 12.00 sec (it only takes .10s to calculate; GCL's
> bignum printer is a big loser)
Just to be fair, I should mention that I tried *really* calculating
2 * 10001 in Perl. I used the "bigint.pl" library that comes with the
distribution, but it doesn't have a power function, so I quickly
hacked one in terms of the functions in bigint.pl.
This is the code:
#! /usr/local/bin/perl
require "bigint.pl";
sub bpow
{
local ($num, $exponent) = @_;
local ($answer) = '1';
while ($exponent)
{
if ($exponent & 0x01)
{
# this exponent of the number is a factor
# in the answer, so multiply it in.
$answer = &bmul ($answer, $num);
}
# go up to the next factor which is a power of two
$num = &bmul ($num, $num);
$exponent >>= 1;
}
$answer;
}
($base, $power) = @ARGV;
print "$base ** $power ==\n";
print &bpow ($base, $power), "\n";
And, on an RS/6000 250 (which is a PowerPC 601):
$ time ./power 2 10001
2 ** 10001 ==
[...] 5193418752
real 0m40.01s
user 0m39.73s
sys 0m0.13s
Not bad, considering it's using floating point to do the integer
stuff, which it's using (in arrays) to do the functions in bigint.pl,
which I'm calling over and over again to do my bpow() function.
If I'd written bpow from scratch, I'm sure it could have been much
faster.
Adios,
Logan
--
The genius of France can be seen at a glance
And it's not in their fabled fashion scene
It's not that they're mean, or their wine, or cuisine
I refer of course to the guillotine
(the French knew how to lynch)
T-Bone Burnett, "I Can Explain Everything"
From: Jack Campin
Subject: Re: PERL as a first programming language?
Date:
Message-ID: <CtrIz5.GqD@cee.hw.ac.uk>
········@mindspring.com (Robert Sanders) wrote:
>> I haven't had a chance to teach our intro class with it yet, but I think
>> a language like "abc" is closer to what I want there than C++ (or Perl).
>> Significant features include:
>> * It's interpreted
>> * It uses a syntax-directed editor -- the student cannot enter a
>> syntactically-incorrect program
> He cannot enter one at all? Or does it just become very obvious by
> bizarre indentation? I can't live without my Emacs modes for any of
> the languages I use. Syntax-directed editors are a must.
The structure editor is why I gave up on ABC. I was trying to use it on
the Mac, where the editor is tightly coupled to the interpreter (you can't
use an editor of your own choice). It's essentially write-only;
reorganizing existing code is so painful you'd better get it right first
time, and nothing works anything like the usual Mac user interface. This
approach was presumably dictated by the pedagogical aims of ABC (teaching
programming by refinement) - those aims are even less compatible with the
language being useful as a practical tool than the aims of Pascal were. I
can't see anybody using Mac ABC for any program longer than a page or that
they were going to keep for more than a week.
Pity, because the Mac needs a simple, readable, interpreted language for
writing small file-processing programs. ABC could easily have been it if
it hadn't been for this appalling user interface.
--
-- Jack Campin -- Room 1.36, Dept. of Computing & EE, Heriot-Watt University,
Riccarton, Edinburgh EH14 4AS Home: 031 556 5272 Fax: 031 451 3431
Work: 031 449 5111 ext 4195 WWW: http://www.cee.hw.ac.uk/~jack/jack.html
Internet: ····@cee.hw.ac.uk Bitnet: via UKACRL BANG!net: via mcsun & uknet
In article <··········@cee.hw.ac.uk> ····@cee.hw.ac.uk (Jack Campin) writes:
>········@mindspring.com (Robert Sanders) wrote:
>>> I haven't had a chance to teach our intro class with it yet, but I think
>>> a language like "abc" is closer to what I want there than C++ (or Perl).
>>> Significant features include:
>>> * It's interpreted
>>> * It uses a syntax-directed editor -- the student cannot enter a
>>> syntactically-incorrect program
>> He cannot enter one at all? Or does it just become very obvious by
>> bizarre indentation? I can't live without my Emacs modes for any of
>> the languages I use. Syntax-directed editors are a must.
>
>The structure editor is why I gave up on ABC. I was trying to use it on
>the Mac, where the editor is tightly coupled to the interpreter (you can't
>use an editor of your own choice). It's essentially write-only;
>reorganizing existing code is so painful you'd better get it right first
>time, and nothing works anything like the usual Mac user interface.
There are syntax-directed editors, and then there are *syntax-directed*-editors.
I've had occasion to use two real, you-can't-enter-an-invalid-program editors
recently.
G2, Gensym's expert-system shell, has a syntax-directed editor for its
Algol-like language. This editor is obnoxious, primarily because it doesn't
auto-indent or give you any way to match opening and closing keywords, so it's
very easy to put in syntactically-correct but wrong code.
Medley, Venue's Interlisp-D derived environment, wants you to do your code
editing with a Lisp structure editor named SEdit. SEdit is really cool: you
can close your eyes and type, ignoring the return key, and the right thing
happens, including pretty-printing.
You can't enter an unbalanced S-expression, or an unterminated string:
typing '(' causes '()' to appear with the insert point between the parens,
typing ')' just moves the insert point past the displayed ')'.
Cut and pasting is per-character within symbols, per-S-expression for larger
constructs. The only thing you can't do directly is grab one parenthesis
and move it; you have to select the whole structure, do Remove Paren,
multiple-select the new group, and do Add Paren.
Syntax-directed editors seem to work best for languages that have little or no
syntax to enforce, like Lisp.
--
Internet: ····@tove.cs.umd.edu
UUCP:...uunet!mimsy!bane
Voice: 301-552-4860
····@cs.umd.edu (John R. Bane) wrote:
> Medley, Venue's Interlisp-D derived environment, wants you to do your code
> editing with a Lisp structure editor named SEdit. SEdit is really cool:
> Cut and pasting is per-character within symbols, per-S-expression for larger
> constructs. The only thing you can't do directly is grab one parenthesis
> and move it; you have to select the whole structure, do Remove Paren,
> multiple-select the new group, and do Add Paren.
Having done a lot of InterLisp-D programming using an earlier version of SEdit
called DEdit, I have several observations. It was so easy to cut and
paste forms that a lot of code ended up being duplicated in functions rather
than the common code being genralizedinto seperate functions. Also, the
InterLisp-D functions easily grew into much larger pieces of code than was
appropriate, e.g., a lot of functions grow in excess of 100 lines of code.
Again, I attribute this large function size to the ease of manipulating a
large function with a syntax directed editor. It was also probably a symptom
of the fact that the editing was on a function-by-function basis, so it was
easier to extend an existing function than create a new set of functions,
especially since new functions had to be "registered" in the file COMS
database.
It could be argued that all of the above observations only require more
discipline by programmers to avoid the pitfalls. This is probably true,
but I observed the same tendancies in code produced by 10 very skilled
and disciplined industrial programmers that used the InterLisp-D
syntax directed editor.I am led to conclude that the metaphors in
a sytax directed editor such as DEdit promote the tendencies. It would
be interesting to hear if similar observations have been seen by other
users of syntax directed editors.
--- AlanG
From: John R. Bane
Subject: Re: Syntax-directed editors and Lisp
Date:
Message-ID: <31n0cp$sb@tove.cs.umd.edu>
In article <··········@iris.mbvlab.wpafb.af.mil> ········@edfuc4.ctis.af.mil (Alan Gunderson) writes:
>
>Having done a lot of InterLisp-D programming using an earlier version of SEdit
>called DEdit, I have several observations. It was so easy to cut and
>paste forms that a lot of code ended up being duplicated in functions rather
>than the common code being generalized into seperate functions. Also, the
>InterLisp-D functions easily grew into much larger pieces of code than was
>appropriate, e.g., a lot of functions grow in excess of 100 lines of code.
>
That's interesting; I used DEdit for about a year before SEdit came out
(and dropped DEdit like a hot rock). DEdit had a big window for your code
and a smaller attached window showing the contents of the cut buffer, whereas
SEdit doesn't display the cut buffer - actually it doesn't even really *have*
a cut buffer: you move text around using the normal Interlisp convention
of shift-selecting (put insert point at destination, hold down shift key and
select source, release shift to copy).
Also, DEdit was occasionally flaky when used to edit more than one function
simultaneously, as I recall. SEdit is a *much* better citizen in that respect.
Most of the big functions I ran into in Interlisp were unspeakably low-level
system code that were written as big PROGs for speed reasons; I don't recall
a lot of bigness for the sake of bigness.
--
Internet: ····@tove.cs.umd.edu
UUCP:...uunet!mimsy!bane
Voice: 301-552-4860