Live data from Hacker News

How to Design Programs (2014)

htdp.org

11–20 of 141 posts

Re: How to Design Programs (2014)

#11

I never understood the appeal of this book.

I never understood the appeal of this, or SICP, or Scheme in general. I learned much more about computer science reading algorithms and data structures textbooks, especially Knuth. There's a reason MIT uses Python for its intro courses now, after all.

SICP for me was the missing link between learning syntax and code to designing actual programs that solve real problems. It made me step back and look at a problem not as something that just needs a layer of code thrown at it, but as a task to complete, with requirements, constraints, etc. to consider before a single line of code is even written.

Re: How to Design Programs (2014)

#12

My undergrad intro class used this. At the time I found it patronizing and silly and artificially limiting, having coded before (the design recipe, the different "levels" of scheme). 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 havin…

Matthias Felleisen was my professor at Rice 2 decades ago and I can still hear his distinctive voice clearly in my head! I too was resistant at first having done some programming in high school, but I wish I could go back and tell myself to pay attention more. Now I know Matthias was both wise and passionate and that combination doesn’t show up in every CS class, so to this day I’m nostalgic for the way he introduced computer science.

Re: How to Design Programs (2014)

#14

My undergrad intro class used this. At the time I found it patronizing and silly and artificially limiting, having coded before (the design recipe, the different "levels" of scheme). 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 havin…

Matthias Felleisen was my professor at Rice 2 decades ago and I can still hear his distinctive voice clearly in my head! I too was resistant at first having done some programming in high school, but I wish I could go back and tell myself to pay attention more. Now I know Matthias was both wise and passionate and that combination doesn’t show up in every CS class, so to this day I’m nostalgic for the way he introduced…

Felleisen taught the first CS class I ever took. I think part of the point of the class was to mess with people who think they know what to do because they've coded before, when in actually they are now on even footing with everyone else. In my position, I was glad for it. Everyone was perfectly intuitive!

Re: How to Design Programs (2014)

#15
Oh wow. I love SICP. I still pick it up every now and then—just for the poetry.

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.

Re: How to Design Programs (2014)

#16

My undergrad intro class used this. At the time I found it patronizing and silly and artificially limiting, having coded before (the design recipe, the different "levels" of scheme). 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 havin…

Matthias Felleisen was my professor at Rice 2 decades ago and I can still hear his distinctive voice clearly in my head! I too was resistant at first having done some programming in high school, but I wish I could go back and tell myself to pay attention more. Now I know Matthias was both wise and passionate and that combination doesn’t show up in every CS class, so to this day I’m nostalgic for the way he introduced…

I was also a student of Prof Felleisen, and his class was both challenging and rewarding if you could stick with it.

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.

Re: How to Design Programs (2014)

#17

I never understood the appeal of this book.

I see two sides: the numericals and the algebraists.

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.

Re: How to Design Programs (2014)

#18

The design and aesthetics of this book template is exemplary. No purple rounded corner bs, huge fonts, excessive negative space, garish colors, etc. We need to do this more please.

I find Scribble [1], Racket's documentation tool to be easily readable and accessible. I wish more projects utilized it.

[1] https://docs.racket-lang.org/scribble/

Post reply on HN