Wadler's critique of SICP (1987)

I'm curious about your thoughts about whether type errors really were a net negative. I spent a fair amount of time with Haskell and it certainly took a bit of time to get used to working with the type system (type inference is awesome, but it can also make for some mind-boggling errors). In particular, I wondered if your Haskell programs Just Worked after you were able to get them to compile?

The payback for grappling with the type system is usually confidence that your program will run without silly errors (though you can still make silly errors (hello, cut-and-paste)). I'm now spending a fair bit of time in Javascript/NodeJS and Python lands and I need lots of testing to make sure that my program won't experience some silly error sometime in the future (<- perhaps this means I'm not a good dev).

So you did first chapter of Scheme book in Haskell. Ie, in a language authors weren't prepared you for. And you get errors you're not expected as authors couldn't prepare you for them.

I think that's pretty straightforward thing that happened with you. The same will be with Scheme if you do some chapters from Learn You A Haskell.

Also, Haskell type system is one of most logical out there. Most type systems are either build around some weak logic with many exceptions (dynamic languages, C++, Java, C#), or just build from some limited number of cases (Ada, VHDL, Verilog).

The Haskell type system incorporates a logic system (some kind of constructive logic, I think). You actually learned that logic while "fighting the compiler" and you did some of first session with "proof assistant" which Haskell compiler/interpreter is.

So I think you're complaining for nothing.

Not that I stopping you, just my thoughts. ;)

I almost agree with you that programming can be approached from a Scheme mindset... It can be really mind-opening. But I think teaching programming from C++ or Python perspective can be of (almost) equal greatness... You can do many cool things here and there... It only depends on the level of the course. I mean, if you are going to take an advanced course in programming languages design, learning Scheme, Lisp and other languages can be of great help; but if you want to give an introduction to programming - to people with no programming-related experience - C, C++ and Python are very good choices, I think.

Well, forcing me to do Lisp when I was busy figuring out the graphic card registers to do cool things could have turned me from IT altogether. But I also think that if you got to the point when SICP is taught (basically university level CS), you have to do the hard things.

I think it comes down to whether you want to teach programming, or computer science. If it's the former, just teach to POKE with BASIC. If it's the latter, I think you'll quickly find yourself in want of a more sophisticated language, in order to teach any of the non-trivial concepts.

I think that's more a libraries thing that a language thing. For example, you can do very cool, HTMLy things using Racket's web-server/servlet and Scheme continuations, which would be incredibly hard to do in C.

But I agree with your suggestion that C should be teached first. If anything, because C's "computational model" is very simple: you know what executes when; it encourages a more common, procedural way of thinking, and it's easy to do side effects in single-threaded C.

That is true.

There was a lot of programming language research in the 1970's and 1980's that is not really used in mainstream programming languages in these days.

A good collection of this material can be found in Simon Peyton-Jones' book "The implementation of functional programming languages". Probably out of print (my uni library has one), but freely available on the net, here's the link: http://research.microsoft.com/en-us/um/people/simonpj/papers...

It's worth to note that since the Miranda days, Haskell has added type classes that can do some OO-style stuff and more, a sensible and efficient solution for IO that also works well in parallel and a kick-ass compiler and run time system.

I have never seen this sort of definition in scheme. Can you provide a pointer or three to show that this is 'idiomatic'?

Yes, and for good reason. I have seen suggestions elsewhere on the internet that SICP be taught in Python and other languages, and have even seen "ports" of parts of the book to these other languages. But SICP is by now part of a family of textbooks from MIT courses (CLRS and Walter Rudin's Principles of Mathematical Analysis come to mind) that have been utilized and perfected and picked apart and cited for so long that they now are accepted as the "right way". In essence, this is why UC Berkeley's decision is such a sad one. SICP is a classic, and I would go so far as to state that it is beyond critique, in the sense that it does what it sets out to do to the point of perfection.

You're not going to turn shlubs into Einsteins by forcing students' heads under water next to a calculus textbook.

I've suffered at the hands of "CS is all math" profs. I was in a course that subjected a bunch of CS-101 students to this kind of thing. A whole semester of "Here's a proof that this ten line program sums some numbers correctly."

A collective "Huh?" from the class.

It became crystal clear, after nearly everyone failed the mid-term, that things were not working. The profs held a "come to Jesus" class, where they explained everything; all the proofs, all the ten line programs that added or multiplied numbers, all the assignments full of greek symbols they made us learn. That all became crystal clear, and you could see the lightbulb blink on, just above everyone's head:

/Yup, they're trying to fuck us./

[I survived this course because I wrote my own functional language interpreter, then just typed their damned calculus into it for the programming assignments. What a crock.]

I take a real dim view of teaching "mathematically pure" CS to beginning students. You don't start riding a motorcycle by doing experiments with gryroscopes in a lab; you listen to an instructor, get on the damned thing and learn to ride in a safe environment. Save mathematical purity for after you get 'em hooked.

I've heard: "Oh, but if have them program in BASIC we're doing irreperable harm!"

Horsepucky. I'd rather have an ex-BASIC hacker at my side, helping me ship, than someone who can't write a hundred line program without dragging in declarations that nobody will be able to understand a week later. The best engineers I know weren't hurt by exposure to BASIC, or assembly; they were good at everything.

I guess I'm just a greasemonkey with a keyboard.

[I love Scheme, btw. I don't get functional languages that think it's okay to ditch the programs-as-data paradigm.]

You happily forget (an ever increasing) non-determinism in current (increasingly) parallel hardware.

That way you cannot count only on one CPU executing instructions one by one, you have to leave engineering, you have to do some math. You have to prove the absence of deadlocks, race conditions.