PERL as a first programming language?
Dragomir R. Radev
programming and therefore be used as a first programming language
in school or college?
Drago
--
Dragomir R. Radev Graduate Research Assistant
Natural Language Processing Group Columbia University CS Department
Office: (212) 939-7121 Lab: (212) 939-7108 Home: (212) 866-8548
http://www.cs.columbia.edu/~radev/home.html
--
Dragomir R. Radev Graduate Research Assistant
Natural Language Processing Group Columbia University CS Department
Office: (212) 939-7121 Lab: (212) 939-7108 Home: (212) 866-8548
http://www.cs.columbia.edu/~radev/home.html
Jeffrey Friedl
|> programming and therefore be used as a first programming language
|> in school or college?
Perl would be excellent, mostly because virtually any random combination of
characters would not only compile, but probably do something useful. Maybe
not what the student intended, but it would build confidence (-:
Jeffrey
-------------------------------------------------------------------------
Jeffrey E.F. Friedl Omron Corporation, Nagaokakyo (Kyoto), Japan
jfr...@nff.ncl.omron.co.jp [ DoD##4 N8XBK 92 CB-1 400 ]
Mike Stok
Dragomir R. Radev <ra...@cs.columbia.edu> wrote:
>Has anyone thought whether Perl could be a good introduction to
>programming and therefore be used as a first programming language
>in school or college?
It depends what you want to get out of it...
Perl 5 has all sorts of features which can make it look more like a
traditional language e.g. references, my, and it has become less cryptic
if you
use English;
at the top of your code e.g.
#!/usr/bin/perl5
use English;
$file = 'banana';
open INPUT, $file or die "can't open $file ($OS_ERROR)\n";
Perl 5 has the ability to build quite complex data structures and use
object-oriented techniques if you so desire, but you can still choose a
programming style that is comfortable.
I would check out Learning Perl by Randal Schwartz as an example of one
way of structuring a course that quickly gets people proficient enough to
produce code that's useful to them.
As a language for teaching people about the 'right' and 'wrong' ways to do
things then Perl's a disaster. It is too rich and there are usually many
ways to solve a particular problem, and when you post to c.l.p asking "How
can I do this" there's a fair chance you'll get useful and varied answers
and not get told to write it in Prolog ;-)
>Natural Language Processing Group Columbia University CS Department
If that's your group then little things like array vs. scalar context
shouldn't be too big a problem - that's the feature I find most people
get stuck on for a while...
Hope this helps,
Mike
--
The "usual disclaimers" apply. | Meiko
Mike Stok | 130C Baker Ave. Ext
Mike...@meiko.concord.ma.us | Concord, MA 01742
Meiko tel: (508) 371 0088 x124 |
Logan Shaw
> Has anyone thought whether Perl could be a good introduction to
> programming and therefore be used as a first programming language
> in school or college?
Uh... I hope not. It's a really neat language, but not a beginning one.
Of course, there have been people who thought that BASIC would be a good
introductory language. I'm not sure why, but they did.
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"
Randal L. Schwartz
Jeffrey> Perl would be excellent, mostly because virtually any random
Jeffrey> combination of characters would not only compile, but
Jeffrey> probably do something useful. Maybe not what the student
Jeffrey> intended, but it would build confidence (-:
eeeeeeeegad. Shades of TECO! (What does *your* name do in TECO?)
Actually, from personal experience, I can tell you that there are
*far* more sequences of characters that *won't* make it through the
compiler. And my students often find far too many sequences of
characters that *do* make it through the compiler that *don't* do
anything useful. :-)
Chapter 13 is numbered that way in Learning Perl for a reason. It's a
good place to *lose* all of the files in your work directory if you're
not careful, and in nearly every class I've taught, despite stern
warning to "mkdir play; cd play", I still get a shriek from someone
about halfway through the lab because they did unlink(<*>). :-)
print "Just another Perl hacker," # but not what the media calls "hacker!" :-)
# legal fund: $1182.57 collected, $11835 spent; email @FUND in body for details
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@stonehenge.com> Snail: (Call) PGP-Key: (finger mer...@ora.com)
Phrase: "Welcome to Portland, Oregon ... home of the California Raisins!"
Malcolm Beattie
>
>
>I don't think Perl would be a good first language.
>
> * Too many ways of doing anything. A person new to the
>language might get confused with the possibilities.
Then don't tell them all the possibilities. Stick to the essentials.
That's what any course on a first language should do to start with.
That's what the Llama book does.
> * Too much syntax. A new user will have a terrible time
>keeping the $#,$!,& and % notations together
$ scalar, @ list, % hash, & subroutine. Some languages declare what
type a variable is before use; some languages use a "marker" on each
use of the variable. Neither way is necessaril better, just different.
You could argue that a new user prefers knowing what sort of item is
being looked at straight away rather than remembering or searching
upward for a declaration. Things like $! are no longer necessary with
perl5. Put "use English;" at the top and the variable $OS_ERROR is
what you want.
> * It is still like a compiled language (compared to
>interpreted languages like scheme and lisp) which adds another step
>for the new user.
The fact that perl is compiled internally is irrelevant here. You write
a program foo, you run it with "perl foo". There's no compilation step
which really is a noticable "extra step" to learn. I realise that
you're thinking of Lisp here where everything is "interactive". Again,
that's just different, not better.
> * Programs in perl generally use lots of global variables.
>When starting programming it is importantant to use local variables.
Badly written programs in many languages use global variables. Perl
is no exception. Local variables are available in perl with
local($foo);
and, of course, learners should be taught to use them (as should
everyone else). Perl5 has lexically scoped variables too, with
my($foo);
In Perl, you can ensure that global variables aren't used by mistake
by doing "use strict vars;". Then trying to access $foo when $foo
isn't locally in scope gives an error instead of assuming you mean
a global variable. Variables which have to be global can be gathered
together in a separate package and referred to explicitly.
>
> * Parameter passing in perl looks a little shaky to me (maybe
>because I'm new to perl). Passing multiple arrays should be easier.
It is in Perl5---just pass a reference to the array.
> * Perl does not provide access to its internal constructs,
>unlike lisp which is all cons cells. Seeing internal structures makes
>it easier.
Here is where I would explicitly disagree with you. A learner should
not be concerned with internal structure. If you have a rack of
pigeonholes with ages in you just want to know that
$age{"Fred"} = 40;
saves 40 in Fred's age pigeonhole and you can get it back later with
$age{"Fred"}
>Disclaimer: I am new to Perl and come from a lisp background (so I
>like parenthesis)
So I gathered (((:-)))
--Malcolm
--
Malcolm Beattie <mbea...@black.ox.ac.uk>
Oxford University Computing Services
Forthcoming change of address: will be <mbea...@sable.ox.ac.uk> (but not yet).
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee
Matthew J. Davey - Travel2 Systems.
: Has anyone thought whether Perl could be a good introduction to
: programming and therefore be used as a first programming language
: in school or college?
Unless you want to count the BBC BASIC which I learnt at School (and
then promply forgot over the next couple of years due to lack of use) Perl
is my first attempt to learn a language "in anger".
I have found it difficult, but have managed to produce a fiew
pretty good scripts, and I am getting on better than ever.
SO...I think it would be an excelent introduction to programming,
and also a very valuable on.
Happy Tapping.......
--
Matt Davey ->
*I KNOW I CAN'T SPELL* Fighting for Peace
*WHAT CAN'T YOU DO ?* is like Fu**ing for virginity
William M. Eldridge
>then promply forgot over the next couple of years due to lack of use) Perl
>is my first attempt to learn a language "in anger".
I like this - an image makeover for Perl. No longer the
friendly dromedary of yesterday, Perl is now "the angry language."
Don't get mad - get Perl.
--
Bill Eldridge
bi...@lifesci.ucla.edu Feeling much better since I smashed my TV.
310-206-3960
310-206-3987 (fax) I set my car alarm for 6 o'clock.
Philip Hazel
|> Dragomir R. Radev (ra...@news.cs.columbia.edu) wrote:
|> : Has anyone thought whether Perl could be a good introduction to
|> : programming and therefore be used as a first programming language
|> : in school or college?
I know somebody who learned PostScript as their first programming
language. How's that for eccentricity?
--
Philip Hazel University Computing Service,
ph...@cus.cam.ac.uk New Museums Site, Cambridge CB2 3QG,
P.H...@ucs.cam.ac.uk England. Phone: +44 223 334714
Philip Richardson
>
> I know somebody who learned PostScript as their first programming
> language. How's that for eccentricity?
>
Isn't that roughly equivalent to learning calculus before algebra?
--
Philip Richardson | http://www.uml.edu/~prichard
pric...@cs.uml.edu | Phone: 508-934-3636
--
--
Philip Richardson | http://www.uml.edu/~prichard
pric...@cs.uml.edu | Phone: 508-934-3636
Tom Kraljevic
I think a strongly typed language such as Pascal or C++ is best to
learn first. This forces structure and proper type-casting, which is
easy to mess up for rookie programmers -- especially in a language
like Perl where you use scalars in a vector context, vectors in a
scalar context, strings in a numeric context, ...
--tom
Bill Karwin (Contractor-MM)
: programming and therefore be used as a first programming language
: in school or college?
I think Perl assumes a *lot* of prior programming knowledge and UNIX
concepts.
I would suggest a good featureful version of awk (like gawk) as an option
if you want an "eccentric" interpreted language for a programming class.
--
Bill Karwin "I have always wondered why Sun thought 'Sparc' was
bka...@cup.hp.com a good name for a piece of electronic equipment."
The views expressed above (including the .sig) are mine, not my employer's.
Jeffrey Friedl
|> I think Perl assumes a *lot* of prior programming knowledge and UNIX
|> concepts.
The bulk of the language itself doesn't... but the perl *manual* does.
[random musing continues....] Considering that it was at first basically a
UNIX-only program, such assumptions were fine, and allowd both the reader
and writer to concentrate on the meat of Perl. In the era when I first
started using perl, such a detailed and complete manual was virtually
unheard of in the Unix world, and I'm sure the manual (that there *was*
one) paid a large part in perl's success.
|> I would suggest a good featureful version of awk (like gawk) as an option
|> if you want an "eccentric" interpreted language for a programming class.
Awk eccentric? Naaah, try FORTH. Not really eccentric either, but more
so than awk WRT perl. But like perl, is easy to be a write-only language
if you're not careful.
Speaking of eccentric, I've wondered for *years* why there's no
Obfuscated Perl Contest
(ok,ok, no jokes about perl *being* obfuscated :-)
Lordy, with all the subtle tricks one can pull, we'd probably have to set
up the judging stricly by how many people throw themselves off of tall
buildings trying to understand a particular entry.
I even used to keep a log of some of the more interesting bugs I'd run
into, with the intention of using them for the OPC when it finally came
about.
*jeffrey*
-------------------------------------------------------------------------
Jeffrey E.F. Friedl Omron Corporation, Nagaokakyo (Kyoto), Japan
jfr...@omron.co.jp [ DoD##4 N8XBK 92 CB-1 400 ]
See my Jap/Eng dictionary at http://www.cs.cmu.edu:8001/cgi-bin/j-e
Joyjeet Bhowmik
(the book) for later reference (kind'a like K & R's C book)?
Joyjeet
Mike Stok
Joyjeet Bhowmik <zjx...@hou.amoco.com> wrote:
>What would be a good book/primer to learn Perl and also keep it
>(the book) for later reference (kind'a like K & R's C book)?
To get up to speed in perl the best book in my opinion is Learning Perl by
Randal Schwartz, it is not so good as a reference book as it's a tutorial
which gets you going and deliberately misses some of perl's features out.
Programming Perl by Larry Wall & Randal Schwartz is a pretty good
reference for perl4, some time in the next year it'll be revised to cover
perl5. For what it's worth, I think it's worth having both books.
Hope this is useful,
Bill Karwin (Contractor-MM)
: What would be a good book/primer to learn Perl and also keep it
: (the book) for later reference (kind'a like K & R's C book)?
The only books about Perl are the O'Reilly books already mentioned.
I'd buy "Learning Perl" to learn perl (of course!), and then for
reference I'd make a nice postscript printout of the Perl man page,
and put it in a nice 3-ring binder. There's also a postscript quick
reference card that is available on the Net.
Gene Spafford
As an educator, I must partially disagree.
Languages such as Pascal or C++ are not very good as first languages.
You have to spend a lot of time teaching syntax before students can
formulate reasonable programs. You have to teach about all the quirks
in doing reasonable I/O. You need to teach about machine precision,
linking with different libraries, and more. That isn't what I really
want to teach my intro students.
What I want to teach in an intro class is how to define a problem, how
to design a solution, how to partition the solution into separate
verifiable/testable parts, and how to evaluate the solution. To do
this, I would like them to be able to write moderately sophisticated
programs without worrying about data types, variable precision, and so
on.
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
* It uses workspaces, so there is no need to describe file structure
and long-lived values are automatic
* No type declarations are needed -- context determines type
* 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?)
* Sets are a native data type (there are only five: numbers,
strings, compounds (records without field names), lists, and
tables (sort of associative arrays).
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
pub/abc).
After the students have learned how to solve a problem properly,
optionally with the computer, then it is apprpriate to teach them a
motr traditional language involving a compiler and other restrictions.
But the key is to get them in the right mindset for learning how to
develop and employ algorithms *first*.
--
Gene Spafford, COAST Project Director
Software Engineering Research Center & Dept. of Computer Sciences
Purdue University, W. Lafayette IN 47907-1398
Internet: sp...@cs.purdue.edu phone: (317) 494-7825
Robert Sanders
>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
Larry Wall
: > * 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
Robert Sanders
>> 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. :-)
Steven Grady
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."
Steve Bleazard
: In article <TOMK.94Ju...@pdx192.news.jf.intel.com> to...@ichips.intel.com (Tom Kraljevic) writes:
: I think a strongly typed language such as Pascal or C++ is best to
: learn first.
: As an educator, I must partially disagree.
[An excellent argument that simpler languages (abc being cited) without
all the extra baggage of linking, machine specifics, types, complex io
etc that come with Pascal and C++ et. al. deleted]
First, I am not interested in a flame war, please if you feel a flame coming
on do it in email, thanks.
The education of programing languages has always bothered me. Computers are
very 'hands on' devices allowing students to play with languages almost
immediately. This means that often the first experience of programming
is done without any formal background.
Comparing this to the pure sciences (chemistry in my case), no one
would ever express a desire to allow there students to play with
Quantum Mechanics in some meaningful way before a formal introduction
to the subject. There is a lot of ground to cover before anything
can have real meaning. Sure, sometimes lab experiments preceed the
lectures, but real understanding only comes (in most cases anyway)
with the lecture course.
Programming is very much the same. Good programming is in my opinion
a very scientific problem. There is are lot of fundamentals to cover
before the first line of code is written. I happen to believe in the
statement "Data Structures + Algorithms = Programs" by N. Wirth. This
has nothing to do with pascal, c++ etc (I program in about 20 languages
including perl). This is about methology: how a problem is converted into
a program. Other's have different ideas about how a problem is broken
into it's components and solved. Which ever method is chosen there is
always a dependency on a number of fundamental concepts. These must be
taught before any problems are tackled.
My belief is that a good grounding in the fundamental concepts is required
before any serious (and in many cases not so serious) programming is done.
The point about linking etc. is valid, but Borland pascal solves this
problem by being very fast and behaving more like an interprated language.
Finally, it's probably obvious that I am not an educator!
Steve
--
"Let's go to work" - Reservoir Dogs
Budi Rahardjo
``perl, the BASIC of the 90s''
-- budi - still can't think recursively.
--
Budi Rahardjo <Budi_R...@UManitoba.Ca>
#include <std-disclaimer.h>
Unix Support - Computer Services - University of Manitoba
Larry Wall
:
: >> 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.
I have an slight aversion to implicit dereferencing, and a stronger
aversion to breaking old code. But you're right in that there is
some primitive typology to ordinary variables, and I haven't thrown
that away, so saying that variables aren't typed in Perl is a bit
of an overstatement. The gist of it is correct though--scalar variables
aren't typed in Perl, while the instances they reference are:
$fido = new Doggie;
print ref $fido;
will print out "Doggie". And calling
feed $fido;
will call the feed method in class "Doggie" (or one of its base classes).
: $$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.
I don't know why you only put the curlies on the hash reference--that's
really independent of type. %$ref works just as well as %{$ref}.
The main reason I did it the way I did was that people kept expecting
it to work that way. And the rule is really quite simple. Anywhere
you might put a symbol, you can replace it with either a simple scalar
variable or a block returning a reference.
Much of the time, however, people are going to use the syntactic
sugar of multi-dimensional arrays:
$count[2]{BAR}[42] += 3;
In fact, most of the time, they aren't going to use references at all.
References in Perl are something that just need to be possible, not
necessarily easy. There are things worth doing that aren't worth
doing well. To do it "well", I'd've had to turn Perl into one of
those languages where you have to learn the whole language before
you can use any of it. And then it would no longer be Perl.
: Of course, those are only for builtin
: types, but even the use of refs to class instances isn't pretty.
Perl never was about beauty, but I think it's prettier than you give
it credit for here.
: 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
I've already announced that Perl 5 will have some form of operator
overloading, so you'll be able to say $a + $b. Even now, though,
you can say
add $a $b
which seems pretty durn uncluttered to me.
: 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.
If you and I always agree, then one of us is redundant.
: P.S. NO MORE ROT13 JOKES! It's not Larry's fault if his home keys
: are all punctuation. :-)
I do worry about visual clutter, and have done so since the day my daughter
came in, looked over my shoulder, and said, "What is that, swearing?"
Larry
Robert Sanders
> I have an slight aversion to implicit dereferencing, and a stronger
> aversion to breaking old code.
Well, it's probably wrong to wedge C++-like references into Perl, but
that isn't what I mean. Perl has 'value' semantics, and
Lisp/Scheme/Dylan have more or less 'reference' semantics. There
isn't anything I'd call "implicit dereferencing" because it's
impossible to ever see a naked reference. In Perl, you can have a
list Right Here (in a @something variable) or you can have a list
Somewhere Else (with a reference). In Lisp et al you don't have the
choice.
> : $$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.
> I don't know why you only put the curlies on the hash reference--that's
> really independent of type. %$ref works just as well as %{$ref}.
It was a bad edit. I had curlies around all of them, but thought it
was unfairly punctuational. You need them sometimes, but not always,
so I decided to take them out, and in my addled state, missed one.
> In fact, most of the time, they aren't going to use references at
> all.
Really? Let's say I have a function that takes two lists. It's
either going to take references or type globs, and references are the
clear winner in most cases.
I think it's always going to be confusing to people that argument
passing coalesces all the arguments into one big list with no
discernible boundaries.
> those languages where you have to learn the whole language before
> you can use any of it. And then it would no longer be Perl.
I think there are very few languages like that. C++ is guilty, but I
use many languages about which I don't know everything (obviously).
Just for my information, could you tell me some of the others?
> I've already announced that Perl 5 will have some form of operator
> overloading, so you'll be able to say $a + $b. Even now, though,
> you can say
>
> add $a $b
>
> which seems pretty durn uncluttered to me.
Duh. Thinko. I knew I shouldn't have argued. In my defense,
although I contributed several fixes to perl5 and I wrote the Linux
dynamic loader, I've written exactly *one* perl5 program and that was
back in the early alpha days. I knew about the other method syntax,
but I was trying to make a point; I guess that knowledge didn't feel
like interfering.
Hey, it's Perl. There's got to be more than one way to invoke
methods. I really don't mean to bash Perl. I'm just trying to point
out some of the nuances that might be unnecessarily interesting in a
teaching language.
Since we're on the subject of overloading, will there be a way to
specify a function to give the string representation of an object?
I'd like to be able to use simple interpolation (print "answer was
$a") instead of some more explicit function call of a's print method.
-- Robert
Logan Shaw
> > * 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:
$ time perl -e 'print "1", "0" x 10001, "\n";'
Real 0.5
User 0.0
System 0.1
Oh - you wanted it in base 10?
Rolf Marvin B{o}e Lindgren
> > 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:
>
> $ time perl -e 'print "1", "0" x 10001, "\n";'
> Real 0.5
> User 0.0
> System 0.1
>
> Oh - you wanted it in base 10?
>
~ ask-1>time perl -e 'print "1", "0" x 10001, "\n";'
real 0.1
user 0.0
sys 0.0
--
Rolf Lindgren | "The opinions expressed above are
9111 Sogn Studentby | not necessarily those of anyone"
N-0858 OSLO | rolf.l...@psykologi.uio.no
Logan Ratner
>...
>The education of programing languages has always bothered me. Computers are
>very 'hands on' devices allowing students to play with languages almost
>immediately. This means that often the first experience of programming
>is done without any formal background.
>
>Comparing this to the pure sciences (chemistry in my case), no one
>would ever express a desire to allow there students to play with
>Quantum Mechanics in some meaningful way before a formal introduction
>to the subject.
Or worse, allow students to go mix reagents without any formal
introduction to the subject. Fortunately, its rather more difficult
to cause permanent harm to yourself or your equipment by unstructured
tinkering with a programming language than with a chemistry set.
Still, though. Computers are tools that are useful at many levels.
Understanding enough programming to get useful computational results
is something that should come early, and in a hands on manner.
Should a Mechanical Engineering student (for example) be required to
sit for a semester class in data structures, and another in algorithms,
before being allowed to try programming in Matlab?
For that matter, should a chemistry student have to get through Quantum
Mechanics before he is allowed to do stochiomatry? I should hope not.
--
Logan Ratner | rat...@rice.edu | It is not funny that a man should die, but
Softlib Manager | s...@rice.edu | it is funny that he should be killed for so
CRPC Rice Univ. | STC 171 Fondren | little, and the coin of his death should be
tinker - tailor - cybernaut | what we call civilization - R. Chandler
Larry Wall
: > all.
:
: Really? Let's say I have a function that takes two lists. It's
: either going to take references or type globs, and references are the
: clear winner in most cases.
Most of the time a function isn't going to take two lists.
: I think it's always going to be confusing to people that argument
: passing coalesces all the arguments into one big list with no
: discernible boundaries.
Part of the reason it's confusing is that people have conflicting
expectations. Sometimes they expect lists to autointerpolate, and
sometimes they don't. I went for consistency in this particular case,
rather than trying to second-guess when the user expects what.
I think people will latch rather quickly onto the Perl5ism that backslash
means to protect the following thing from interpretation. It's so much
like how backslash behaves in the usual Unix string, and it's so much
like how ampersand behaves in C.
Of course, there will always be the people that just don't manage to
latch on at all, but they're not gonna latch onto Lisp or C either...
: I think there are very few languages like that. C++ is guilty, but I
: use many languages about which I don't know everything (obviously).
: Just for my information, could you tell me some of the others?
Well it's all a matter of degree, of course, but I'd tend to put Ada
and Icon in that category. C has tendencies that way which are amplified
greatly in C++. It's a tough call, actually, because whether some
subset of a language is easy to learn depends in part on the shared
cultural heritage of the language and the user, and in part on how
fascist the language designer is about making people do it "the right way".
I think Lisp does pretty well at this by the way. Language cultures
that are evolved rather than designed tend to do well here, because
there's always that pressure to make sure the old code works, and that's
going to be a cultural subset, unless there have been genocidal episodes.
: Hey, it's Perl. There's got to be more than one way to invoke
: methods. I really don't mean to bash Perl. I'm just trying to point
: out some of the nuances that might be unnecessarily interesting in a
: teaching language.
I don't disagree with you. There is value in learning theory, and there's
plenty of non-theory in Perl.
: Since we're on the subject of overloading, will there be a way to
: specify a function to give the string representation of an object?
: I'd like to be able to use simple interpolation (print "answer was
: $a") instead of some more explicit function call of a's print method.
As far as I can recall offhand, the proposed overloading module included
the capability of intercepting implicit conversions.
On the other hand, the folks looking at persistence say that the current
default string conversion of references is rather useful, and overloading
that might put a crimp in generality of a persistence package. I don't
profess to know the best answer here.
Larry
Bill Janssen
In article <CtKGM...@taligent.com> lo...@taligent.com (Logan Shaw) writes:
> > 486dx33:
>
> $ time perl -e 'print "1", "0" x 10001, "\n";'
> Real 0.5
> User 0.0
> System 0.1
Dec ALPHA:
~ ask-1>time perl -e 'print "1", "0" x 10001, "\n";'
real 0.1
user 0.0
sys 0.0
Sun SparcStation-10:
% time python -c 'a = pow(2L, 10001)'
0.1u 0.0s 0:00 104% 0+436k 0+0io 0pf+0w
% time python -c 'print pow(2L, 10001)'
39901262[...digits omitted...]193418752L
5.0u 0.0s 0:05 93% 0+532k 1+9io 0pf+0w
or:
% /usr/5bin/time python -c 'a = pow(2L, 10001)'
real 0.3
user 0.1
sys 0.0
% /usr/5bin/time python -c 'print pow(2L, 10001)'
39901262[...]585193418752L
real 6.0
user 5.0
sys 0.1
Bill
--
Bill Janssen <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html
ozan s. yigit
...
I think people will latch rather quickly onto the Perl5ism ...
what choice do they have?
Robert Sanders
> Most of the time a function isn't going to take two lists.
I think that's a self-fulfilling prophecy. I can't count the number
of times I had to code around 'args are one big happy list' with
typeglobs or some other hacks. If it's easy, I think it's a very
natural (and efficient) way to do things. It's much faster to push
two refs on the stack than X+Y elements.
> I think people will latch rather quickly onto the Perl5ism that
> backslash means to protect the following thing from interpretation.
> It's so much like how backslash behaves in the usual Unix string,
> and it's so much like how ampersand behaves in C.
I thought my point was that 'most of the time people won't be using
references' wasn't necessarily true. Here you say they'll catch on
rather quickly. Does that mean you agree?
> On the other hand, the folks looking at persistence say that the
> current default string conversion of references is rather useful,
Most of the time people aren't going to be using object persistence.
(I couldn't resist.) Seriously, this is obviously a special case that
won't directly affect most people; the persistence people can do a
little extra work to get that behavior so most of us don't have to
suffer for it. I think that most of the time (perhaps not when I'm
debugging) 'SCALAR=(0x74000)' as an object's string representation is
not going to do me any good.
Well, it might build character.
-- Robert
Jim Bowery
> Has anyone thought whether Perl could be a good introduction to
> programming and therefore be used as a first programming language
> in school or college?
>
Yes, it would.
--
The promotion of politics exterminates apolitical genes in the population.
The promotion of frontiers gives apolitical genes a route to survival.
Dragomir R. Radev
Wow! What should I post to the net today to make Larry post some more
of those witty things?
D.
In article <1994Jul28....@netlabs.com>,
Larry Wall <lw...@netlabs.com> wrote:
>In article <OZ.94Jul...@nexus.yorku.ca> o...@nexus.yorku.ca (ozan s. yigit) writes:
>: lwall:
>: ...
>: I think people will latch rather quickly onto the Perl5ism ...
>:
>: what choice do they have?
>
>Ozan, Ozan. You're such a great straight man. I feel like Cyrano on the
>subject of noses. I can't choose among all the bales of hay, so I'll just
>let you choose your own favorite answer.
>
>The Calm Answer
>
> The same choices they've always had, and more.
>
>The Snotty Answer
>
> What a snot!
>
>The Zen
>
> What is the sound of one person choosing?
>
>The Sarcastic
>
> Oooh, I'm sooo sorry. I take it all back.
>
>The Good Old Boy
>
> Hey, ease off on the caffeine, buddy.
>
>The Mindless Aphorism
>
> Perl programmers have the choice of freedom, and freedom of choice.
>
>The Light Witticism
>
> Now, now. Let's not confuse Occam's Razor with Ozan's.
>
>The Veiled Insult
>
> People always have the choice of remaining ignorant.
>
>The Slam Dunk
>
> They can go with me, or they can go with you, or they can go nowhere.
> But gee, the last two options are the same.
>
>The Tolkien Allusion
>
> "The choice is yours, to go or stay."
>
>The Obvious Biblical Allusion
>
> "There's a time for everything under the sun..."
>
>The Obscure Biblical Allusion
>
> "And when there had been much disputing, Peter rose up, and said
> unto them, Men and brethren, ye know how that a good while ago
> God made choice among us, that the Gentiles by my mouth should
> hear the word of the gospel, and believe."
>
>The Poetical Allusion
>
> "Two roads diverged in a wood..."
>
>The Personal Allusion
>
> They've got lots of choices, including even SDBM.
>
>The Flame
>
> [FLAME ON!!!!!!!!]
> How DARE you quote me out of context like that?!?!? You make me sound
> like another Hitler or $omething!!! Just shut the fuck up, okay?!
> [flame off]
> By the way, how's the wife and kids?
>
>The Imminent Death of the Net Predicted
>
> With content-free messages like that, it's no wonder the net is
> going downhill. What we really need is an administrative solution
> to this problem. Now if we could just get some of the backbone SAs
> to agree...
>
>The Psychobabble
>
> What you're saying is valid, but you know, you really have to
> let me be me.
>
>The Flower Child
>
> Peace, man. Got any good stuff?
>
>The Rodney King
>
> Why can't we all just get along?
>
>The Sergeant Friday
>
> You have the right to remain silent.
>
>The Quote Bait
>
> Unlike most computer languages, Perl is both pro-choice and pro-life.
>
>The Paternal Patter
>
> That's okay, Ozan, I understand where you're coming from.
> I once went through the rebellious stage you're going through,
> but eventually I settled down and started getting some real work
> done. These things just take time. Be patient with yourself.
>
>The Philosophical Discourse
>
> While none of us can, in fact, choose anything freely, we must
> make our own meaning out of the absurd by pretending that our
> choices do matter. In this way we authenticate ourselves; we
> demonstrate our existence to everyone who cares, which is, of
> course, nobody but ourselves. In this we are the elohim.
>
>The Direct Answer
>
> They can choose to use the new feature, or they can choose to
> program in the subset of Perl 5 corresponding to Perl 4, which
> many people have oddly enough found to be perfectly adequate.
>
>The Oversimplification
>
> Perl is about nothing BUT choice.
>
>The Infinite Recursion
>
> Ozan, Ozan. You're such a great straight man. I feel like Cyrano...
>
>The Best Answer
>
> [This space intentionally left blank.]
>
>Love,
>Larry
--
Dragomir R. Radev Graduate Research Assistant
Natural Language Processing Group Columbia University CS Department
Office: (212) 939-7121 Lab: (212) 939-7108 Home: (212) 866-8548
http://www.cs.columbia.edu/~radev/home.html
Allen S. Rout
-=> o...@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?
--
< a...@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>
Larry Wall
: ...
: I think people will latch rather quickly onto the Perl5ism ...
:
: what choice do they have?
Ozan, Ozan. You're such a great straight man. I feel like Cyrano on the
Logan Shaw
> > 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.
Karen D. Rayl
> Has anyone thought whether Perl could be a good introduction to
> programming and therefore be used as a first programming language
> in school or college?
Yes, it would.
perl was the first language i learned.... =]
karen.
ozan s. yigit
the reference to cyrano is especially entertaining, although in
this particular case, a reference to the "Ring of the Nibelung"
could have been appropriate also.
two other possible answers:
The Populist:
they want it. they shall have it.
The Designer:
trust me, i know what i am doing.
oz
Richard Smith
The "Beavis & Butthead" version:
Butthead: Perl 4 is cool, but Perl 5 is, like, even more cool. Huh, huh.
Beavis: But doesn't that mean Perl 4 sucks?
Butthead: No way, asswipe! Just because one thing is cool doesn't, like,
automatically make something else suck!
Beavis: Yeah, Yeah, I get it. But, like, why is Perl, like, so cool?
Butthead: I think it's because, like, Larry Wall's, like, from Seattle
or something. Huh, huh.
Beavis: Yeah. Huh, huh.
----------
The "Deep Thoughts by Jack Handey" version:
"Last night I spent the whole night on my computer. In the morning my wife
woke up and asked me what I was doing. I told her I was telling some guy
at Cornell why it's better to stay with Perl 4 until there's a really good
reason to switch to Perl 5."
"My wife told me she wanted a divorce."
--
+------------------------------------------------------------------------+
| Richard S. Smith | PROGRESS(tm) 4GL Developer | Monrovia, California |
| rsm...@netcom.com | Holding my breath for V7.3 | Voice: (818) 303-7346 |
+------------------------------------------------------------------------+
Randal L. Schwartz
Richard> Butthead: I think it's because, like, Larry Wall's, like, from Seattle
Richard> or something. Huh, huh.
Perl. And Pearl Jam.
Coincidence?
I think not.
Our first album: "Smells like Camels and Llamas".
print "Just another Perl hacker," # but not what the media calls "hacker!" :-)
# legal fund: $1182.57 collected, $11835 spent; email @FUND in body for details
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@stonehenge.com> Snail: (Call) PGP-Key: (finger mer...@ora.com)
Phrase: "Welcome to Portland, Oregon ... home of the California Raisins!"
Jack Campin
>> 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).
>> * 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: ja...@cee.hw.ac.uk Bitnet: via UKACRL BANG!net: via mcsun & uknet
John R. Bane
>rsan...@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: ba...@tove.cs.umd.edu
UUCP:...uunet!mimsy!bane
Voice: 301-552-4860
Alan Gunderson
> 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 genralized 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.
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
John R. Bane
>
>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
>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.
>
(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.
Dylan Northrup (SCI)
: In article <OZ.94Jul...@nexus.yorku.ca> o...@nexus.yorku.ca (ozan s. yigit) writes:
: : lwall:
: : ...
: : I think people will latch rather quickly onto the Perl5ism ...
: :
: : what choice do they have?
: Ozan, Ozan. You're such a great straight man. I feel like Cyrano on the
: subject of noses. I can't choose among all the bales of hay, so I'll just
: let you choose your own favorite answer.
[List of answers deleted]
Bravo, my good man, bravo.
: Love,
: Larry
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Dylan Northrup -- Physics Education | "And She knows she's more than |
| nort...@madonna.coedu.cas.usf.edu | just a little misunderstood |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ She has trouble acting |
| Will system admin && || code HTML for food | normal when she's nervous." |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
Your Name
>
>In article <Y-PISAN.94...@SPD-13.ils.nwu.edu> y-p...@nwu.edu writes:
>>
>>
>>I don't think Perl would be a good first language.
>>
>> * Too many ways of doing anything. A person new to the
>>language might get confused with the possibilities.
>
>Then don't tell them all the possibilities. Stick to the essentials.
>That's what any course on a first language should do to start with.
>That's what the Llama book does.
>
>> * Too much syntax. A new user will have a terrible time
>>keeping the $#,$!,& and % notations together
>
>$ scalar, @ list, % hash, & subroutine. Some languages declare what
>type a variable is before use; some languages use a "marker" on each
>use of the variable. Neither way is necessaril better, just different.
>You could argue that a new user prefers knowing what sort of item is
>being looked at straight away rather than remembering or searching
>upward for a declaration. Things like $! are no longer necessary with
>perl5. Put "use English;" at the top and the variable $OS_ERROR is
>what you want.
>
>> * It is still like a compiled language (compared to
>>interpreted languages like scheme and lisp) which adds another step
>>for the new user.
>
>The fact that perl is compiled internally is irrelevant here. You write
>a program foo, you run it with "perl foo". There's no compilation step
>which really is a noticable "extra step" to learn. I realise that
>you're thinking of Lisp here where everything is "interactive". Again,
>that's just different, not better.
>
>> * Programs in perl generally use lots of global variables.
>>When starting programming it is importantant to use local variables.
>
>Badly written programs in many languages use global variables. Perl
>is no exception. Local variables are available in perl with
> local($foo);
>and, of course, learners should be taught to use them (as should
>everyone else). Perl5 has lexically scoped variables too, with
> my($foo);
>In Perl, you can ensure that global variables aren't used by mistake
>by doing "use strict vars;". Then trying to access $foo when $foo
>isn't locally in scope gives an error instead of assuming you mean
>a global variable. Variables which have to be global can be gathered
>together in a separate package and referred to explicitly.
>>
>> * Parameter passing in perl looks a little shaky to me (maybe
>>because I'm new to perl). Passing multiple arrays should be easier.
>
>It is in Perl5---just pass a reference to the array.
>
>> * Perl does not provide access to its internal constructs,
>>unlike lisp which is all cons cells. Seeing internal structures makes
>>it easier.
>
>Here is where I would explicitly disagree with you. A learner should
>not be concerned with internal structure. If you have a rack of
>pigeonholes with ages in you just want to know that
> $age{"Fred"} = 40;
>saves 40 in Fred's age pigeonhole and you can get it back later with
> $age{"Fred"}
>
>>Disclaimer: I am new to Perl and come from a lisp background (so I
>>like parenthesis)
>
>So I gathered (((:-)))
>
>--Malcolm
>--
>Malcolm Beattie <mbea...@black.ox.ac.uk>
>Oxford University Computing Services
>Forthcoming change of address: will be <mbea...@sable.ox.ac.uk> (but not yet).
>"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee
From a high school teachers perspective, I would like to see my
second year students give it a try. Some of the variables seem a little
criptic, passing more than one array is not real nice, but it provide some
nice variety.
Breck Baldwin
>In article <1994Jul15....@black.ox.ac.uk>, mbea...@black.ox.ac.uk (Malcolm Beattie) says:
>>
>>In article <Y-PISAN.94...@SPD-13.ils.nwu.edu> y-p...@nwu.edu writes:
>>>
>>>
>>>I don't think Perl would be a good first language.
tons of stuff deleted
>
>From a high school teachers perspective, I would like to see my
>second year students give it a try. Some of the variables seem a little
>criptic, passing more than one array is not real nice, but it provide some
>nice variety.
Well, IMHO the debugger nixes Perl's chance at being a 1st language. Just
the simple fact that variables are not shown with values (I'm so afraid that
someone will just up and say: just use the -z flag) makes things
pretty tough for a newbie--and I know, you learned to program with vacum
tubes and had to debug by watching them flicker--thought punch cards were
frivilous.
breck
------------------- A .sig for the 90's --------------------------
finger br...@unagi.cis.upenn.edu for my educational software resume
Larry Wall
: Well, IMHO the debugger nixes Perl's chance at being a 1st language. Just
: the simple fact that variables are not shown with values...
I don't understand this "simple fact" at all. Could you give an example
of what you mean?
Larry
Breck Baldwin
Sure: To see the value of variable '$foo' while stepping through the code
you have to type 'p $foo'. A really helpful feature is to have
bindings for variables available when you encounter them as
you step through the code. Something like if you see
$foo =~/$hairy_reg_exp/;
you see on another line something like:
$foo = "fe fi fo fum",
$hairy_reg_exp = "(fe|fum)*froo",
even a command to bring such bindings up would help tons.
Now I'm waiting for someone to tell me that this is already implemented,
and to RTFM. But such are the hazards learning.\
Larry Wall
: Sure: To see the value of variable '$foo' while stepping through the code
: bindings for variables available when you encounter them as
: you step through the code. Something like if you see
:
: $foo =~/$hairy_reg_exp/;
:
: you see on another line something like:
:
: $foo = "fe fi fo fum",
: $hairy_reg_exp = "(fe|fum)*froo",
:
: even a command to bring such bindings up would help tons.
:
: Now I'm waiting for someone to tell me that this is already implemented,
: and to RTFM. But such are the hazards learning.
It's not implemented, but it would be pretty easy to add a command that
extracted variable names from the current line and printed them out.
In fact, I'd classify that as a good idea. Thanks. Anybody want to
hack it into perldb.pl? dumpvars.pl can already take a list of variables.
Larry
Breck Baldwin
Wow! I've finally done something that will change the course of history!
Do I get it named after me???? That would look like:
h Prints out help message.
T Stack trace.
s Single steps.
F_Breckenridge_Baldwin Prints value of variable names of current line
...
I can see it now, my contribution's role in a moment of duress....
Scenero:
Large Comet on collision course w/ earth. Nuke Missiles on direct intercept
are Earth's only chance.
Sweaty ensign: "Sir! the detonate program has a bug, the missiles are
not going to explode!"
Block Jawed Commander: "Run the debugger!, arrrrhg, get away from
that terminal you simpering fool...lesse,
>emacs detonation.prl&
>"perl -d", C-x, C-s,
>detonation.prl
>
Loading DB routines from $RCSfile: perldb.pl,v $$Revision: 32.0.1.3 $$Date: 2009/06
/08 13:43:57 $
>Emacs support available.
>Enter h for help.
>main'(detonation.prl:3): require(global_variables);
DB<1>b light_fuse
DB<2>c
main'light_fuse
DM<2>n
DM<2>&light_zippo_ if ($flint_working & $not_much_wind & $not_showing_off)
DM<2>F_breckenridge_baldwin
DM<2>f_Breckenridge_baldwin
DM<2>F_breckenridge_Baldwin
Commanders screams in frustration, the missiles slip harmlessly past the
comet, and the earth is reduced to a cinder.
---------end of scenero
On second thought, I think you should make the command case insensitive.
breck "does this come out of my 15 minutes of fame" baldwin
Tye McQueen
) In article <32ro4i$g...@netnews.upenn.edu> br...@unagi.cis.upenn.edu
) (Breck Baldwin) writes:
[If to step to the following line in the debugger:]
) : $foo =~/$hairy_reg_exp/;
) :
) : you see on another line something like:
) :
) : $foo = "fe fi fo fum",
) : $hairy_reg_exp = "(fe|fum)*froo",
)
) It's not implemented, but it would be pretty easy to add a command that
) extracted variable names from the current line and printed them out.
) In fact, I'd classify that as a good idea. Thanks. Anybody want to
) hack it into perldb.pl? dumpvars.pl can already take a list of variables.
I was planning on putting my Perl4 debugger hacks into Perl5 and
wanted to know how best to do them so that they could become part
of the distribution. I'll take a stab at the above as well.
(I assume I can't parse Perl code so I'll just look for something
like /([$@%])([\w][\w:']*)([[{]?)/ then pass
"@$2" if $3 eq "[" or $3 eq "" and $1 eq "@"
"%$2" if $3 eq "{" or $3 eq "" and $1 eq "%"
"\$$2" otherwise
I feel like I've stumbled onto Larry's Last Feature: "I've just
thought up an ingenious way to add that feature but it is too
small to be included in this post" :-)
My Perl4 debugger hacks include a way to easilly pipe the debugger
output through a pager ("more" or "less"), and an easier shell
escape that uses the debugger input and output rather than the
script's input and output.
The first item is done by begining a Perl debugger command with
"|". So "|h" pipes the more-than-one-screenful of help through
whatever command $ENV{'PAGER'} is set to.
The shell escape is like typing system("cmd") except that "cmd"
uses the debugger's input and output so it connects to your
terminal even if you did "perl -d script <in >out" (and it is
a lot easier to type, especially if you want to use lots of
quotes in it).
I had strong feelings that "!cmd" should work like so many other
Unix utilities so I remapped the csh-style command recall stuff
to use ".5" instead of "!5". The new perl debugger may use
GNU's readline library so we may have ksh-style vi/emacs
command recall and the csh-style stuff will be less important
(no need to delete it, just less problem changing it).
This is where I'd really like some feedback. Does anyone have
a better idea, one that doesn't clobber the csh-style command
recall? Or is it okay to change it a bit?
Thanks
--
Tye McQueen t...@feenix.metronet.com || t...@doober.usu.edu
Nothing is obvious unless you are overlooking something