Re: PERL as a first programming language?

Larry Wall (lwall@netlabs.com)
Tue, 26 Jul 1994 23:34:43 GMT

In article <RSANDERS.94Jul26025543@hrothgar.mindspring.com> rsanders@mindspring.com (Robert Sanders) writes:
: On Mon, 25 Jul 1994 16:09:26 GMT, lwall@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.

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