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

21–30 of 141 posts

Re: How to Design Programs (2014)

#21

Post by spekcular »

ska wrote: post #6
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.

MIX/MMIX are close to how CPUs work physically. scheme is close to how computation works theoretically. The pedagogical approach that appeals to individuals tends to align with how they are most comfortable thinking about it.

Let me say something that may reveal my ignorance, but which I'm very happy to be corrected on: for the purpose of writing moderately-sized, everyday programs, I've never needed to understand how computation works theoretically (more abstractly than introductory algorithms and data structures). And that's not because I'm not comfortable with abstraction, or because I don't know how it works theoretically, I just haven't.

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...

Re: How to Design Programs (2014)

#22

Post by neilpanchal »

unreal6 wrote: post #18
neilpanchal wrote: post #13

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/

Thanks, TIL Racket is a programming language for languages: https://racket-lang.org/

Re: How to Design Programs (2014)

#23

Post by Jtsummers »

spekcular wrote: post #21
ska wrote: post #6

Earlier quoted context omitted.

MIX/MMIX are close to how CPUs work physically. scheme is close to how computation works theoretically. The pedagogical approach that appeals to individuals tends to align with how they are most comfortable thinking about it.

Let me say something that may reveal my ignorance, but which I'm very happy to be corrected on: for the purpose of writing moderately-sized, everyday programs, I've never needed to understand how computation works theoretically (more abstractly than introductory algorithms and data structures). And that's not because I'm not comfortable with abstraction, or because I don't know how it works theoretically, I just have…

> 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.

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.

Re: How to Design Programs (2014)

#24

Post by brudgers »

procload wrote: post #8

Why is this posted again today?

There was this question about books on software engineering. https://news.ycombinator.com/item?id=26488944

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.

Re: How to Design Programs (2014)

#25

Post by mmcdermott »

naringas wrote: post #17
adamnemecek wrote: post #2

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

The part about the two mindsets sounds vaguely familiar. Is there an article or blog post that lays this out in more detail?

Re: How to Design Programs (2014)

#26

Post by gwern »

procload wrote: post #8

Why is this posted again today?

Hanson & Sussman have a new SICP-related book coming out which tackles similar topics: https://mitpress.mit.edu/books/software-design-flexibility This post may ultimately be downstream of people thinking about software engineering/CS textbooks and comparing.

Re: How to Design Programs (2014)

#27

Post by bogomipz »

ska wrote: post #6
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.

MIX/MMIX are close to how CPUs work physically. scheme is close to how computation works theoretically. The pedagogical approach that appeals to individuals tends to align with how they are most comfortable thinking about it.

>"MIX/MMIX are close to how CPUs work physically."

What is MIX/MMIX? Is this something specific to the SICP book?

Re: How to Design Programs (2014)

#28

Post by spekcular »

Jtsummers wrote: post #23
spekcular wrote: post #21

Earlier quoted context omitted.

Let me say something that may reveal my ignorance, but which I'm very happy to be corrected on: for the purpose of writing moderately-sized, everyday programs, I've never needed to understand how computation works theoretically (more abstractly than introductory algorithms and data structures). And that's not because I'm not comfortable with abstraction, or because I don't know how it works theoretically, I just have…

> 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. 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…

Yes, I agree, that is a caricature. More seriously, I think leaning on this language-specific feature in a book that's supposedly teaching "general programming 101," or whatever, is in bad taste. As it says:

> 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.

Re: How to Design Programs (2014)

#29

Post by Jtsummers »

bogomipz wrote: post #27
ska wrote: post #6

Earlier quoted context omitted.

MIX/MMIX are close to how CPUs work physically. scheme is close to how computation works theoretically. The pedagogical approach that appeals to individuals tends to align with how they are most comfortable thinking about it.

>"MIX/MMIX are close to how CPUs work physically." What is MIX/MMIX? Is this something specific to the SICP book?

From Knuth’s The Art of Computer Programming. MIX is the earlier version, MMIX is the more recent (though now 20 or so years old) version. They are descriptions of a computer architecture and machine instructions used to explore algorithms in his books.

https://en.m.wikipedia.org/wiki/MMIX

Re: How to Design Programs (2014)

#30

Post by astrange »

bogomipz wrote: post #27
ska wrote: post #6

Earlier quoted context omitted.

MIX/MMIX are close to how CPUs work physically. scheme is close to how computation works theoretically. The pedagogical approach that appeals to individuals tends to align with how they are most comfortable thinking about it.

>"MIX/MMIX are close to how CPUs work physically." What is MIX/MMIX? Is this something specific to the SICP book?

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.)
Post reply on HN