If not SICP, then what? Maybe HTDP? | Hacker News Reader

If not SICP, then what? Maybe HTDP?

stevenrosenberg.net

336 pointsphilonoist213 comments

"that make me jump through intellectual hoops made of mathematics"

There is actually surprisingly little mathematics in SICP. What is does have are mechanisms that are then analysed and modelled, after which the mental model is adapted so it can be turned into computational model that is a faithful representation.

Some of the presented mechanisms are mathematical in nature, but you don't need a mathematical background any more than you need an economics background to write, say, a banking application.

"make it hard for me to learn the actual programming."

Depends on if you see "actual programming" as the mental discipline of correctly representing a part of the real world into a computational model.

If you see "actual programming" as typing in characters on a screen until they compile, then ship them and get absurd amounts of money for it, then sure, SICP might not be for you.

"without going too deep into the quirks of a single programming language"

SICP is not about scheme, has never been about scheme, will never be about scheme.

You will not emerge a "God of the Lisps" from SICP. It might, however, clue you in about what's actually happening when programming, in any language of choice.

Honestly, there's just a tiny bit too much of real number knowledge required in SICP. I wasn't good enough to really derive newtonian method on my own. For someone looking to develop applications I believe it's completely off the map. HtDP requires no arithmetic from what I recall. Which makes it more focused.

Now SICP was for EE doing software. I suggest to everyone to learn EE, even partially, it's surprisingly useful to learn designing anything. It's still system design, state changes, but in a different substrate, and personally I found it very helpful (gives you a new appreciation for crude language like C).

> I wasn't good enough to really derive newtonian method on my own.

There is an old SMBC comic highlighting this general issue in STEM where for some mysterious reason, mathematical theories that took at least a few scientific generations to figure out, with lots of bitter fighting among the giants of science about which conclusion we should accept as correct, are now being taught as if they are trivial to reproduce and come up with for bachelor students.

As a physics drop-out, I felt really relieved when I read that, in a "oh so it's not just me"-sense

I grew up bothered by this on many levels. Not only some of us feel negatively for the struggle. I believe that ~learning the results teaches less than learning how to solve it. I does accelerate learning and allow people not to reinvent all 4 wheels... but reading old papers (there's a video on Newton's very own notebook, it is so damn different from anything I've ever read about physics) tickles another part of your mind.

> there's a video on Newton's very own notebook, it is so damn different from anything I've ever read about physics

Sounds interesting. Would like to watch it. Got a link?

I think that's this one https://www.youtube.com/watch?v=ObPg3ki9GOI

They don't review all of it, but you can get a few pages read

Similarly, a lot of James Clerk Maxwell's writing can be found on Archive.org, and it's amazing:

https://archive.org/search.php?query=maxwell%2C+james+clerk&...

too easy, last night I went to Gilbert De Magnete (original in latin no less) http://www.gutenberg.org/ebooks/33810?msg=welcome_stranger

You joke (and cool find), but Maxwell's writings one the subject of electromagnetism are indeed a lot easier to grasp than some modern textbooks

I don't doubt it

It's not unusual that original scientific works are more clear than the later works of people trying to explain them.

The original author has to persuade people, and convince people who aren't familiar with them. The "pedagogical" author later is in a more clear position of authority and doesn't need to work as hard.

> The original author has to persuade people, and convince people who aren't familiar with them. The "pedagogical" author later is in a more clear position of authority and doesn't need to work as hard.

Or perhaps: The "pedagogical" author can assume that by the time of his writing, we live in a society where it is accepted that there is nothing mysterious about the material (e.g. imaginary numbers are nothing mysterious) and can concentrate on explaining the material in the best possible way.

The problem is that many students come from a background where they were taught a deeply anti-scientific attitude.

EDIT: To put it more concisely: It is a different job to convince someone of a scientific result (here the other side is distrusting) than to teach it (here the other side gives you credit of trust (but a lack of understanding) and you have to teach them so that they understand it). Unluckily many students who attend lectures have an attitude where they need to be convinced instead of taught.

>Unluckily many students who attend lectures have an attitude where they need to be convinced instead of taught.

Isn't this backwards? If you're just accepting the lecturer's word as dogma, I would argue you're not really gaining an education at all. The process of being convinced and having doubts about the material resolved improves critical thinking and improves understanding of the underlying material as well.

That's how you become the annoying student in the algorithms class who interrupts the professor all the time and ruins the class.

> Isn't this backwards? If you're just accepting the lecturer's word as dogma, I would argue you're not really gaining an education at all. The process of being convinced and having doubts about the material resolved improves critical thinking and improves understanding of the underlying material as well.

Maybe I think differently from you because I come from Germany. But I don't think this is backwards. I openly admit that I cannot stand "critical thinking" gospel.

Before you can start thinking critically, you have to understand the material that is there (that you want to criticize). Explaining the material so that you hopefully understand it is the role of the lecturer/teaching assistent. Why are you enrolled in the degree course if you are critical of it instead of wanting to learn the material? So one can assume that the students want to learn the material.

> Why are you enrolled in the degree course if you are critical of it instead of wanting to learn the material?

Maybe you want to learn why it is true?

Since Euclid, mathematics is about proof i.e. being convinced. If you really understand the material, you see it must be true - and need not blindly accept it.

What is taught in high school and many university courses is not mathematics, but how to use it. Like how to use Word, not how to write Word.

When you understand something, it becomes yours. You remember it longer, and can adjust and generalize it.

Unfortunately, it can be many times as much work to understand some mathematics, even some from early high school, and requires higher mathematics. So you can't understand til after you've understood it... It makes sense mathematics is taught the way it is... especially when most people are users, anyway.

But bad luck for those who need to understand and be convinced, which was so important to the developers of mathematics. i.e. mathematics filters out mathematicians.

> Maybe you want to learn why it is true?

> Since Euclid, mathematics is about proof i.e. being convinced. If you really understand the material, you see it must be true - and need not blindly accept it.

I agree. Learning mathematics means learning the proofs. This is pure learning and has nothing to do with critical thinking (at least to me and I am a mathematician).

Maybe we mean different things by "critical thinking"?

To me, an essential part of a proof is checking that it is correct yourself... as opposed to "learning" it i.e. taking it on faith, believing it is correct because someone said it was. (Of course, in practice you can't verify everything yourself... but nonetheless that's the idea of mathematics, in theory).

Is that not the purest form of critical thinking?

OTOH I suppose when a proof uses a clever change in perspective, to show that it must be true (such as non-constructive proofs), it refutes many possible objections without ezplicitly considering them. So formulating those objections (or "criticisms") isn't needed.

> (at least to me and I am a mathematician)

Please keep in mind that you therefore have an inevitable non-zero amount of survivor bias there, and may have some trouble seeing why everyone else had trouble with the material.

The lectures of the old 4 semesters of calculus at UT Austin consisted almost entirely of the proofs of why the material worked.

Less than entirely helpful if you wanted to use it.

And probably doesn't understand all that was required to see and prove the theory. Making his message narrower.

So that’s where Google- and all of the tech companies aping Google- got their interviewing style from.

Hah! I do wonder if it isn't simply human nature though, something we actively have to unlearn.

Google is made up of high test achievers who move on to decide how to test applicants. Its self perpetuating in that casez not human nature

I got the same feeling when taking timed tests in some of the more proof heavy CS classes.

In a lot of ways it felt like solving crossword puzzles for a grade with a timer ticking down. Frequently I'd spend the most of the test with no idea what to do, and then about 20 minutes before time was up, I'd have an insight and I'd spend the last 15 minutes furiously racing to write it all down.

This worked out well and I ended up with a 4.0 program GPA, but I was a wreck every test day--I was always convinced that this was the day I'd fail to have that last minute epiphany.

I was always looking for a more systematic approach, but I never found one. In the end I still don't know if the problem was me or the tests.

Is this[0] what you were thinking of?

[0] https://www.smbc-comics.com/comic/how-math-works

Yes, thank you!

Invention and comprehension through Socratic guidance are different tasks, with wildly different levels of difficulty. It's just not accurate to pretend that students are expected to "come up with" these theories in anywhere close to the way that (eg) Newton did.

Correct, but perhaps not in the way you are thinking.

Newton was something else, but still: he had acquired a vast amount of knowledge and insight upon which he built his new theorems.

Meanwhile, experts are notoriously good at forgetting what it is like to not understand something yet, so when explaining things they subconsciously presume more a priori knowledge than is appropriate.

This comic is brilliant!

I ended up being a programmer but I graduated with an Electrical Engineering degree.

What's interesting is that I generally don't recall fundamental physics or applied coursed having this attitude, i.e. nobody expects students to understand theories without proper context set up. Physics is generally taught from experiments.

I believe math is mostly guilty here :-) For some reason most of school math is taught as a bunch of soulless abstract sybmol manipulation. No proofs, no reasoning, pure memory-based excersises.

Then you come to a university and they just go on. Proofs-proofs-proofs, but with the same mechanical approach. No motivation, no context, just endless calculus variation.

Yes, this really showed how much information I can put into my memory. But I only started to get math many years and books later.

The first chapter of SICP is entirely relying on mathematical examples because data structures are not introduced before the second chapter. The book expect the reader to have a solid base in calculus.

This comment reads like a very partisan, overstated puff piece in defence of the book.

The Scheme aspect of SICP, and other decisions made by the authors, matter a lot because, contrary to what you seem to be claiming, there are many different approaches to and flavours of programming. There isn't a single core philosophy that, once imparted to students, "clues them in" to the essence of the cultures/styles/models deployed by Forth, Haskell, APL, Prologue, C etc.

Of course these decisions matter, but not in the way you mean. The biggest hurdle to learning programming is not the syntax, not even when you're starting out with C++. It's learning to think like a programmer.

One needs to learn how to take apart a problem and put it back together again in a way the computer understands - to get rid of all the ambiguities and phrase the solution in terms of conditionals and loops. When one starts to deal with bigger problems, one needs to learn the use of abstraction in order to deal with the added complexity.

This is the skill that makes somebody a real programmer, and it stays pretty much the same across languages. The differences between OOP, FP and all the rest pale in comparison to that first great lesson that needs to be learnt. (Having started off with Java, learning Lisp was a huge step for me that I really struggled with at first. But it still wasn't anywhere near as difficult as learning programming for the very first time.)

This is the skill that SICP tries to teach.

I do not understand the "domain knowledge" complaints.

So far I have found that the Wizard Book always provides the required algorithm, or enough discussion to work it out.

I agree with everything you say. Just want to add that SICP had a context: it was designed to be an introductory computer science course designed for university engineering students (including CS), almost all of whom take calulus in their first year, if not earlier. This was probably a valid assumption back in the day, but clearly there is a more diverse audience now.

Anyway, I absolutely agree SICP was never about Scheme per se, or even functional programming. Scheme is nice as a teaching tool because, as Sussman likes to say, you can teach everything you need students to know about the language in one lecture. (Not even all of Scheme, mind you, just what you'd use in a 1-semester course, which back when I took 6.001 meant R4RS minus macros and continuations.) There's certainly always been pressure to use more "practical" languages. But back in those days, there weren't the options there are now. Any derivative of C, especially C++, would end up being as much about the language as about programming concepts, if not more.

I think the thing about SICP is that while it makes some minimum demands about mathematical background, it makes a lot of demands about intellectual maturity. It took me years to appreciate many of the points it makes -- as I got more experience, different parts of the book start to resonate. On the other hand it's stayed relevant all these years, at least for me personally.

Well said.

I'm reading the book now (and watching the lectures), and can't imagine trying to go through it as an undergrad.

Indeed, the context reflects the origins of CS departments. They are always were part of physics school and later electrical engineering.

All the famous CS people over say 60 started in physics or EE.

This might be true in America but in Europe it is common for the CS department to have been an offshoot of the mathematics department.

In the US you find both. More commonly CS came from electrical engineering, but you do find some departments that started as part of mathematics. In any case, as other commenters said, early "computer scientists" often came from physics, math, electrical engineering, etc. (Abelson & Sussman themselves had PhDs in mathematics.)

> almost all of whom take calulus in their first year,

What? How can anyone do any meaningful engineering without calculus?

SICP is not about scheme, has never been about scheme, will never be about scheme.

It strikes me that when someone says that, and my GSI said something very similar to that in section, it means that the book+course has failed to say what it is about, clearly, in a way the student will understand rather than misunderstand.

It's f'ing ineffable is not a good thing.

From the preface to the first edition:

> we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs...

The whole preface talks about how the aim of the book is to get students to think with a programmer's mindset. Scheme is only incidentally the language the consider best for the task, due to its near-absence of syntax.

https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

I think programmers reaction to the mathematics in SICP is completely hysterical - in the sense of hysteria, not comedy. For example, the author-professors who wrote HTDP, quoted at length in this article complain about using 'complex domain knowledge' and the author of the blog post does as well, but the running example used is literally arithmetic. In particular:

Section 2.1 starts by building a data type of rational numbers, then extends it to interval arithmetic In section 2.4 this is extended to Complex numbers, which also adds the complication of multiple representations of a data type (rectangular vs polar). In section 2.5 these are unified with a generic arithmetic package. Which is finally extended to operate on symbolic polynomials, creating a symbolic algebra system.

So you can see, the authors complain about 'domain knowledge', but the example was surely chosen precisely because everyone already understands these relationships so well! It's a relatively nontrivial example, technically simple but structurally complex, that everyone already understands intuitively, so that you can get right to work thinking about data abstraction techniques - and in this example we go all the way from introducing the notion of an 'abstraction barrier' for the first time, to data-directed programming & message passing!

-----

The other mathematical section is 2.3, which is the infamous calculus section. Again the reaction is completely over the top - there's no 'deep dive', you don't need a 'solid foundation' in calculus, etc. The appearance of calculus is no more than implementing a couple of symbolic transformations of data, and all 4 of the rules are provided for you. You don't actually use calculus to do anything, so that if you don't know calculus, you can still write the program, it'll just be a bit more boring not knowing what it means. This section of the book is like 5 pages long, out of a 500 page book, but it's all we hear about...

"already understands these relationships so well"

Is that true for complex numbers?

Perhaps the thing people potentially already understand well is the arithmetic?

Complex numbers as 'cyclic numbers' is not widely understood. What is understood is how they fit into the arithmetic 'hierarchy': how the real numbers embed into the real axis, and how the operational rules for addition and multiplication work. However SICP also asks us to implement the polar form of C to illustrate multiple representations of the same data type, so I have to admit that part might require some additional explanation for many students.

I agree. Currently working through the book in Javascript [1], and there isn't a crazy amount of math.

Newton's method in the first chapter was a little rough for me, but after that it's much more about exploring ways of representing data. (At least so far... I'm almost through chapter 2).

1. https://github.com/ahuth/sicp

For me it wasn't the maths in SICP, it was the physics, or rather the particular examples in the chosen domain.

I love physics but coding Newton-Raphson does not engage me.

(I had a similar reaction to particular Python book -- Roman numeral conversion? blah!)

The motivation for using that example in particular is, I believe, that it's computing a fixed point - which is an idea that came up several times in the course in increasingly general settings. First you do the concrete example of newton's method, then do a more general fixed-point (higher order) function, and a more general newton's method.

Later on the Y-combinator is presented as computing the fixed point of an (finite) iteratively defined function - the fixed point returned is the full recursive function. Lastly when talking about programming languages, and interpreter computes a fixed point. The scheme language is the fixed point of the scheme meta-circular evaluator.

OK, that's interesting. I should go back to it.

But it would be good to hint about it's relationship to later material.

Perhaps it's the timing/context; I had an very odd lecturer for numerical methods.

The first genralization is in section 1.3.3 and 1.3.4

https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

Unfortunately I couldn't find the material about interpreters - my memory of it is them discussing it in the lectures so perhaps it never actually made it in the book, or was only in the 1st edition. Those lectures are available on youtube if you want to find it.

I basically disagree. In my opinion, the main mathematical requirement of the book is not knowing how to add fractions and such, but a reasonable amount of mathematical maturity, and many people reading the book will not have this.

When I say mathematical maturity, I mean the kind of basic “real” mathematics that is normally taught only at universities, specifically the idea of what a proof is, what one looks like, how to write one, how to read definitions, and some idea of how one might analyse a problem and work towards its solution.

For example, exercise 1.10 defines the Ackerman function and asks some questions about it. The Ackerman function does not fit the model of any function one might typically encounter in mathematics before this course, it’s definition is hard to reason about, and solving the exercise requires understanding certain cases of the Ackerman function (and not trying to figure it out all at once) and also having a good understanding of various mathematical operations (e.g. +, *, ^, which seems simple but spotting the pattern might not be so easy).

Exercise 1.13 is about proving a closed form for fib(n) which requires a reasonable amount of mathematics and no programming whatsoever. Thankfully the hint gives one some kind of clue as to how to solve it or I think many would find the mathematical bar too high.

Immediately following this is a chapter introducing orders of growth (big-O and friends) which is fine for anyone with a decent background in mathematics or computer science but one must remember that there is a difference between the abstract manipulation of symbols and vague graph-sketching one does in school (e.g. e^x is flat and then shoots up a bit past 0, x^2 shoots up either side of zero, x^3 goes up on the right and down on the left ...) and having a good understanding of how these functions behave and compare.

Exercise 1.19 essentially requires a careful and correct analysis of the Fibonacci sequence (thankfully there are lots of hints) to derive a logarithmic algorithm for computing fib(n). This is essentially the “matrix exponentiation method” except that the matrix is hidden in three variables. I think it is silly to say that all you need is to be able to understand arithmetic to solve these.

I think the book is fine for a course that happens after (or possibly concurrently with) a first course in real mathematics. It is probably less useful if one is lacking in the mathematical background required, and I think it is reasonable for people studying a “first course in computer science” to not have this mathematical background.

Everyone on here is very excited about HTDP. You are mostly very smart people, and not representative of the typical CS student starting off. Many of you are driven and have rich STEM backgrounds that you draw upon. Therefore, I want to point out that there is no substantial evidence to prove most of the claims of "success" that the HTDP community claims, with regards to novice learners. There are certainly people who HTDP works amazingly for - I have met many brilliant folks who it resonates with. But I have met far more students who it does not work well for (I would describe them as having almost low-key PTSD from their CS1). The curriculum is too artificial and disjoint from the rest of their CS degree. I have met instructors who make it work fabulously, and their students apparently really buy into it. But overall, the claims that HTDP leads to better students is not proven by any literature I can find.

The closest thing I can find for good evidence is Fisler '14 [1], which did indeed suggest that HTDP teaches Functional Decomposition in such a way that CS1 students are better able to tackle short-but-complex problems by the end of their CS1. I find this work compelling, and I look forward to applying the ideas inherent to my own courses. However, in the decade-plus that HTDP has been around, I have not been able to find any long term studies that back up the slew of claims made about how we "should" teach CS1. Language and paradigm arguments in general have not really born out any evidence[2].

I'm not saying HTDP is bad or Python is good or C++ is ideal. I'm saying we don't know much about any of this stuff. Relying on theoretical arguments is dangerous when it comes to pedagogy. For every positive experience you can share about HTDP, I can share a negative experience. It's great if you found a curriculum that works for you. But be very, very careful about whether you believe that curriculum should work for everyone.

[1] https://dl.acm.org/citation.cfm?id=2632346

[2] https://www.researchgate.net/publication/329544316_Introduct...

> you believe that curriculum should work for everyone.

Maybe it would be possible to determine which teaching approach works best for a student and individualize/personalize, rather than having a one-size-fits-all curriculum for everyone?

The curriculum is too artificial and disjoint from the rest of their CS degree.

That was my takeaway from CS61A at Berkeley. I thought that Scheme was incredibly elegant and I was disappointed that we never used it again. The profs sure were pleased with themselves at the end of CS61A and I imagined later that they thought their preferred outcome would have been that we pursued a PhD using Jikes. SICP was the text which everyone bought and no one (that I knew) read and I tried. We had no assigned readings; it simply meant to be worshiped. It comes up on HN but never in conversation. No one quotes SICP.

I'll look at HTDP.

As I remember it, the book SICP itself wasn't really the core of CS61A... the lectures and slides were, and they drew off the concepts in SICP. No one read the book, but we learned from the (fairly good) lectures and explanations of the concepts, and especially the projects of course.

Those concepts were and remain a foundation for how I think about programming—at the level of elegant structure and short modular thinking. Software engineering and architecture is something different, and has its own class (CS169) which was far more valuable and important for those skills at that higher level.

I dunno. It was a good foundation. I've looked through SICP and I still recognize the concepts, the lectures matched it fairly well. But you're right—no one read the book.

Are you guys talking about an older iteration of 61A? It doesn’t really make sense to read SICP nowadays if the course is taught in Python.

Must be, I'm pretty old. :) Would have been 61A circa 2002.

I quote "programs must be written for people to read, and only incidentally for machines to execute" fairly often to students, which is from the 1st ed preface.

That just shows that's as far as people get in the book!

I binged the whole thing on a long bus trip once. Didn't implement much of it, but enjoyed the read.

I will say that the people who develop HTDP are the some of the people who spend the most time writing about pedagogy in computing education. Felleisen in particularly has written a lot on the subject: http://www.ccs.neu.edu/home/matthias/Thoughts/Developing_Dev...

> The curriculum is too artificial and disjoint from the rest of their CS degree

I would then argue the problem is the rest of the CS degree. Whether HTDP "works" or not, the principles espoused in the course are the same ones you'll encounter over and over again throughout your professional career. As far as I can tell, the only difference is the HTDP (and SICP) folks are introduced to them from day one while others learn through years of experience. And this is the problem about the CS101 course "working for everyone": does it work because you're only delaying the introduction to the difficult concepts endemic to software development? If a student can pass CS101 just by virtue of being able to string together a compilable C++ program, is that really for the best?

Anecdotally, I got a 2 on the CS AP test, which was enough to make me second-guess my major. Luckily, I went to an HTDP school where the professor assured me not to worry about it -- and sure enough, I aced the CS101 course and went on to have a successful career writing code.

> I will say that the people who develop HTDP are the some of the people who spend the most time writing about pedagogy in computing education.

I don't think that's really true. Yes, the HTDP community, and Felleisen in particular, write a lot about Pedagogy. But Mark and Mike have them beat handily. Thinking about the CS Ed blogs I read[1], I don't think any HTDP folks have that much compared to others.

[1] https://acbart.github.io/2018/06/25/cs-ed-blogs/

Hm. Not entirely sure what to think.

I find SICP to be a mind-blowing book - a truly enlightening experience. But not, perhaps, entirely suited for beginners. I first started reading it four years ago, just over two years after I had started to teach myself programming in high school. Although I already found it interesting and its functional programming approach did have a lasting impact on my programming style, I recall finding it somewhat too challenging on the whole and didn't get very far. Half a year ago I started it again and have been blown away by the elegance and fundamental importance of the concepts it presents (although I'm still not done yet). For one thing, I understand the foundation of OOP a lot better now than I ever did from reading Java books...

So if the author is saying that SICP is a bad programming textbook because it doesn't include a "How to build a webapp in 12 easy steps", well, he rather missed the point. But if he is arguing that it perhaps isn't the most suitable textbook for a first year CS student fresh out of high school - that is a fair criticism.

I agree, I started reading SICP a few years ago when I was already a professional dev. I enjoyed it quite a lot, it's a very elegant book.

That being said if I try to put myself back in 16 yo old me learning to code to write games for my calculator, I would've been incredibly frustrated by this book. The insights on the nature of programing constructs would've flown completely over my head and at the same time it wouldn't have given me the practical information I needed to get things done.

It is useful to consider the audience the book was written for: first-year students at MIT in the 1980s. That was a formidably bright and meticulously prepared group. Many of them already had some programming experience from high school.

It's not too surprising that a book tailored to such a crowd's particular needs is not particularly suited to other students, whether less bright, less prepared, or simply true beginners to programming.

Agreed. Fashion and perspective change with time, and the approach taken in SICP doesn't match up well with the cognitive impedence of 18 year olds today, some 40 years after the book was written.

Then, PCs were not yet integrated in university teaching. It was still common for students to sketch out new software in pseudocode on paper before sitting down at a terminal they'd waited hours to get access to. And of course, editors were crude, IDEs nonexistent, and the compile-run-edit cycle often took 15 minutes or longer.

Programming was more deliberate, involving absolutely no cutting and pasteing. Coding then was much closer to writing a proof, which goes a long way to explaining why SICP put more emphasis in principles, formality, and derivation than we do today.

> "Many of them already had some programming experience from high school."

Supposedly those that did found SICP to be more challenging than those who didn't.

I agree. I think the quoted professor-authors' point in the quoted passages is to make a book like SICP, designed to teach deeply rooted computer science concepts more approachable to beginners without going to the extreme of "How to build a webapp in 12 days". I support the effort, as I think it's a bummer that the choice as a beginner is often between a too-difficult SICP and overly abstract and non-theory-based tutorials.

    They may even come to the conclusion that programming is a
    shallow activity and that what truly matters is an
    understanding of domain knowledge

THE HORROR ;)

In all seriousness, IMO we'd have much better programs if developers spent more time thinking about domain knowledge and less time believing that "programming" in isolation is the important part.

Domain knowledge vs. programming "in isolation" is a false dichotomy. Indeed, the programmer's business is to think about the domain in terms of computer science in the programming language of choice. It is sometimes a very complicated translation process, and the complexities do not necessarily come from the domain per se but often from requirements concerning the target platform, efficiency, precision, user interface, etc. At the end of the day, that is what turns out to be the "important part," and those who fail to realize that early in the process are usually bound to suffer some unpleasant consequences.

The "important part" is that the code solves the end user's problem while creating the minimum possible amount of new problems for them. Everything else is an implementation detail. Everything else that we hold so dear about computer science is only important insofar as it solves someone's problem.

It's an old and long tired adage that the "pure" knowledge, especially mathematics, is only "important insofar as it solves someone's problem." This is wrong on at least two accounts. First, the pure mathematics, for example, like art, is interesting, valuable, and perfectly happy to exist for its own reasons and does not need any permission from anyone to do so; second, it has not been a secret that the pure knowledge routinely turns out to be tremendously useful at some point - even if centuries later.

It's not just about solving the end user's problem, it's about anticipating future problems and features. If all code was write-and-forget you'd be right, but in general you have to maintain and upgrade codebases over a rather long timespan. That's where "implementation details" matter a whole lot.

"The amateur, then, is learning about his problem, and any learning about programming he does may be a nice frill or may be a nasty impediment to him. The professional, conversely, is learning about his profession—programming—and the problem being programmed is only one incidental step in his process of development.

"The other side of this observation is that the professional never quite takes any problem as seriously as does the amateur. He has had bugs before, and he will have them again. This difference in attitude is a source of constant friction between the two types: the professional is very tired and a bit irritated by the unending stream of amateurs waving their printouts in his face and condemning the machine, the operator, the system, the keypuncher, the language, or the government. The amateur, on the other hand, can see that the professional does not even care that his means and standard deviations are not going to be ready in time for inclusion in the proceedings of the conference."

Gerald M. Weinberg, The Psychology of Computer Programming.

http://www.pacifier.com/~mmead/cs162/professional.html

We need both. Not enough domain knowledge and you end up with software that isn’t a great fit for what it’s trying to do, but without enough computer science and software engineering knowledge and we end up with all of these stupidly memory-and-cpu-hungry applications that are all the rage these days.

Clearly. If people want code written by people with a lot of domain knowledge but not a lot of software engineering experience, look at the code written by electronic engineers who just need to write a little software (typically for microcontrollers) to interact with the hardware, the true focus of their craft.

Some of the most horrendous, fragile, unmaintainable spaghetti code I've seen in my life was written by electronic engineers. And some of them were true masters of their crafts, it's not like they lacked the cognitive abilities to write good code, it's just that they didn't care at all, it just had to accomplish the function they needed. Meanwhile I'd see them spending a lot of time making sure things were routed nicely and PCBs looked nice.

That’s a great example! Unfortunately.

As is scientific code.

I came here to comment on this. Its probably actually true :)

As a software engineer, I find HtDP awesome. As a teacher, I found it lacking. I think the best way to teach programming is in the context of a domain of interest to the student. Problem is, you can't write an universally usable book like that.

A central principle in HtDP is how to represent information (the domain) as data in a systematic way. The whole point of it's approach, as I understand it, is in fact to teach a domain-neutral approach, where what dictates data and function structure is the information's structure.

I find that, as a rule, general programming proficiency and (worse still) language proficiency are given too much weight compared to domain knowledge, but it’s most definitely possible to overshoot and end up thinking those core skills are unimportant.

Yes, but I think that extends well beyond coding to include half or more of the UG CS curriculum. The rose of object-oriented groupthink is most pronounced among CS graduates, to the general detriment of the software dev world.

I learned the downside to domain ignorance early in my career when a engineering manager confided to me, “It's eadier to teach an engineer to code, than teach a computer scientist engineering.” The same applies to biology, medicine, chemistry, culture, and many other domains where mastery of context is difficult yet essential.

And I've found those turn out to be the most interesting software jobs.

There are two models for CS education. One model is for students who want to learn the theories of computer science and be computer scientists, and the other is for students who want to be programmers.

SICP is the foundation for people who want to be computer scientists. That’s not everyone.

But from what I’ve found, all the top CS schools create computer scientists, and the other CS schools create programmers. While it’s easy for a computer scientist to make the jump to programmer with just a little guidance, it’s much harder to go the other way.

The world mostly needs programmers though, with just a reletively few computer scientists to come up with the new innovations. So it seems like everything is working out ok.

Although I’m really glad I got to learn the fundamentals of computer science with a SICP based intro class.

> While it’s easy for a computer scientist to make the jump to programmer with just a little guidance, it’s much harder to go the other way.

I don't think it's actually that easy for a computer "scientist" to unlearn all the idealistic stuff that can actually be counter-productive in a real-world programming environment, particularly if they're enamored with languages like LISP or Haskell. These people easily get depressed in a "real" programming job.

Whether it's hard to go the other way doesn't really matter. There's no pressure to go the other way. The only healthy place for computer scientist types is academia, or maybe certain R&D positions. These are few and far between.

Because people get depressed when they can't program in their favorite language? Frankly, ridiculous. A job is a job and the main question is whether you can do it or not.

Yes, this is why initial salaries from MIT, Stanford, and Berkeley are comparatively low.

Rust is becoming very popular. What is Rust though, if not a strict (i.e., non-lazy) Haskell with different syntax, linear types, and less polymorphism? I think a CS type who loves Haskell will be right at home with Rust. Or modern C++. Just as a CS type who loves Lisp will also be able to make the move to Rust or modern C++. Java, maybe not so much :)

If anything it’s ocaml.

> Rust is becoming very popular.

For actual jobs? I don't see any evidence for that.

IMHO, Rust is a cleaned-up, simplified, modern C++.

This is one of the major advantages of computer science over many other sciences: an undergraduate degree in CS is actually useful.

Old joke: What do you call someone with a BS in archaeology?

A ditch digger.

It's always interesting seeing the textbooks that are renowned by professors/people with prior knowledge, yet disliked by actual students. The Feynman Lectures on Physics is a pretty famous example (iirc, the actual course was received pretty negatively by students).

I wonder how many people have actually sat down with a bunch of students and done a real experiment with textbooks. It's quite easy to think that a textbook is good when you already understand the material. Only by getting feedback from real students can you truly figure out whether a textbook is good. It'd be interesting to do a course with two different textbooks and the exact same professor and compare feedback/results. Perhaps they could even take the same final exam. Preferably at an average university. One problem with using textbooks written by MIT professors (such as Artin, Strang, etc.) is that MIT students are far stronger than average and can generally skip certain elided steps that other students cannot.

> MIT students are far stronger than average and can generally skip certain elided steps that other students cannot.

They are stronger at what?

Either they know things already or they don't. If they know things already then they can skip steps and if not then they can't or can use guesswork. And that's what any other human being will do.

They are stronger at thinking -- higher IQ for pattern matching, problem solving, and creativity. Better ability to remember something after just one or few exposures, and recognize it when it is hinted at indirectly. Better ability to visualize without being given illustrations. More able and willing to spend time and paper on working out missing details. Any or all of the above.

Source citing any or all of above properties?

http://www.prepscholar.com/sat/s/colleges/MIT-SAT-scores-GPA

(First google result, I didn’t verify further)

It is admittedly only a proxy, but the entrance SAT math scores for MIT students are 770 for the 25th percentile and 800 at the 75th percentile.

Put another way: the test that is a helpful differentiator of intellectual ability of the general college population is not a good differentiator for the MIT population because a large proportion max out the scale.

Raven's progressive matrices and similar are differentiator of intellectual ability. SAT scores correspond to time spent on chair doing homework.

Wow! You really need sources to prove to yourself that MIT students are smarter on average than a typical first-year student chosen at random from any University or Community College in the US?

Not in my experience. I've met numerous MIT grads, and invariably they're smarter than the average grad from a less demanding school. Obviously that also applies to Caltech, Chicago, most Ivies, etc. But part of that equation is that the MIT alum learned not only how to survive that greater workload, but they learned more because of it. So they have a head start on several counts.

> They are stronger at what?

Lifting heavy books, of course.

You are absolutely right that there is a tendency for people to respond to a recommendation request with a book that is too much for the requester, and I've sometimes thought may have been too hard for the answerer on their first time through the material. I see that on /r/math, for instance, it seems to me. (That phenomenon needs a name.)

That said though, let me say that for me personally SICP was mind-opening. I think about it a lot; it has had a major influence on me. An example is that I am working on a Theory of Computation book and I am trying to emulate some aspects of it (while keeping the presentation accessible). I certainly will admit, though, that when I read it I expect that I was in a different place than the post's author or than the typical student.

I watched the SICP lectures after a few years as a java developer and absolutely loved them.

I also remember doing a course on functional programming (SML) when studying that did absolutely nothing for me.

You’re probably correct, you need to have mastered the mechanics of programming before having the brain capacity and experience to appreciate the finer details and subtleties of the craft.

I had a similar experience with karate training. When siting on the bench and watching my son train it looks rather straight forward, just remember to focus. Then after a term I decided to join the training and suddenly it feels like you have five arms to coordinate, and processing any verbal input from the sensei is just out of the question.

> Only by getting feedback from real students can you truly figure out whether a textbook is good.

The problem is (also in my experience) that students often cannot grasp the depth of the textbook/topic when they here the lecture. I openly admit that I only could appreciate the depth of the topics taught in some math lectures 5-10 years later (but already at the time that I heard them, I loved hard lectures - in oppposite to many classmaters).

So if you want to get feedback, ask the students not before 5 to 10 years after they heard the lecture - otherwise the answers will in my opinion be meaningless.

My Physics III prof: “I won’t lecture from the book. I wrote the book. I know what’s in the book. It is your job to read the book.”

Worst book ever. Ugh.

Academia is double Dunning-Kruger. Most students don't know what they don't know about the topic, and most professors don't know what they don't know about teaching it.

It's amazing anyone gets out alive.

An accidental double blind leading the blind study.

> people with prior knowledge, yet disliked by actual students

This is the key!. I was about to say SICP was great then, yeah, I read it only when get interest in build compilers and after 20 years on the craft.

I think you need a progression on material:

1- Start with a highly practical book more alike build little experiments/programs

"Build a pacgam game" "Make a calculator", etc... ie, do a single pass for the minimal amount of info necessary to build a practical yet rewarding project.

2- Now the student have accomplished their first success, slowdown a little and put a small amount of theory here and there, but put focus on:

"Discipline and follow good practices" then re-do the projects right this time.

To build a analytic mindset move to:

3- How a computer think, using debuggers, disassembles, etc.

You get your hands dirty and see the magic behind the magic

And at the final step (is necessary to put some more steps before, just wanna get to the point):

4- Finish with a well round, deep and wide treaty about the field like SICP, so with some practique behind you can actually see what you have done and how it relate to the new info you are getting now.

Also, this will broad your horizons and open the appetite to get in the deep more.

----

I think is to be like how is learn to cook. You start doing simple yet good dishes, without worry to learn first the theory. You move to more challenge, learn techniques tools and tricks of the trade. Finally, move to see the theory behind, round your mental framework and challenge yourself in come with exotic, new dishes...

That’s very well put. I’ve actually really wanted a “cookbook” for compilers. Basically small, self contained lessons for writing a particular part of a compiler. I.e. here’s how to write a typechecker, or how to write a garbage collector. The closest to that I’ve found is Crafting Interpreters. A lot of the compilers textbooks focus on the theory or general concepts, which is great, but I want to get my hands dirty. I’m not reading the book to learn the theory of compilers; I’m reading to book to write a compiler.

I agree for the cookbook. I'm building a lang I have scavenged so much info from so many places, but all is kind of disconnected. Or worse, all stop at generate the AST, and barely interpret the AST at the level of a calculator and maybe simple functions.

For example, I need like 5 different sources to finally have a grasp in how pattern match, and build a solution that later found in another paper.

There is a great paper by Abdulaziz Ghuloum, An Incremental Approach to Compiler Construction, that is pretty much the cookbook you want: http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

"We show that building a compiler can be as easy as building an interpreter. The compiler we construct accepts a large subset of the Scheme programming language and produces assembly code for the Intel x86 architecture, the dominant architecture of personal computing. The development of the compiler is broken into many small incremental steps. Every step yields a fully working compiler for a progressively expanding subset of Scheme. Every compiler step produces real assembly code that can be assembled then executed directly by the hardware."

There is also a work-in-progress effort to write a more extensive textbook that follows the same approach to teaching compiler development, using Racket instead of R5RS Scheme: https://github.com/IUCompilerCourse/Essentials-of-Compilatio...

I was recommended that paper by someone else. Just need to get around to reading it :)

The main roadblock I'm having right now is typechecking. I've implemented Hindley Milner in Haskell and played around with Turnstile, but I still don't know enough theory to invent my own type rules for an imperative language. Something like "Type Theory for the Working Programmer" would be excellent. I just got a copy of TaPL, so maybe I'll just use that.

This made me think about how I learned to program on the Commodore 64: By typing in listings from magazines on little games, like Snake or a little text adventure game etc. When teaching kids I think that could be a great method: Usually, kids are also not afraid to start experimenting and tweaking what they typed in, while perhaps adults lack the patience needed to just copy an example.

Now that I typed that out, I guess the thing about trying to come up with the one perfect teaching method is that students vary so widely in what experiences they bring to the table. There just isn't one method that could possibly work for everyone.

I was thinking of making a product like that. Essentially it'd be like a typing program such as Mavis Beacon in that you'd have a snippet of code that you'd have to type out in its entirety, after which, you'd be asked to tweak it in some fashion. Not sure if it'd be effective, but worth a shot.

Knuth's math textbook has commentary from his students in the margins. Some of it is hilarious.

The Feynman Lectures on Physics is an amazing second book for each course. The usual combination in my university for a Physics course for a degree in Physics is

* The "main" book of the subject

* The Landau book about it

* The relevant chapters of The Feynman Lectures on Physics

* The Shaum's Outline book about it.

The idea is that you study from the main book, and use the Landau book as an auxiliary short version with only the important points. The Shaum book has a lot of exercises. [Some people don't like to recommend Shaum's book.]

After that, you can read the relevant chapters of the Feynman book. It's like a book with fairy tales for physicist [or physicist students] that you read before going to bed. Each chapter is amazing and you enjoy it a lot, but it is very difficult to study using it as the first read about the topic. It's very useful to have a deep understanding of a few difficult key topics, after you are familiar with the subject and the mathematical part.

[I really grok the difference between phase velocity and group velocity reading the Feynman. The definition of each velocity is easy so it's not so difficult to pass the exam, but understanding what they really mean took me a few years.]

I can fully recommend HtDP for beginning programming - tried various options for my 11 year old. I needed it to involve very little help from me - tried some scratch, mit50x, both which helped but did not spark and sustain interest.

Then we came across https://www.edx.org/course/how-code-simple-data-ubcx-htc1x - love it and does not need any help from me :) planning to move on to https://www.edx.org/course/how-code-complex-data-ubcx-htc2x after that!

edit: corrected typos

> we came across

There are YouTube videos (I don't know how well they fit with the current course) and they are excellent.

+1 to learning programming thingies from YouTube videos.

Do you mean the online HarvardX CS50 course? I started it when MOOCs were first appearing, and it includes Scratch. It looked very enthusiastic and buzz-worthy to me (which can be very good for a lot of people). However, past students doing a music and dance routine on stage about how exciting it had been, and the first lectures concluding with announcements of pizza parties with Facebook recruiters was too much for me, in that I felt too old.

Alternatively, the MITx 6.002 course on Computational Thinking is also for undergraduate students, but it had a greater focus on programming being integral to the sciences and other fields. I don't recall the the curriculum exactly, but even though the course is an introductory one I think some of the concepts might be a little daunting for a young teenager.

In addition to the UBC courses, another introductory treatment that won't overwhelm to a committed young learner is the DartmouthX C Programming with Linux. One of the instructors, Petra Bonfert-Taylor, taught a very accessible introductory complex analysis course on Coursera, and seems especially interested in first experiences students have with topics so that they are not discouraged. She has written a number of articles on teaching an introductions to new subjects.

my bad - yes, I meant the Harvard CS50 course. Thanks for MITx 6.002 and DartmouthX C Programming with Linux - The DarmouthX one would be a good second course if the interest still continues.

The audience that SICP was written for seems to be basically a younger, roughly freshman-year Gerry Sussman, with all the advantages and disadvantages that entails.

I haven't done HtDP yet. I love The Little Schemer http://www.ccs.neu.edu/home/matthias/BTLS/ , but I can't recommend it unequivocally, mainly because I've found (somewhat to my surprise) that it's not accessible to all programming beginners without quite a lot of extra in-person tuition. (And I'm talking about the early chapters here, not chs. 7-10 or chs. 8-10.)

The book is written for freshmen at MIT, not your average high school grad. You're expected to have a solid foundation in calculus to get admitted to MIT.

This is what everyone seems to be forgetting.

Was that true in the early '80s, when SICP was presumably developed (it was first published in 1985).

I know that at Caltech in the early '80s, a majority of incoming students had not had calculus in high school. I would expect MIT to be similar.

6.001 was a second semester course, all incoming students had already completed a semester in undergrad calc and physics.

http://www.gigamonkeys.com/code-quarterly/2011/hal-abelson/ "There’s a tremendous amount (of math) in this 6.001 book. That’s partly because we were writing it for MIT. You want to talk about higher-order procedures, so the obvious thing you can do is you can express the idea of an integral. So that’s an obstacle for lots of places. Remember, at MIT the context we were writing in is every person who took the course had just had a semester of calculus.

We actually did some versions for the Humanities faculty, where we didn’t do that at all, and we effectively started with the data structure chapter and then talked about the ideas for how do you structure and manipulate data, and then do abstractions over that."

HtDP is similar to their other version, starting with data. Author of that book has a good talk about creating a compsci curriculum https://youtu.be/5c0BvOlR5gs

I think anyone reading the book with a determination to drop their intuitions in favor of the book's concepts will find it much easier going, and tremendously worthwhile.

I get why readers don't do that. There is very little written so well that it deserves that trust. Generally we have to step back from something and ask "what does that mean? how do I reframe that into something I can understand?" Because the material's models are too poorly thought out to be useful or too poorly communicated to be discovered. Trying to adopt such models is futile.

But for me, SICP is one of those rare books where I am better off trying to absorb its frameworks, rather than constantly trying to reframe the material into something I understand.

When I step back and _think_ the way the book suggests, the problems solve very quickly. When I try to get a solution from some combination of my intuitions and known tricks, I thrash about endlessly.

It is a very carefully written presentation of profound and important ideas, and deserves to be approached differently than the vast majority of books.

Both SICP and HTDP are very good books. SICP has little more 'attitude' in it, but I think its neutral feature. If you want to learn programming as something between algorithms and programming languages, I suggest these four 'Lisp' books:

1. SICP (Structure and Interpretation of Computer Programs)

2. HTDP (How to Design Programs) https://htdp.org

3. LiSP (Lisp in Small Pieces),

4. PAIP (Paradigms of Artificial Intelligence Programming) https://github.com/norvig/paip-lisp

SICP and HTDP are different but serve the same purpose. LiSP is about interpretation, semantics, and compilation. PAIP by Peter Norvig can seen as elementary programming book that uses classical AI as a subject. You learn both.

I don't know what to think about this, I haven't read it: SICM (Structure and Interpretation of Classical Mechanics)

Which among these teach me functional paradigm through LISP the best? Or would you recommend some other book that uses a small language to gain a good grip over FP? Haskell, Scala and Clojure are intimidatingly big.

HtDP or none of them.

Functional paradigm has two flavors:

1. Functions as first class objects in the language and enabling the functional style programming.

2. Pure functional programming. Not a style, its functional programming.

IMHO learning the first kind helps relatively little when you want to learn second kind and vice versa.

Lisp is multi-paradigm language or "Lisp paradigm" language family. Because functions are first class objects it facilitate functional programming of the first kind. Some Lisps are geared towards using functional style more than others.

So for second flavor, what would you recommend with focus on smallness of language?

I have no idea.

I have only read Thompson's Haskell: The Craft of Functional Programming and some old ML books I can't name. I have no idea if it's a good compared to other FP books.

You were very helpful in this discussion. Thank you. :)

For Clojure - a good start might be something like solving a few of the advent of code puzzles with the simple but powerful map/reduce functions. You won’t need the whole language and you will be writing functional programs.

The experience of that alone might help you find the next book that works for you.

There are several more books. For example:

https://www.goodreads.com/book/show/1032517.The_Schematics_O...

Also in that league, but using a different language Mozart/Oz:

https://www.info.ucl.ac.be/~pvr/book.html

German: Schreibe Dein Programm

http://www.deinprogramm.de/sdp/

I have found that the best way of learning the HtDP approach to program design, at least for me (I find the book itself a bit dry), are the EdX "How to Code" free moocs [1] [2]. The instructor is fantastic. It completely changed the way I program and design.

If you like the approach and want to learn more, like, for instance, how to extend it to OO design, I list below links to several courses (most, except for the last one, offer enough material to complete them on your own, but I couldn't find any videos) at the university where HtDP's main author, Matthias Felleisen, is tenured (North Eastern). The courses are listed in the order in which they should be taken, and the rationale is explained by the professor in the paper "Developing Developers" [3]:

* CS 2500 - Fundamentals I [https://course.ccs.neu.edu/cs2500/]

* CS 2510 - Fundamentals II - Introduction to Class-based Program Design [https://course.ccs.neu.edu/cs2510/index.html]

* CS 2800 - Logic and Computation [https://course.ccs.neu.edu/cs2800/index.html]

* CS 3500 - Object Oriented Design - Spring 2018 (scaling up the 3 previous courses) [https://course.ccs.neu.edu/cs3500/]

* CS 4500 - Software Development [http://www.ccs.neu.edu/home/matthias/4500-f18/index.html]

[1] https://www.edx.org/course/how-code-simple-data-ubcx-htc1x

[2] https://www.edx.org/course/how-code-complex-data-ubcx-htc2x

[3] http://felleisen.org/matthias/Thoughts/Developing_Developers...

I happen to best learn through video lectures more than reading.

Thank you for your effort. I am starting with these.

Could try both, the book (HtDP) is more rigorous than those two MOOCs as they're meant just as an intro where you progress into many more courses (as part of the micromasters on software development) while the book is a full grounding in CS 101. Somebody correct me if wrong but I don't remember any big-O analysis in the MOOCs or the parsing XML chapter, traversing graphs, the content on fixed-size arithmetic, plus the 500 or so exercises the book has compared to the three or four at end of each unit in the MOOCs. For example the sierpinski triangle assignment in the MOOC is pretty straightforward, but in the book you also generate a fractal savannah tree using trigonometry functions that isn't so straight forward, but when you see how they do the generative steps in the book you get that 'eureka' moment learning about Bézier curves. https://jeremykun.com/2013/05/11/bezier-curves-and-picasso/

Agreed. But I would still recommend those interested to start with the online courses. The reason is that they hammer in the core principles that underlie all of systematic program design, with plenty of hand holding and exercises, and spending the right amount of time on each new concept, which is a lot harder with the book alone. The instructor is so good that in 10 mins one will understand what would otherwise take more than one hour with the book, at least in my case. After completing the moocs one will have a rock solid foundation from which to tackle more ambitious problems, including the ones you mentioned. Only then would I open the book.

> If not SICP, then what? Maybe HTDP?

I can recommend "Concepts, Techniques, and Models of Computer Programming" (CTM or CTMCP).

Book's page: https://www.info.ucl.ac.be/~pvr/book.html

Quote from www.c2.com:

"Like SiCp, CTMCP is first and foremost a book on programming, not on Oz or Scheme or anything else. And if SiCp is the reigning king of such books, CTM is a worthy challenger to that particular throne."

I found CTM a harder book to read than SICP for some reason, so if the author finds SICP too much, then they probably won’t like CTM. I personally thought SICP and CTM were both great books.

Speaking of CTM, it's a little unfortunate that the modernization of Oz's implementation as Mozart is progressing very slowly.

On https://teachyourselfcs.com/ CTM is recommended if you find SICP too easy

CTM isn't an intro to program design concepts. It's a survey of programming language concepts, which presumes more knowledge of programming techniques and problem modeling and formal CS theory than a CS1 course should.

I much prefer CTM to SICP. It's my reference for most programming related concepts, and I find it a very entertaining read. It is a wonderful intellectual journey, which I suspect would appeal more to ambitious programmers who want a deep understanding rather than to those just interested in pragmatic knowledge. No hip frameworks here, plenty of timeless concepts with all the context you need to choose which are suitable when, and that underlie all present and future frameworks.

I haven't read HTDP and can't authoritatively comment on it /have no idea how it compares to SICP, but I found this statement pretty ridiculous:

> While SICP (yes, everybody uses the acronym) is considered a holy grail for serious computer scientists, it's hella hard to figure out. For me, programming "methods" that make me jump through intellectual hoops made of mathematics make it hard for me to learn the actual /programming/.

I started learning how to program in high school using whatever resources I could find (my school didn't have any programming courses beyond an introduction to 1980s BASIC, so independent study was the only option), initially following the very nuts and bolts-oriented instruction in C++ Primer Plus (I arbitrarily chose this as a good intro textbook based on my limited understanding of what constituted 'real' programming versus BASIC). I spent the better part of of 2 years making unremarkable C++ programs that were little more than basic math and control flow mashed together with the C++ standard input/output libraries.

At some point, I happened upon SICP, and learned more about computer science and programming in six weeks than I had in all of my previous self-study. I hold that it was, and still is, a remarkably succinct and understandable introduction to the fundamental concepts that underlie computer science. Yes, math was involved, but I didn't need to learn anything beyond my basic high school algebra education to understand how that math translated into programs: SICP did an excellent job of explaining how programming related to that math. Most importantly, it was /fun/: working through SICP made me feel like I was learning a new way of thinking, not just learning how to translate something I already knew into computer language.

Other descriptions of HTDP suggest that it combines my painful slog through the nuts and bolts of programming (albeit more succinctly and less painfully) with SICP's math/CS elements, so it's probably a better textbook for tackling both at once. However, it's crucial that it does both: to focus only on "actual programming" as the author suggests is probably a surefire recipe to convince students that computer science is a dull field consisting solely of writing instructions for computers, with no thought whatsoever into what instructions make sense or why.

So you had two years of prior experience with languages like C++ before starting on SICP. That makes for a very different experience than a first introduction to programming.

HtDP is about systematic program design, not just coding; after reading it one will know how to start any new program, no more staring at a blank screen.

A couple of historical clarifications to Sedgewick Wayne's points:

> [SICP] set the curriculum for "beginning" computer science

> All [examples and exercises] use complex domain knowledge. ... Some early sections and the last two chapters cover topics from computer science ...

Why the square quotes around "beginning"? At the time the course, 6.001, was launched it was quite reasonable to assume that an MIT undergrad might arrive at the Institute never having previously used a computer, much less programmed one. This was truly an introductory class and while required for all EE and CS students, was intended for any undergraduate. The material in the examples all covered core subjects every student needs in oder to graduate, or else were computer science topics that should hardly shock someone taking a computer science class.

Some of the other criticism is reasonable in light of the authors' desire for a slightly different approach. 6.001 was and is the basic introductory class and a CS student will take other classes which will address different aspects of program design and application. Choosing a different time of introduction for different objectives is hardly unreasonable.

(And I don't know why object-oriented programming is somehow thought to be in opposition to the principles of SCIP; the latter's heart is abstraction and composition which are the whole point of object-oriented thinking, right?)

All very interesting, but what do Sedgewick and Wayne have to do with any of this? Your first quote is from the post's author (Steven Rosenberg says the site header), and the second quote is from the authors of How To Design Programs (Felleisen, Findler, Flatt, Krishnamurthi).

Thanks for catching that. Unfortunately it’s too late for me to edit my misattributions.

I recommend "Concepts, Techniques and Models of Computer Programming" Van Roy and Haridi. While SICP is an enlightening read, much of what it discussed, looked to be methods that do not all mesh together into one overarching discipline or "science" of programming, which is what CTM aims to do(But admittedly it is a much harder book, and I am still only in the very early chapters). Important questions like how programming in the large is different from programming in the small, how some methods scale and how some do not, topics like these aren't perhaps handled by either of the books, if my memory serves right.

I think it's worth pointing out why the author's of SICP themselves acknowledge why it was phased out.

Praphrasing, it essentially boils down to the kind of applications developpers of today are writing. People are now mostly slinging libraries they have a superficial understanding of together in a black-box style. So for most proprammers there's a lot of prodding and tinkering and this isn't a skill that SICP teaches.

disclaimer: I don't think I've imagined reading this however didn't bother looking for the reference.

If your CS degree aims to churn out programmers ready for industry, then a overview of the currently favoured libraries is indeed what you need to teach. If on the other hand, you want to produce actual computer scientists who know how to think for themselves, the SICP is what you're looking for. (And I would hope that an institution like MIT would choose the latter focus for its program.)

I tend to think the goal of a CS education is to form computer scientists. It's just that a lot of people (and articles) think it's about churning out programmers for the industry.

With such a mismatch of expectations, the resulting frustration on both sides is not surprising...

I like the German system: We have university CS courses, which tend to be more theoretical, but also universities of applied sciences as well vocational training in IT for the more practical approach.

I had a hallway conversation with Sussman a few years ago and asked him why SICP was phased out, and the above is exactly what he said in reply. He was not at all happy about the fact that many if not most engineers nowadays were being taught "tinkertoy" or "erector-set" engineering (pretty sure he said one of those words literally) rather than the fundamentals that would allow them to write their own libraries instead of hooking together libraries built by others and being adrift when they didn't work.

> I think it's worth pointing out why the author's of SICP themselves acknowledge why it was phased out.

Gerald Sussman made some remarks about this during an unrelated roundtable discussion at the 2009 International Lisp Conference:

https://cemerick.com/2009/03/24/why-mit-now-uses-python-inst...

Note that Sussman did not actually state why the committee decided to change the curriculum. The remarks about studying software empirically were his opinion. I was in the audience, and while Sussman seemed sincere in his remarks, I still have a hard time believing he was serious. How can anyone state, without irony or sarcasm, that we should just give up, and start treating software programs, where all the "laws" are not only known, but made up, by us, as if they were natural systems, where our only way to understand them was to start "poking" (I may be wrong, but from what I remember this was the actual word Sussman used) at it and observing the results?

If you give up before you have even started on modularity, composition, etc., and start treating every program as if it was a million line COBOL hairball, the hairball part is just going to be a self-fulfilling prophecy.

My takeaway from Sussman's remarks was the opposite of his message - the ideas about applying mathematical principles to software design in SICP have become even more relevant as a way to prevent software hairballs.

I make good money doing the "poking," but if you are going to teach that, stop pretending that you are teaching a science at the university level - this kind of shrug-and-give-up empirical programming is to computer science and engineering what a trade college auto mechanic education is to a mechanical engineering degree.

During my time as a student I felt that the computer science department should have been split into two disticnt programs. The first program should have existed in the math department dealing with the theory and mathematics of computation. The other should have been in the engineering school and focused more on actual computers. Hardware, software, operating systems, working in a team, designing large systems, etc. I think I would have gotten much more out of that. Instead it seems many universities created “CS lite” programs in their business schools.

Do you realize how much mathematics goes on in the average engineering program?

Warning, anecdotes ahead:

I tried to read SICP after about 6 months to a year after learning my first language, and I couldn't get past the part where they turn a recursive function into a tail-call eliminated 'iterator' style recursive function. I understood what was going on, but I just couldn't grasp how to generalize it. Of course, I get it now; you just pass an extra variable in and use it like you would the `i` var in a for loop, but at the time I just couldn't grasp it.

I also had similar struggles with the early use of math problems as examples and other vaguely described algorithms.

Granted, my background is in Music, so I didn't have the domain knowledge that the author mentions, but programming is more about strategic and logical thinking, so I was perfectly able to do that even at an early stage.

I think MIT is right to think SICP is too much for a freshman. Hell, I was already graduated and applying for grad-school when I tried to read SICP and I still struggled.

Brown University has a textbook and course called Programming and Programming Languages (PAPL) which is based on Pyret, their teaching language that combines concepts from Python and Scheme/SICP for teaching code and data abstraction.

Freely available here: https://papl.cs.brown.edu/2018/

More on the Pyret language here: https://www.pyret.org

I'll add that some people from HTDP went onto create Pyret as a new experiment in education:

https://www.pyret.org/

It's used in the Bootstrap program that teaches it to middle schoolers. Probably pretty easy to learn.

I didn't find SICP good or bad, but utterly boring. In fact, so boring that I couldn't bring myself to finish even half of it in 3 separate tries.

Perhaps I should've read it as my first programming book, but that time's long past.

Anyone else had this problem? I'd gladly take tips on how to get over it, since I do honor classics and don't think I'm above them.

You're not alone. I forced myself to read through half the book before asking myself what was the point of solving essentially leetcode style problems using only tail-end recursion and glorified linked lists. At no point did I ever feel that the scheme language had any practical applications.

People are completely missing the point, even though this article includes the important quote.

In a 4-year Computer Science curriculum, SICP is not a perfect fit for the role it was being asked to play. HTDP was written with the goal of being a better fit in that specific role.

If you are self-taught or otherwise learning in a non-4-year CS program, this distinction is not applicable to you. SICP is great. HTDP is great. They are both great.

When I started my Bachelor in Italy (Bologna) I had actually not enrolled yet to the degree, and I was instead following both Computer Science and Philosphy. My plan was to continue both of them, or to choose one. We had this first year programming course taught by a fairly younger teacher (39), Ms Busi: I was expecting not much from it because I thought it would be an introductory course on programming OOP stuff with Java, things that I had done fairly extensively during the high school program. Hower, on the first day, she explained us that we were going to use a language called "Scheme" and that our reference book was going to be freeily available (in general, courses in Italy often require expensive books - sometimes ones that you won't find on the internet since they are written by exactly your little-known professor and will be available in selected book shops of the city), the book was "How to Design Programs". She said that one of the goals of this choice was also to decrease the difference in levels between students: we would use a language nobody knew, and approach a paradigm that nobody knew, and this would have made her (interactive) lessons and the lab practice more interesting. I also remember how she said "the organization of this course is going to be simple: every day, you will come and I will write down a problem on the whiteboard, and we will find a solution. Then, we will find a better, more beautiful solution, and that's it". I could see she knew that this choice was going to upset people, so much that she tried to sweeten the pill by saying "this is how they teach programming at MIT".

Indeed, the course did upset people. I remember how people constantly complained how shitty this decision was, how "people in the 1st year engineering classes are doing real Java programming while we do this shit no employer asks for", some noted how the language was stupid, or in the best case just a toy, useless in "the real world". Thing got worse when some people realized that, contrary to their expectations, they did not know how to program, since they could not do eg. graph traversals once that was stripped of its OOP or Java-like envelope - "I will fail the year because of the bloody scheme!", they would say.

To me, instead, it was revelatory. We did indeed solve one problem per week, and although the problems were less sexy than the ones I was expecting (finding the max of a list is not the coolest thing in the world), promises were kept, and little by little I started appreciating how much you could express with so few lines or predefined functions, leveraging only on very few concepts (eg. recursion), it was different from the programming we had done in high school. It was also a big difference with the university classes of philosphy, where "assistant professors" (underpaid PhD [students]) will come to read you a book AND a comment to it, with very little intellectual work needed from either them or students. I quickly decided to follow only Computer Science. I became no black belt lisper or anything, but that style of programming, of looking at problems, software and the whole field certainly influenced me. I am currently enjoying my role at a FAANG company, and thinking about all of this made me want to write her an email to thank her, but the saddest thing is that I can't do it because right at the end of that academic year, Ms Busi actually died, unexpectedly, at the age of only 39. First year student of CS in Bologna now learn Python programming.

(this is her uni page if you are curious: http://www.cs.unibo.it/~busi/)

This is a beautiful story. I am sorry for your loss.

"Indeed, the course did upset people. I remember how people constantly complained how shitty this decision was, how "people in the 1st year engineering classes are doing real Java programming while we do this shit no employer asks for", some noted how the language was stupid, or in the best case just a toy, useless in "the real world". Thing got worse when some people realized that, contrary to their expectations, they did not know how to program, since they could not do eg. graph traversals once that was stripped of its OOP or Java-like envelope - "I will fail the year because of the bloody scheme!", they would say."

This is a perennial problem with computer science programs everywhere. The irony is that the department will have employers banging on the doors trying to hire graduates while the students complain no one will hire them because they're wasting their time on "toys"; no one seems to notice the relationship.

Hopefully, the problem will go away with the removal of things like SICP and the introduction of Python as you mention.

Thank you for sharing this story. I’m sorry to hear about professor Busi.

My introduction to computer science was also HtDP and your experience mirrors mine exactly. The people who were the most upset about it were people with exposure to Java and C from high school. Now that I’m in industry, I find I have a better grasp on things like recursion compared to many of my colleagues.

This edition is an amazing improvement on the original ebook: https://sicpebook.wordpress.com/

What mathematics? Now that many states have legalized cannabis, SICP should be read while high in the middle of the night. Its nonstop commentary is profoundly amusing. I love for example the passage that presents tail-recursion as the natural form of iteration, and notes about other languages:

"As a consequence, these languages can describe iterative processes only by resorting to special-purpose “looping constructs” such as do, repeat, until, for, and while."

Of course they're right, and yes that's a mathematical view, but they put it so well. All replacement texts are unreadably dry.

This quote makes my head hurt:

> "Instead of teaching some currently fashionable programming language" [...] > "The approach emphasizes the systematic design of programs. Experience shows that it works extremely well as a preparation for a course on object-oriented programming."

As someone who gradually transitioned from "object-oriented programming" (or "place-oriented programming in general") with mutable data into largely functional systems with immutable data structures, I find this quote mind-boggling, especially coming from educators.

Moving to functional programming and immutable data structures is what allowed me to build and maintain systems at least an order of magnitude larger than before.

SICP is not just a book. They are lectures you can freely watch on the Internet.

For me is one of the most interesting lectures I ever watched. Requires effort because it makes you think, and this is one of the great things about it.

Not for beginners? Yeah, like structural engineering, physics, biology,chemistry, writing, or anything worth something in life you need to work on it, have interest and abilities doing that if you want to become a professional.

Some people want to make University so easy that the title becomes worthless, like happened with University titles inflation in the UK.

Working through SICP my main issue was the almost unbounded time commitment- like it will take you between a month to two years. I remember there was a trivial problem that took 5 minutes then apropos nothing the next problem bascially required you to invent the concept of numbers as functions in lambda calculus and required a two day diversion just to understand the answer. Even the best programmers I’ve known who’ve done it have said its been a multi month process and without a teacher its so easy to get bogged down.

This last week I took an in-person class where we covered almost all of the book: https://dabeaz.com/SICP.html

The instructor David Beazley very skillfully weeded out all the non-essential parts and added one amazing exercise where we implemented the lambda calculus and, funny enough, the ycombinator.

Highly recommend it for anyone who desires to learn this material, can't find the time, and is willing to pay $2500 for the experience.

link broken, gets 404

Try this. It works: https://dabeaz.com

Or this: https://dabeaz.com/sicp.html

The links seems to be dead and $2500 makes me think the link is better off dead. Haha! On serious note, I'd like to read some materials from his side.

Link is caps-sensitive -- needs to be https://dabeaz.com/sicp.html

People who worked through HtDP: what are your impressions?

I worked through it some years ago because I was interested in Racket. It is solid when it comes to programming, but if your goal is to get the Scheme feeling, the little Schemer would be a much better choice.

BTW a very nice introduction to Racket is also "Realm of Racket".

I liked it. My least favorite part wasn't the book itself but rather DrRacket. DrRacket's not bad, in fact it has some slick features, but I don't consider it great either. As an IDE it's good, but as a text editor it's poor. But then again my brain has been poisoned by Vim, DrRacket is probably great for young students without preexisting biases like mine.

I've been using racket for almost all of my recreational programming for the past few years but I don't do it with DrRacket.

I will agree with you that any programming language that has the editor locked-in (thinking Mathematica) is simply not worth it's salt.

You’re free to use Racket with any editor. DrRacket is just one IDE that you can use that is geared towards learners.

Isn't HTDP very DrRacket oriented though?

My first, first year CS course [1] was based on HTDP and used DrRacket extensively. I, on the other hand, did all my assignments in Emacs. Worked completely fine for me.

[1] https://www.student.cs.uwaterloo.ca/~cs135/

Only worked through a part of it, but left a pretty good impression. Writing style was pleasant to read, sometimes imagined it read in Bob Ross' voice. Only Scratch has a shorter "zero to moving pictures" time. The language manual is so tightly integrated with the book it doesn't leave a single character of code unexplained (I've read beginner's books that never explained "+=" while using it in code samples). My only nitpick is that the design recipe wasn't sufficiently explained and it finally clicked when I tried the edx course based on the first part of HtDP, which has its own problems like a plodding pace and unchallenging excercises. All in all a great beginner's book.

Could you please link me the EDX course site? I am not able to find it. Coursera scrapped it's 2015 version

Seems to be a newer version of what I did, so my gripes might be fixed. https://www.edx.org/course/how-code-simple-data-ubcx-htc1x

1) it's near paradigm agnostic

2) it does not lie, gives a very nice structured way to think about data and processing it through simple cases (product and sum types without naming them)

3) it's quite small step read, nothing as extraordinary as SICP

It's the best book I've found for actually teaching people how to solve problems using programming, rather than just learning semantics.

I use it for continuing education at a company, the only complaint I've heard from people is that it's very deliberately paced.

I do wish there was an equivalent that used a statically typed language, because the actual approach is very fundamentally based on types. I've spoken with the authors about this, and the reasoning was twofold: 1. people are going to have to deal with unityped languages in industry; 2. existing error messages for static languages were bad. At this point, something like Elm might be a good fit, although you'd lose out on lispy things like quasiquote.

> I do wish there was an equivalent that used a statically typed language

Not exactly an equivalent, but a very good book (that uses a statically typed language) is "Elements of ML Programming" by Ullmann.

Yeah, that's a good book, but as you noted it falls under teaching a language, not so much teaching how to think.

I am working through HtDP now. I was initially watching Gregor Kiczales' accompanying playlists[0] on YouTube concurrent with the material. They were good and short enough that I charged through and finished them before reaching the corresponding material in the book.

I think the biggest win is that it's the first source I've found that incrementally teaches a pragmatic understanding of recursion[1]. But also why it works, with the structure of the code following the structure of the data definitions and downward. The videos classify natural, mutual, structural, and generative recursions and explain the who/why/what/etc of each. Gregor's video explanations were great, and the book similarly seems to anticipate many questions I have while working through the problems. At times, parts have been slow, probably due to some prior knowledge[2], but definitely worth the trek.

The first time I learned recursion was basically a "now draw the rest of the owl" trope. I was hoping for so much more in way of explanation and have always felt incapable whenever struggling to approach and solve recursive problems. And questions always just led to non-didactic Inception movie references.

I used to think maybe I was just bad at that type of problem. And maybe I am, but more and more, it feels like people generally - including those teaching - don't actually know the concepts here themselves. It's like the world has just collectively memorized a few examples and refuses to acknowledge the giant spaces between them.

In that sense HtDP has been incredibly refreshing.

[0] https://www.youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w They are the videos that go with the edx course mentioned elsewhere here.

[1] Although I've heard The [Little|Reasoned|etc.] [Schemer|Lisper] books may do similarly.

[2] I'm in my last semester of a CS degree and I have work experience programming

The book is great, I've been working through HTDP and it's generous amount of programming exercises casually over the past year as a self learner. I had been dabbling in programming over the past several years (as a true dilettante) and have utilized several resources on my journey (CS50, Programming: Principles and Practice Using C++, a touch of SICP), but it wasn't until progressing through HTDP that I really felt confident I was learning HOW to program. The pedagogy the book uses instruct a beginner on how to program is sound and uses many of the concepts touched upon by the popular "Learning How to Learn" edX course. The natural progression of the exercises as well as the evolution of the language used throughout the book(BSL or Basic Student Language) pair nicely and you slowly feel yourself becoming "wizardly" as the training wheels are slowly being stripped away.

The authors do a good great job in promoting good software craftsmanship from the very beginning of the text. Like any good teachers they reinforce the importance of developing good habits that as a beginner you sometimes take for granted, such as writing unit tests for newly defined functions. Thinking through programming exercises is done methodically with HTDPs Design Recipe, which enforces the use a function signature, purpose statement (comments), a header, and functional examples - followed by a template to flesh out the basic structure of the code you will be using to define your function.

I've watched most of the SICP lectures by Sussman and Abelson and while brilliant, it becomes quite clear that even the professional programmers in the room have trouble keeping up with the pace of the lectures. As a beginner, I was acutely aware that I had bitten off more than I could chew and I will revisit them and SICP after completion of HTDP.

As a side note, I discovered small typo in one of the examples and emailed the lead author (Matthias Felleisen) and he responded to me same day very appreciative that I took the time to do so. If he or any of the other authors read this, thank you! I'm still diligently making my way through and enjoying your text!

I'll just mention https://composingprograms.com a take on sicp mostly in python. A bit of scheme is used in the latter half for doing meta circular evaluator.

Another great but lesser known CS book is "The Functional Approach to Programming". It uses Caml (a predecessor of OCaml). Like SICP, it covers a wide range of CS topics, although it's probably not as accessible as HtDP.

While this topic is being discussed, what books do folks like for Data Structures and Algorithms?

And importantly, can you contrast why you chose the one you like over others you’ve worked through?

> If not SICP, then what? Maybe HTDP?

TAoCP should be enough for anybody

Or too much for anyone.

Now if the author is bummed by the "mathematics" of SICP he sure will have himself handled pretty roughly by TAoCP :)

disclaimer: I haven't read SICP but as others have pointed out I doubt there's any significant math in it. I presume the author was referring to a heavy dose of informal reasoning.

Not really the same thing, SICP is about the practice of programming and the effects of abstraction. TAOCP is more like a recipe book of algorithms.

So the answer is, one needs both.

I suppose it depends on what people are trying to learn. Programming and computer science are very different things.

If I try to access this site I get:

"Access denied. Your IP address is blacklisted. If you feel this is in error please contact your hosting provider's abuse department."

It could be my VPN, but still, not nice.

I'm the author of the original blog post, and I wanted to say that SICP, as well as HtDP, and even a book like Robert Sedgewick's Computer Science (https://www.amazon.com/Computer-Science-Interdisciplinary-Ro...) are in a completely different category than more mainstream how-to-program books (like anything from O'Reilly, Manning, No Starch, Pragmatic Programmers) and even the other popular college texts like Y. Daniel Liang's Introduction to Java Programming and Data Structures (https://www.amazon.com/Introduction-Programming-Structures-C...) or the book in my intro class, Tony Gaddis' Starting Out with C++: Early Objects (https://www.amazon.com/Starting-Out-Early-Objects-9th/dp/013...).

Supposedly all of these books assume (or at least allow for) no background in programming, but I think the reality is that taking SICP or even HtDP into the intro class at a non-elite university or a community college would be a complete non-starter and/or abject failure.

What I'm trying to say is that there is a place for both of these approaches: A deep look into computer science, and the nuts and bolts of basic "get it done" programming.

Should both of these things happen in a single class, or series of classes? I think the answer is yes. But how to do that and not leave non-elite students back on the road is another matter.

I believe that the HtDP authors think that the "domain-specific knowledge" required of SICP was a barrier.

And I also understand how advanced CS students think that a class focused on how to manipulate strings, use loops, deal with variables of various types, and work with basic logic in the context of a specific computer language is NOT computer science.

But in my view, most students -- and all average students -- need to crawl quite a way, then walk, before they can run.

Even Sedgewick's Computer Science, which focuses on Java and has a wealth of great questions/assignments all along the way, could really be a barrier to students who aren't steeped in math and science. I learned some math while going through the book, but I didn't learn so much programming. Liang's approach might be too basic for someone who has already done years and years of programming but is way more approachable for those who have not.

My guess is that many professors tried SICP and had a very poor rate of success. I fully support a selective class that says, "this is very hard, but you will learn a lot and look at the world in a different way, and if you really want to understand computer science, this is the class for you."

But there also needs to be more of a gateway class for future programmers (not necessarily graduate-school-bound CS majors) that eases them into the world of writing code. Offering the basics and sneaking in some CS seems better than doing it the other way around.

In a way, it's like the difference between carpentry and architecture. You can teach people who want to build houses how to design them, but at some point they're going to have to get out a saw, hammer and nails and make something happen.

Thank you for this much more nuanced response. Your original post was very critical of SICP in a way that didn't seem to do it justice - I think that's what set of much of the debate in this thread. But if what you say in this comment is what you really meant, I fully agree with it.

I am writing from the perspective of someone who isn't a CS major and is trying to learn programming on my own. I am very interested in the CS aspects of programming but am finding it hard to learn it in an approachable and understandable way.

If an "ivory tower" approach is working, I'm on board, but I bet more people get value out of SICP after they have a lot of classes and experience under their belt and not the other way around.

Books like SICP are touted -- if not by the authors, then by those who got a lot out of them -- as the one true key to knowledge. I think we all gravitate toward that ideal, and we want one book to teach us everything, but reality is often more complicated, and one person's steak is another person's ... not steak.

On htdp.org: https://htdp.org/2018-01-06/Book/part_prologue.html

"If programming were just about numbers and arithmetic, it would be as boring as mathematics."

What's wrong with this author?

"Just kidding: mathematics is a fascinating subject, but you won’t need much of it for now."

Thanks. It's on a sidebar and I didn't see that. Still, I don't think that's good humour.

From an AI point of view, all subjects are the camouflage of mathematics. If a person with good math thinking and boredom can learn many subjects as quickly as possible.

Reply on news.ycombinator.com