Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Design Programs (2014)

htdp.org

Post reply on HN
Print view View original

131–140 of 141 posts

Re: How to Design Programs (2014)

#131

Post by ralphc »

grey4228 wrote: post #123
hackermailman wrote: post #111

Earlier quoted context omitted.

I believe op is talking about the entire sequence where after those 2 you learn java and typescript. I also took the entire sequence the java one was really good at explaining aliasing problems, how to figure out an existing codebase by yourself, and all taught by UBC profs. 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…

The two courses of your parent comment are 2 out of 6 courses of this program [1]. It mentions Java and Typescript. It seems like all 6 can be taken for free if you click the individual links. Is this what you took? [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 D…

Kiczales also wrote the Common Lisp classic "The Art of the Meta-Object Protocol"

Re: How to Design Programs (2014)

#132

Post by jimhefferon »

tjr wrote: post #37
naringas wrote: post #17

Earlier quoted context omitted.

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 "c…

Some people prefer not to commingle the functional, lambda-calculus part of a language with the parts that do side effects. It seems they believe in the separation of Church and state. --Guy Steele

Thank you. One of the funniest things I've ever read.

Re: How to Design Programs (2014)

#133

Post by agumonkey »

lanstin wrote: post #117
agumonkey wrote: post #86

Earlier quoted context omitted.

The whole series is very high grade. I don't appreciate the dialogue format all the time (too fine grained and a bit distracting after the first book). But high density of knowledge here.

Seriously these are not quick reads. If you don’t feel your conceptual space expanding every few pages you are surely missing something.

I came to them long into my lisp/scheme journey. So maybe it made me impatient.

Re: How to Design Programs (2014)

#134

Post by ralphc »

TeMPOraL wrote: post #88
spekcular wrote: post #4

Earlier quoted context omitted.

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.

> There's a reason MIT uses Python for its intro courses now, after all. 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.

Here is Gerald Sussman, creator of SICP and the course, explaining exactly what happened with the switch - https://www.youtube.com/watch?v=cblhgNUoX9M&t=3578s

Re: How to Design Programs (2014)

#135

Post by astrange »

disgruntledphd2 wrote: post #81
astrange wrote: post #30

Earlier quoted context omitted.

Knuth's TAOCP was originally written in an imaginary 60s-style CISC assembly called MIX (with some oddities like being decimal) but newer editions are in a RISC style one called MMIX (which Knuth claims is more practical but really isn't.)

Well, all I can say about that is that I read through the MMIX supplement and did a bunch of the exercises, and I know have enough knowledge to vaguely understand assembly. 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.

By practical I meant it's hard to implement in hardware. As far as I know it's easy to learn, having register windows is just kind of weird.

Re: How to Design Programs (2014)

#136

Post by billfruit »

notapenny wrote: post #118
billfruit wrote: post #20

Earlier quoted context omitted.

'Concepts, Techniques and Models of Computer Programming' by Peter Van Roy and Hadidi may be a better book than this and even SCP, since it presents a well organized "science" of computer programming..

I've read both SICP and CTMCP and would recommend the latter as a first read. Sure the language it teaches in is not practical, but I actually found that to take away the distractions of reading a book in whatever your target language is. Also its the first book that got me thinking about how programming languages actually work and what actually happens under the hood when you're writing code. Great book.

I also like that it is a very comprehensive book, it covers almost all fundamental approaches to programming, and clearly sets out their scopes and limitations.

Re: How to Design Programs (2014)

#137

Post by sevensor »

samth wrote: post #5
sevensor wrote: post #3

This is a book that embodies its thesis, that learning to design programs is like learning how to write or do mathematics. In the same way that academic treatments of writing or math abstract out the things you might actually do with writing or math, HTDP abstracts out the things you might actually do with a computer program. Instead you work through exercises that illustrate the fundamental concepts. I don't know th…

Are you saying the examples in the book are insufficiently real-world (ie, they should be more like creating websites and less like Tetris [ https://htdp.org/2020-8-1/Book/part_two.html#%28part._sec~3a... ] or XML [ https://htdp.org/2020-8-1/Book/part_four.html#%28part._ch~3a... ])?

No, I think that would be a lazy and unjustified criticism. My remarks shouldn't be taken as criticism at all. In the same way that a calculus textbook has the student work carefully constructed math problems, HTDP has the student work carefully constructed program design problems, always at exactly the right level to stimulate growth. My point is more that the setting is as different from ordinary software development as a calculus class is from the work of electrical engineering. This isn't a bad thing; just as everything I learned in calculus class helps me in my work as an engineer, everything I would have taken away from HTDP had I been taught with it as an undergraduate, would help me now. Instead, having read through most of HTDP long after my school days, I've concluded that it's a very good, systematic treatment of a subject I learned in bits and pieces along the way.

Re: How to Design Programs (2014)

#139

Post by disgruntledphd2 »

astrange wrote: post #135
disgruntledphd2 wrote: post #81

Earlier quoted context omitted.

Well, all I can say about that is that I read through the MMIX supplement and did a bunch of the exercises, and I know have enough knowledge to vaguely understand assembly. 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.

By practical I meant it's hard to implement in hardware. As far as I know it's easy to learn, having register windows is just kind of weird.

Ah OK. I guess that makes sense (especially as Knuth implemented its interpreter in C, as documented in MMIXware).

Re: How to Design Programs (2014)

#140

Post by unrequited »

tartoran wrote: post #94
unrequited wrote: post #57

Earlier quoted context omitted.

What would be your advice to someone who's going through that frustration? I would love to get in touch to talk more about this. Thanks.

It really depends on what your current situation is. Sometimes a break or distancing solves the problem. Other times it simply is trying something else, job, language, hobby. Make changes until something clicks. It sounds cliche, each person has a different journey but journeys do have some common patterns. Not sure what your frustrations stem from but I could get in touch and talk more about this.

Thanks, this in insightful. Is there a way I can reach out to you?
Post reply on HN