[ldar15]

I'd been programming over 20 years when I read SICP. The book was interesting. It was interesting as an introduction to functional programming. But, in my opinion, a lot of the stuff in it that is held up to be clever or informative is just difficult because the reader is expected to figure out how to to imperative programming in a functional language.

A computer is an imperative device. It is a deterministic state machine. Teaching introductory programming with a functional language is teaching students wrong, i.e. it does them a disservice. This being ycombinator, and given pg's thoughts on the merits of FP, I may not have a popular view. We will just have to agree to disagree.

Once you figure out (i.e. immediately if you have done it before) that computers are imperative, not functional, many of the "truths" or "revelations" in SICP are like "well, duh" or worse, "why the fuck did you make me go to all that effort?"

[microtonal]

A computer is an imperative device. It is a deterministic state machine. Teaching introductory programming with a functional language is teaching students wrong, i.e. it does them a disservice.

One could as easily argue that a computer is a tool, and if it helps us making better (according to some criteria) programs, why not abstract away the underlying architecture?

[ldar15]

why not abstract away the underlying architecture

Because it would not be an abstraction of what is there. It would be the creation of an abstraction of something that isnt there: i.e. a simulation. And indeed, this is exactly the cause of my complaint.

Its like you have a machine that deals with squares. You're suggestion is to "abstract" the system into shapes, but then build a system using circles. A shape is an abstraction of both squares and circles. But a circle is not a square, and squares are what you have. FP languages and Imperative Languages are both specializations of the "programming language". But FP is not a generalization of IP. The computer is an IP machine.

When reading SICP there were several places where I had an uneasy feeling. Something was wrong and I didn't immediately know why. Then it clicked: I'm being asked to make rectilinear geometry out of circles. First time students aren't going to make it past the confusion.

And finally, if we're abstracting away the underlying architecture, why the focus on tail-recursion (an optimization), iteration vs recursion (an optimization), memoization (an optimization)... The complaint of the original article is that the alternative books are "How To Program In Language X", instead of "How to Program". However, SICP is most definitely "How to Program in Scheme".

[4ad]

In my country, we have Computer Science and Computer Engineering. CompSci is done in Science or Math faculties, while CompEng is done in engineering faculties.

CompSci is about abstract theory. It's more related to math then to engineering. To CompSci, computer languages are the building blocks. The fact that those language happen to run on computers is implementation detail. The fact that those computers are imperative is also implementation detail.

I'd say most CompSci students here don't care much about the inner workings of computers.

CompEng students are different. They couldn't care less about functional programming and care a lot about the underlying implementation.

Different people, different interests. I'd keep SICP for CompSci but not for CompEng.

I'll end with a quote: Computer science is no more about computers than astronomy is about telescopes ~Edsger Dijkstra