How to Design Programs (2014)
htdp.org
htdp.org
I'm not sure if it's still on the platform, but about a year into my self studying I took a series of courses on edX that used this system. I think it was called Systematic Program Design, but I could be misremembering. Anyways, the courses were incredible. I completely credit them with beginning to turn me from a coder into a software dev. The system they provide just locked into my brain like it had always been there.
I almost didn't take it because it used Racket, and I questioned its general applicability for that reason. I'm so glad I pushed those concerns aside, because in addition to introducing me to software design principles, it introduced me to Lisp in a way that also completely changed my thinking about what programming itself could be.
I've now been a paid dev for 2.5 years. I don't really explicitly use the system from the course in my daily work, but the knowledge contained within it has molded my entire understanding of the field.
The course literally changed my life.
Sometimes the best tools for teaching aren't the tools we need in our day to day work, and that's ok. When you're in learning mode, it's about discovering those foundational blocks upon which all else is built. Those fundamental blocks are never the actual programming language itself.
On the day job, I wish for the level of expression of a different paradigm.
I sigh at the entanglement of information that is presented to my kind.
And when comes the evening, I’m relying on cheap tricks and iterative steps because I’m fried and human.
That’s a bitter sweat thing, that you describe.
It rarely is though.
Once a fundamental understanding of the problem solution is achieved, one can think about refactoring steps like this. Depending on how well one wrote the code, these refactoring steps become easier or more difficult.
I ordered a paperback from lulu and it was a great decision, I use a marker and write on the margins. It is absolutely worth it.
https://www.lulu.com/en/us/shop/nils-m-holm/logic-programmin...
I ordered a paperback at:
https://www.lulu.com/en/us/shop/nils-m-holm/logic-programmin... in-scheme/paperback/product-1z82nmng.html?page=1&pageSize=4
It was absolutely worth it.
Seriously though, they are fun. Racket's way of programming with pictures is great. Maybe following the book at your own pace would be more rewarding.
The two intro courses that use htdp are not nearly as rigorous as the book, you never get to see anything difficult enough to warrant using the design recipes where the book you begin to appreciate that style more and more as it gets harder.
[1] https://www.edx.org/micromasters/ubcx-software-development/
That indeed is the course the top comment is talking about.
The instructor Gregor Kiczales has a youtube channel named 'Systematic Program Design' [2]. His 5 minutes intro video [3] is really good IMO - one can send it to ones relatives or friends who ask you what the heck you are doing in your job.
[2] https://www.youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w
“Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.”
I dream of getting into legal tech and combine my passion for computers with my hard earned law knowledge at some point. But it's just a dream at this stage as I can see no way out.
I was always obsessed with computers since childhhood, I somehow got into law school and faked my way from there.
My problem is taking the plunge to do something else other than law. I try to live day by day and focus on other things besides computers.
But I saw some of the wisdom in the approach when I later tutored the class. People would try to rush into coding problems without doing real analysis of what the cases would be, and had a foggy notion of different parts of program having a "contract". HTDP and the design recipe makes that muscle memory for beginners which is pretty nifty.
Among other things, I learned one of my most memorable quips from him: "Don't put your ego in your code." Basically: don't consider attacks on the quality of your code as attacks on the quality of who you are. Learn, improve, and teach others the same.
He came off as incredibly self-absorbed and at times, borderline hostile. A sibling poster quoted him as saying "don't put your ego in your code", but in the 4+ years I dealt with him, he was nothing but ego.
I don't doubt his intelligence and obviously he's a very accomplished individual, but I just don't see what everyone else saw in him.
Notice the font size of his name, versus the font size of the students who actually wrote the book and everything will be clear to you!
Except that, thank you for that YT link. A critical opinion, when well stated is worth its weight in gold.
How does one increase font size on HN? I feel I deserve a larger font for my username!
How to Design Programs, second edition - https://news.ycombinator.com/item?id=16561815 - March 2018 (30 comments)
How to Design Programs, Second Edition - https://news.ycombinator.com/item?id=14932552 - Aug 2017 (40 comments)
How to Design Programs - https://news.ycombinator.com/item?id=12768134 - Oct 2016 (3 comments)
How to Design Programs, Second Edition - https://news.ycombinator.com/item?id=8778569 - Dec 2014 (39 comments)
How to Design Programs, Second Edition - https://news.ycombinator.com/item?id=6150967 - Aug 2013 (26 comments)
How to Design Programs, Second Edition - https://news.ycombinator.com/item?id=2958108 - Sept 2011 (18 comments)
How to Design Programs: An Introduction to Computing and Programming - https://news.ycombinator.com/item?id=2049477 - Dec 2010 (17 comments)
How to Design Programs - https://news.ycombinator.com/item?id=637152 - June 2009 (4 comments)
This curriculum, along with NUs co-op model, creates some of the most spectacular engineers I've ever had the pleasure to work with. HTDP gives them the tools, and the the co-op gives them the experience. By the time they graduate, they are immediate contributors who are ready to accelerate and grow rapidly during those early years of their career.
While my undergrad experience was exceptionally different (yet equally transformative), if I could recommend a model for teaching software engineering, it would be the structure developed by the folks who created HTDP.
I sometimes feel like I'm crazy when I tell people I wouldn't pick nearly anywhere else for undergrad CS, but time after time when I compare with peers on their experience, this model really is incredibly different and only a few others schools use it (the list is growing, but notable ones being Brown and Waterloo).
If anyone wants a high level overview of the approach, I can't recommend this essay enough: https://felleisen.org/matthias/Thoughts/Developing_Developer...
Also, the comp sci classes were amazing like you said. I started out as a bored business major and took the intro class that used htdp and it immediately changed the course of my life.
The intro CS course I had taught from SICP (but the course was python, & scheme, & sql). I wasn’t so interested. I didn’t read or see the book until months after the course ended, but by then I was hooked.
I’ve never heard of HTDP, I can’t wait to read it.
We need to do this more please.
So I would say, contributions do not seem to be welcome on this topic.
https://github.com/racket/scribble/pull/62
It's pretty clear from this that scribble will never support mobile. I can't remember if I pulled the CSS from this change or if I came up with something myself, but making it work slightly better on my phone at least was a pretty small change, not sure if I have it around still or not.
I saw it was at least a couple of years since HtDP was discussed on HN.
I appreciate its flat footed approach and systematic method. To me, these are hallmarks of professional engineering practice. There's no attempt to make the problems more interesting by adding complexity or affectations. YMMV.
Not that.
You know how Tyson early in his career just walked straight forward and punched?
Like that.
I've talked with people who also see these two sides but call them differently.
As I see it, this book is closer to the algebraists side. Thus, you probably lean closer to the nuemerical side.
I also like to think about it as the Turing perspective (numerical, algorithmic) and the Chruch outlook, which is more algebraic-symbolic.
At the end of the day, it's both "contrasting" viewpoints coming together that truly animates the science of computing.
edit: typo
There's a reason MIT uses Python for its intro courses now, after all.
The pedagogical approach that appeals to individuals tends to align with how they are most comfortable thinking about it.
Further, the obstacles I face when coding are mostly tightly coupled to the fact that I'm programming on physical hardware – again, nothing to do with the theory of computation. Even in a high-level language like Python, if you program the Sieve of Eratosthenes in a naive way without understanding what's going on under the hood with deleting an element from a list, you're going to have a bad time [0].
To caricature SICP-style instruction a bit, I'm imagining someone learning that recursion is useful (Scheme peeps seem to love it) without also being taught it generally has poor performance characteristics.
Perhaps a better criticism is the mostly useless emphasis on immutable data structures. The example I like to bring up is how Haskell for a long time didn't have a readily-available hash table implementation for completely ideological reasons. No, hash maps are strictly worse, thank you.
[0] https://stackoverflow.com/questions/3939660/sieve-of-eratost...
SICP teaches that recursion can have bad performance and how to use it without blowing the stack or wasting time with unnecessary computations. Scheme, the language, requires tail call elimination so compilers will transform tail recursion into something as fast as a conventional loop.
> One reason that the distinction between process and procedure may be confusing is that most implementations of common languages (including Ada, Pascal, and C) are designed in such a way that the interpretation of any recursive procedure consumes an amount of memory that grows with the number of procedure calls, even when the process described is, in principle, iterative. 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. The implementation of Scheme we shall consider in chapter 5 does not share this defect. It will execute an iterative process in constant space, even if the iterative process is described by a recursive procedure. An implementation with this property is called tail-recursive. With a tail-recursive implementation, iteration can be expressed using the ordinary procedure call mechanism, so that special iteration constructs are useful only as syntactic sugar.
This is an example of a point where an algorithms book is helpful + clarifying and SICP is really not. (fake quote: "Be conceptually sloppy and let Scheme take care of it, kid.") It has a few pages on orders of growth, but the coverage is not amazing.
Other popular languages have TCO to varying degrees, like C and C++ when using fairly standard compilers like MSVC, GCC, Clang, or ICC [1]. Destructors do get in the way though sometimes.
Java/JVM doesn't support TCO, but Kotlin and Clojure make do with special syntax to support tail-recursion (i.e. tailrec, recur).
Apparently JavaScriptCore supports TCO for JavaScript [2].
The book makes it sound like TCE is language-specific, but since that book was published, it's spread to many other mainstream languages too.
[1]: https://stackoverflow.com/questions/34125/which-if-any-c-com...
[2]: https://dev.to/rohit/demystifying-tail-call-optimization-5bf...
More importantly, in the listed languages (excepting a handful of compiler optimization options) the semantics of procedure calls are different than Scheme's semantics for procedure calls. So if you, in C, convert a for loop into a tail recursive procedure you have changed the behavior of the program, not just its appearance (and same in reverse). In Scheme or another language with tail call elimination, then this conversion ought not actually change the behavior of your program (done in either direction). This also has the effect of removing the loop constructs as a necessity of the language. You can describe an efficient iterative process in Scheme with tail recursion, but you cannot describe it (in a general sense, same caveat for some optimization options) with tail recursion in the listed procedural languages and must use a special syntax element (their loop constructs) to achieve the same program semantics.
(I could be wrong, I am not an expert in this, my basis are that an open set of function with a call in tail position can be used to describe arbitrary state machines (with the state being the arguments of the tail call and the rules the code of each function) that is open to new functions being added from anywhere. If you want to transform this in an iterative state machine all your functions need to be "registered" and "called" by the state machine.)
Can you link to some evidence that the reasons were completely ideological?
What is MIX/MMIX? Is this something specific to the SICP book?
It hasn't been massively useful to me in my professional life (I'm a data scientist), but it definitely has helped me to gain a deeper appreciation of how computing works.
Yes, and IIRC, that reasons were, roughly: a) Python is more popular, b) Python has better robotics libraries, which is what kids coming to MIT care about these days. Notably, I don't recall the reasons they given having anything to do with giving students a good fundamental understanding.
Then again what do I know, I didn’t go to university remotely in that realm of prestige.