Path: utzoo!mnetor!uunet!mcvax!ukc!its63b!aiva!jpd
From: jpd@aiva.ed.ac.uk (Paul Dourish)
Newsgroups: comp.lang.misc
Subject: Re: : First Languages
Message-ID: <283@aiva.ed.ac.uk>
Date: 6 Mar 88 16:01:25 GMT
References: <725@sandino.quintus.UUCP>
Reply-To: jpd@eusip (Paul Dourish)
Organization: Alvey Speech Input Project, CSTR, U of Edinburgh
Lines: 61
Summary: The model that underlies the language is more important.

In article <725@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>>In article <1016@its63b.ed.ac.uk>, cstjc@its63b.ed.ac.uk (A Cunnigham) writes:
>> But if you know HOW TO PROGRAM then it doesn't matter if you know C ( or any
>> other language for that matter ). All you need is the manual and a language
>> definition.
>
>To take you out of context, this isn't really true.  If you take a
>skilled 20 year veteran assembly language programmer and give hime an ML
>or Prolog or Smalltalk manual and interpreter, it'll probably take him
>quite a while to get to the point where he can program comfortably in
>any of those languages.  There are important (necessary!)  concepts that
>he hasn't had to face (inheritance, backtracking, unification,
>recursion).

Yaay! Cheers! Applause!

This is exactly the point. A programming language embodies a model of a
machine and a model of the solution. The important thing in a CS education
is that the student should be exposed to a wide range of such models. Remember,
the models that the student encounters in his course will form that basis of
his solutions to problems later. If the student is always tackling things in
a C-like way, then he'll always produce C-like solutions, even when these are
not appropriate. So, then, the student should learn a range of models, so that
he can pick the one most appropriate to a given problem.

Before I get flamed here, I should point out that I'm talking about models on
the level of *understanding* a problem. I'm trying to divorce the understanding
and conceptual modelling of the problem from its solution. There may be
constraints upon the type of solution ("Sorry, John, it's got to be written
in FORTRAN and interface to those COBOL routines over there...") but there's
no need to place such constraints on the programmer's understanding of the
problem to be solved. Not if you want a good solution, anyway.

The idea of underlying models is important. It really bugs me when concepts in
one language are explained in terms of those in a completely different
language, but which look vaguely similar. Too often, the teaching of
programming languages is done syntax-down rather than model-up. The right way
to teach a language is from the base concepts up to the actual syntax. That way
when new ideas are introducted, the student thinks "Oh, yeah, I'd guessed that
there should be something like that; it fits" rather than "Hmm, I wonder how
that relates to what I've already learned".

So, what's the bottom line? Well, here are two quotes. I've seen them
attributed to Dennis Ritchie and Brian Reid respectively, but I'm not certain
about them:

- "A language that doesn't change the way you think about programmming isn't
   worth knowing."

- "When all you have is a hammer, everything looks like a nail."

I guess that's all....

-- 
Paul Dourish, Speech Input Project, University of Edinburgh, 80, South Bridge,
Edinburgh EH1, Scotland. (Phone: +31 225 8883 x279.)

 ARPA: jpd%ed.eusip@nss.cs.ucl.ac.uk   UUCP: ...!uunet!mcvax!ukc!eusip!jpd
                      JANET: jpd@uk.ac.ed.eusip

          "Ain't they got no barbers where you come from, boy?"