Path: utzoo!attcan!uunet!decwrl!shelby!neon!kanamori
From: kanamori@Neon.Stanford.EDU (Atsushi Kanamori)
Newsgroups: comp.edu
Subject: Re: Pascal as a first Language
Message-ID: <1990Jul26.144456.1108@Neon.Stanford.EDU>
Date: 26 Jul 90 14:44:56 GMT
References: <24994.26a7079d@kuhub.cc.ukans.edu> <2560@sequent.cs.qmw.ac.uk>
Organization: Computer Science Department, Stanford University
Lines: 149

In article <2560@sequent.cs.qmw.ac.uk> you write:
>In article <24994.26a7079d@kuhub.cc.ukans.edu> cs300@kuhub.cc.ukans.edu writes:
>>Some of my reasons:
>>The main technique to learn is abstract data types and modularity.
>>Pascal adds all kinds of syntactic overhead to the structuring of
>>data (e.g. "." vs "[]" for essentially the same thing: compound data)

>I think the distinction between arrays - which are indexed -
>and records - which are not - is an important one.
>Of course, you should encourage the use of syntactic structures
>ONLY within procedures and functions which implement the
>abstract data types. In this way, the language syntax becomes a
>minor detail anyway.

Agreed. Syntax is a minor issue.



>
>>Pascal forces everything to be declared globally if it is to retain its
>>value (i.e., there is no private data)

>I think this is acceptable for a first programming course.
>Introducing private data at this stage is only overloading the
>students. They will only get to see the benefit of private data
>as a result of experience, so it is better introduced in the
>second programming course.
>

Disagree. Whether or not abstraction can be left for a second course
is arguable. But Pascal is openly hostile to modern abstraction methods.

  1. No way to hide type definitions that are supposed to be private
     to a module. In fact, no way to hide definitions at all: so
     defining a module has the side effect of creating all kinds of
     unwanted global bindings.

  2. Const, type and var declarations separated for the compiler's
     convenience, making it impossible to put related stuff together.
     How can you call it a module when it doesn't even look like a 
     module?

Most commercial Pascal compilers fix these but those languages
aren't Pascal: they're C or Modula 2 with a Pascal-like syntax.
Why not start off with a language that does this right instead
of using Pascal for one course and then forcing students to unlearn it?




>>Pascal punishes one for recursion (unless tail recursion is implemented)

>At the first programming course stage you shouldn't be worrying
>too much about efficiency. Students are unlikely to be writing
>programs where the inefficiency of Pascal's recursion
>implementation notices.

As a recursion fanatic, I grudgingly agree that for a first course,
students are unlikely to be solving problems for which recursion is
appropriate.



>
>>Procedures and functions are not first class data items and hence only
>>a small subset of programming techniques is learned.

>The use of higher-order functions often strikes me as a dirty
>programming trick, akin to the use of gotos. I don't think I
>have ever had to use it in ten years of writing programs. I
>have seen too many "clever" programs which make unnecessary use
>of procedures and functions as first class data items. I
>think it is best not covered at the initial stage.

Wrong! First class procedures not only simplify a programming language
by getting rid of the artificial distinction between variables and functions,
but they are the only natural solution for many problems. Try writing
a general integration routine, or a sorting routine that can use any
ordering relation without higher order functions. The trick is to
think of a function as a mathematical mapping, rather than place to
branch to: then the notion of passing functions around becomes no 
more mysterious than passing large tables of input-output pairs around.





>
>>Polymorphism is only difficultly achieved to a partial degree.
>Again, while polymorphism has benefits, at the initial stage
>there are positive benefits in NOT using it. Students ought to
>be thoroughly aware that a "list of X" is not of the same type
>as a "list of Y".

I disagree: often, a piece of code wants to think about general relationships
between objects rather than the specific representations of the objects 
themselves. To take the sorting example again, why should the code for 
sorting care what X is if it can be abstracted away in the ordering relation 
passed to it as a parameter?

Similarly, it's stupid to have to type "write-integer" to print integers,
"write-string" to print strings and "write-foo" to write foos. Pascal
gets around this by hypocracy: it violates its own type rules when
it comes to primitive procedures like writeln. Message from Wirth:
"I can do it but you can't. Nyaa nyaa."

It took me a long time to shake off Pascal's "TYPES WILL BE DISJOINT!!!"
dogma and embrace the more natural type hierarchies of object-oriented
languages. Why not teach the right way to start with?



>
>I don't think Pascal is perfect, but it's a reasonable
>compromise between various conflicting requirements. The
>important thing is to stress that it is being used as a
>teaching tool - making sure that students are aware you are
>teaching the principles of good programming, not "coding in
>Pascal".

Pascal may have been good 20 years ago but computer science has made much
progress since then. It is an antiquated and inadequate language and
we should be looking for better ones.

Re: Scheme as a first language, I'm a declared Scheme fanatic. I do have
a couple of serious bitches though:

   1. No way to statically declare the types of variables when I want to.
      How often have you looked at someone else's code:

          (define (foobar set1 mapping2 graph3) ...)
   
      and wondered specifically, what kind of objects foobar wants?

   2. No sensible way to create variables and data private to a file.

       (define x #f)
       (define y #f)
       (let () 
	 ... lots of private stuff here ...
         (set! x (lambda...))
         (set! y (lambda...)))

      is *not* an aesthetic solution. Nor is there any portable way
      to write a macro that does this, at least I haven't come up with one.



Just my $.02.