←back to thread

460 points pieterr | 1 comments | | HN request time: 0.413s | source
Show context
upghost ◴[] No.42160938[source]
Hot take: SICP and SD4F "considered harmful (without counterpoint)"*.

Why? The modus operandi of problem solving in these books is object oriented programming masquerading as functional programming, and it is presented as a _neutral_ beginner book. It is _not neutral_. This is a very opinionated approach to programming.

To be fair, I do not believe the authors intended for this style of programming to be taken as gospel, but it is often presented _without counterpoint_.

The most powerful technique introduced -- implementing complex behavior via extensible polymorphic generics -- is virtually unmaintainable without a compiler-supported static type checker. You would know that if you ever tried to implement the code yourself in a dynamic language of your choice.

The ramifications of these choices can be felt far and wide and are largely unquestioned.

Ironically, they make code hard to understand, hard to extend, and hard to maintain. I need to reiterate, I do not believe the intention of the authors was to suggest these ideas should be used beyond a pedagogical setting, but they often are.

As a specific critique to SD4F, which states as a goal making code more resilient by emulating biology, I would point to Leslie Lamport's talk on logic vs biology[1].

I would add that I think SICP would be fine if it were taught in tandem with Paradigms of Artificial Intelligence Programming by Peter Norvig[2]. PAIP offers a completely different approach to solving problems, also using lisp. This approach is much closer to constructing a language to model a problem and then solving the problem symbolically using the language created. Areas that use OO techniques, such as the chapter in CLOS, are clearly marked as such.

In other words, I say "SICP considered harmful" because thrusting it upon an eager newcomer as a trusted neutral guide to beginner coding (without offering any counterpoint) could set them back by a decade, filling their head with "functional object oriented programming" concepts that don't translate well to industry or CS.

[*]: I say this as someone who has thoroughly studied both books, implemented the code, taken Dave Beazely courses to have the information spoon fed to me (dabeaz is awesome btw, take all his stuff) and used the techniques in production code bases.

[1]: https://lamport.azurewebsites.net/pubs/future-of-computing.p...

[2]: https://github.com/norvig/paip-lisp

replies(2): >>42165652 #>>42170796 #
1. SleepyMyroslav ◴[] No.42165652[source]
I would say that after 20+ years career OO plus functional elements have been a good default. Maybe I missed opportunities where symbolic computations were important and limited myself with languages like C++ that prefer OO/functional approaches... I can't go back and try something else to know =)

I might agree with your hot take in sense that leaving choice is important though.