Re: 10 ten things any good programmer can/has done?

Vesa Karvonen wrote:
> Jon Harrop <usenet@xxxxxxxxxxxxxx> wrote:
>> Vesa Karvonen wrote:
>> > Jon Harrop <usenet@xxxxxxxxxxxxxx> wrote:
>> >> As the videos are old now (1986?), they won't discuss lots of
>> >> interesting developments done more recently.
> [...]
>> He said that typesetting is "an accidental phenomenon". Only a Lisp
>> programmer could say that.
>
> ;-)
>
> Well, I can see that you are mostly bitching about the use of fully
> parenthesized prefix syntax. To quote Shriram Krishnamurthi, syntax
> arguments are lame. I strongly believe that an introduction to CS should
> stress issues other than the surface syntax of some programming language.

Yes, absolutely. By using Lisp they are forcing themselves to stress
syntactic issues (explain the syntax) when they are entirely unimportant.

Like I said, if you're going to write "pattern -> skeleton" on the board
then you should not be writing:

d(a+b)/dx -> da/dx + db/dx

in Lisp as:

(cond ((sum? exp) (make-sum (deriv (a1 exp) var)
(deriv (a2 exp) var)))

when you could be writing:

D[a_ + b_, x_] -> D[a, x] + D[b, x]

in Mathematica.

Put it another way - how much longer and more obfuscated does the syntax
have to become before you'll agree that it is no longer a "lame" issue but
a crippling hindrance?

> I'm not saying that syntax doesn't matter at all, but I'm saying that
> introducing CS through a language whose syntax is fairly complicated is a
> big mistake. It means that more time has to be spend teaching the
> intricacies of the syntax and less time will be available for teaching the
> deeper concepts.

But there is a trade off between simple syntax and simple programs.
Abelson's example pattern matches would much much simpler and easier to
understand in a language with native support for pattern matching.

>> Then he writes the abstract syntax tree for "1+2" as a tree with three
>> leaves: "+", "1" and "2". <cringe>
>
> I'm not entirely sure what you mean, but I assume that you mean that the
> tree should be of the form on the left hand side below rather than of the
> form on the right hand side:
>
> + apply
> / \ / | \
> 1 2 + 1 2
>
> The above trees are quite different. The *AST* on the right hand side
> represents applying the function + (or, more precisely, the function bound
> to the variable +) to the arguments 1 and 2. That is precisely how it is
> in most functional languages.

No. The left is the conventional representation of an AST. The right comes
directly from Lisp's syntax '(+ 1 2).

My compiler books all use the left-hand style.

> OTOH, the tree on the left hand side treats
> + as a(n AST) constructor, which isn't the case in many modern languages.

Indeed, Appel uses BinOp(Plus, 1, 2) but still draws the left-hand AST.

>> Just looking at the "Henderson Escher Example", he gives Lisp code for
>> map:
> [...]
>> He also gives the code:
>
>> (cons 1
>> (cons 2
>> (cons 3
>> (cons 4 nil))))
>
>> which is just the linked list:
>
>> 1::2::3::4::[]
>
>> or even:
>
>> [1; 2; 3; 4]
>
> This is precisely the kind of lame syntax stuff that I think should not be
> stressed while introducing CS.

Yes, absolutely. Consider this code from lecture 7a:

(define eval
(lambda (exp env)
(cond ((number? exp) exp)
((symbol? expr) lookup exp env)
((eq? (car exp) 'quote) (cadr exp))
((eq? (car exp) 'lambda) (list 'closure (cdr exp) env))
((eq? (car exp) 'cond) (evcond (cdr exp) env))
(else (apply (eval (car exp) env)
(evlist (cdr exp) env))))))

With OCaml's pattern matching, for example, that is just:

let eval env = function
| Num n -> n
| Var v -> assoc v env
| Quote e -> e
| Lambda f -> Closure(f, env)
| Cond e -> evcond e env
| Apply (f, args) -> apply (eval env e) (map (eval env) args)

Not only is that shorter and easier to read, it is almost self contained (it
doesn't require number?, symbol?, eq?, evlist and lookup to be defined,
only evcond).

> The time should be spent on more fundamental principles and concepts such
> as "black box abstraction".

Yes. Time should not be wasted explaining Lisp's syntax when Lisp has an
unusually obscure syntax in order to support its metasyntactic capabilities
and first-order code, neither of which are worth the time they are given.

>> Types!
>
> This one is controversial. Frankly, I don't know whether the first
> language being taught should be typed or not.

No debate there: the language must be typed. I don't think untyped FPLs even
exist.

> I would probably tend
> towards starting with a dynamically checked language and then introduce
> types later in the course in the form of motivating, specifying and
> implementing a simple type checker for a reasonably subset of the
> language.

Yes. I would certainly discuss both static and dynamic typing. Moreover, I
would introduce and use static typing before pattern matching in order to
show how pattern matching is used to extract the data associated with
variant type constructors in ML.

>> I think the widespread adoption of static typing in FPLs has to be a big
>> one. A lot of very useful information could be presented on that,
>> including the basics of HM up to an overview of type classes, polymorphic
>> variants and statically typed approaches to OO. I'd wager that a lot more
>> people use static typing than use the "metacircular evaluator" that they
>> discuss for 2.5hrs.
>
> Here my view differs strongly from yours. I think that glossing over a
> large number of static typing buzzwords *instead of* spending the time
> illustrating such fundamental issues as an evaluator for a programming
> language would be a bad mistake.

At the very least, I would give an overview of what dynamic and static
typing were.

>> For other topics, I think currying and HOFs are more easily implemented
>> in ML. Both are important concepts in functional programming.
>
> Higher-order functions and currying are introduced in the lectures and
> book fairly early.

Currying doesn't appear in the table of contents. Where is it in the book?

> Frankly, I don't think that currying is such an
> important concept that it should be strongly stressed in an introduction
> to CS (but HOFs are that important).

Ok. I use currying a lot so I would rank it alongside HOFs.

>> There are also issues such as eager vs lazy evaluation. Haskell has come
>> a long way since 1986!
>
> Lazy evaluation (lazy streams) is introduced in the book and the lectures.

For both of these points, I think it would be better to teach currying, HOFs
and lazy evaluation in languages that make them easy. In the latter case,
that means a lazy language.

>> Overall, I wouldn't have any problem if the series was called "Structure
>> and Interpretation of Lisp Programs" [...] Of course, SML and OCaml have
>> a huge number of advantages over Lisp...
>
> I think that you are strongly confused about the intent of the course. The
> course isn't about teaching a programming language.

Yes, the course should not have been about teaching a programming language,
Lisp. After watching the lectures, I felt I had learning a lot more about
Lisp and Scheme than anything else.

> The idea is to introduce students to rather more fundamental concepts and
> principles in CS and engineering.

Yes.

> Scheme is a convenient vehicle for this purpose precisely because it is so
> simple that they don't have to spend a lot of time teaching the language.

No. Scheme's simplicity forces them to ad-hoc much of their code and
Scheme's simple syntax results in far more code than is necessary. In many
cases, you can validly say that my approach would require teaching of a
more complicated syntax. In this case, they've already explained the "more
complicated" syntax of pattern matching so exploiting it requires no
overhead whatsoever.

The same will go for laziness and many of the other topics.

Assembler has a simple syntax. That doesn't make it suitable for this kind
of work...

> Just look at the videos. How much time do you
> see being spent on teaching Scheme?

About half of the time is spent teaching Scheme or teaching things that you
must do (or implement yourself) in Scheme to get a simple task done.

"A lot of what we're going to do today is worrying about syntax..."
"This question mark doesn't mean anything..."
- lecture 3b video.

But that isn't the correct question. The question should be "how much time
do the students spend trying to understand Scheme's syntax?". A lot, I'd
wager.

> Contrast that with introductory
> courses in universities that start with a language like Java. Such
> introductory courses usually spend almost of all of the time on little
> more than Java syntax.

I taught SML rather than Java at uni so I can't really comment.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
.

Relevant Pages

  • Re: Whats the best language to learn...
    ... on processors designed to run Lisp and Lisp OSes. ... sence that the language make effective use of them. ... No other programming language can do what lisp can do. ... is exactly because of its syntax. ...
    (comp.programming)
  • Re: Language design evolution vs. revolution
    ... Programmers prefer a language that is similar to what they ... I don't like typing lots of extra syntax that is unrelated to expressing ... I prefer structured programming. ... With NASM assembler, I don't have to understand what, why, or most ...
    (comp.lang.misc)
  • Re: Seed7 - what is it? What does it do?
    ... is quite unlike the language I want to build. ... Seed7 is capable to do many things, but some conditions must be met: ... - Syntax and semantic of your language must be independent. ... Structured programming seemed to make programming harder for people ...
    (comp.lang.misc)
  • Re: Language design evolution vs. revolution
    ... Programmers prefer a language that is similar to what they ... Doubtless it is not possible to design in ... do "Fundamentals of programming" include debugging ... probably be one with more familiar syntax and some features of the ...
    (comp.lang.misc)
  • Jacques Arsac (the French Don Knuth)
    ... programming is something instant that can be learned in three ... limited merely to encoding in some agreed language ... Teaching programming boils down to teaching the ... on Computing should be taught by people without computer ...
    (comp.os.cpm)