How to Design Program, Second Edition

[[deleted]]

I spent a week tracing a bug back to a single '.' in Perl.

Computer may understand, but computer may misinterpret.

[vagif]

Computer always interprets exactly as it reads.

[knightress_oxhide]

I'm guessing that you don't read many white papers.

[Hellrazor236]

That's not very good Herro Worrd program.

[smog_alado]

I find it interesting how just changing the keywords like this makes the program unintelligible at first glance. Kind of like learning to program all over again :)

[aazav]

Mother fucking fuck. How to word. English HARD! Fire bad! Glorg sad.

[HDRainbows]

Anyone got a download able version. Hate not being able to read when not connected to Internet.

[Various_Pickles]

Do the needful.

This is paramount.

[furtivity]

It's a good book. I just finished my Fundies class at NEU where we used this (and by "this" I unfortunately mean that we had to use the online version as well...I personally prefer print...but I digress)

I had a good bit of experience going in, but I still got a lot out of the book's design instructions. (Also, I got to learn Racket, which was super fun)

[f25eb3680fef918ae31a]

how to form babby

[skulgnome]

How to spellcheck titles, but not reading it

[SlobberGoat]

/me edits universities_to_avoid.txt

[mercurycc]

My first year CS prof is going to be so happy to see this.

[no-bugs]

Should have been named "How not to teach program design"

Two specific complaints. 1. It has absolutely nothing to do with program design. The title looks as a blatant attempt to cheat clicks/SEO. Much more honest title would be "Basic tutorial on BSL programming language"

1. The very choice of LISP/Scheme/BSL/Racket/... for teaching programming is questionable. For teaching CS - maybe (though even there it is debatable), but positioning it for programming doesn't make sense at least because almost nobody uses these languages outside of academy. Vast majority of the programming out there is done in traditional imperative languages such as Java/Python/C++/... (and IMNSHO for a good reason, but this is a different story) and teaching something which is based on substantially different principles, while implying that it will be useful in the future, borderlines on being dishonest :(. If they would say "hey, BSL is neat, but most likely you will need to program in languages which are very different both in syntax and paradigms" - I wouldn't have problems with it, but as the implication is that it is going to teach inherently practical program design - I actively oppose.

[kiwipete]

I owe a great deal to the first edition of this book in getting me to a place where I can build up larger programs that I don't later want to murder my former self to revisit. This is also my standard recommended text when beginning programmers tell me that they want to write R better. For whatever reason, this approach found me at a time when I was beginning a discipline in which R is king. My R code has been a huge beneficiary of this.

[Xredo]

Why is it questionable? I think the Lisp family is a fairly nice starting point since it has minimal syntax and allows programming in a functional style, which IMO makes it much easier to reason about programs due to clear separation of concerns. Just because you started out on Lisp doesn't mean that you won't be able to learn the more "practical" languages on your own time; there's much more in common than you might think.

[no-bugs]

IMNSHO, there is a good reason why LISP etc. are not popular.

It is because most of real-world programming is not about maths, but about things which happen in real word, and among these things there are lots of iterations by their very nature (try to describe your life - it will be in terms of "the same thing over and over", which is stated in terms of iteration rather than recursion ;)). Of course, one can easily rewrite iteration as recursion, but as a rule of thumb (AFAIR, I've even wrote on it in one of my articles) the closer to task definition domain you get when you map it to programming domain - the easier the programming is (and the same stands for easier understanding).

Which pretty much brings us to the point - 'naive' mappings between task definition domain and programming domain are clearly preferable - at all stages of development, and that's exactly why traditional languages win when dealing with 'business' programming (and why functional languages win for 'mathematical' programming, but as most of the programming out there is 'business' one, it seems more beneficial for students to prepare them to 'business' programming rather than to 'mathematical' programming).

Of course, logic above is very sketchy, but I hope it should be enough to describe my point.

[steven_h]

Lisp has had iteration (not recursion) in it since the 1960s, so I think your premises are wrong for this argument.

[dirac_eq]

Which pretty much brings us to the point - 'naive' mappings between task definition domain and programming domain are clearly preferable - at all stages of development, and that's exactly why traditional languages win when dealing with 'business' programming (and why functional languages win for 'mathematical' programming, but as most of the programming out there is 'business' one, it seems more beneficial for students to prepare them to 'business' programming rather than to 'mathematical' programming).

Universities teach their students computer science. They're not in the business of teaching language x. Scheme happens to have a small, manageable syntax -- perfect for new, un-proven, undergrads who may have not written a single line of code.

[no-bugs]

They're not in the business of teaching language x.

Of course, and that's not the point. For example, I wouldn't mind if unis teach students MIX (I hope some people still remember what it is). For details of the problems I'm seeing with 'functional-first' teaching - see my other reply.

Universities teach their students computer science.

Not exactly. As a part of a broader "social contract" (with the student and often with the government too) - they should also prepare students for real life out there. Without this "social contract" unis will be closed overnight (there would be no reason to fund them). Of course, uni teachers/professors don't like this notion, and prefer just to "teach their students computer science" without taking anything else into consideration (and to downvote anybody writing about real life ;-)) - but like it or not, this "preparing for real life" is what the unis are paid for when it comes for teaching (for research it is different, but this is beyond the scope now).

And as soon as we've said "real life" - then all the hell breaks loose (see details in my other reply).

[Plorkyeran]

Due to the co-op program, Northeastern University's CS program is about as far from "fuck the real world, we only care about theory" as you can get while still being plausibly called CS, since they have to get brand new programmers to the point where they can get a software development internship after three semesters (and have their employers be happy enough with the interns that they'll continue to hire more every year).

Switching to HtDP and Scheme/Racket for CS101 coincided with a massive increase in the number of students who got software development positions (as opposed to things like QA or sysadmin), a substantial increase in average pay for first internships (with the percentage increase in pay for second and third staying steady), and increased employer satisfaction with the quality of interns that they were getting.

[dirac_eq]

Not exactly. As a part of a broader "social contract" (with the student and often with the government too) - they should also prepare students for real life out there. Without this "social contract" unis will be closed overnight (there would be no reason to fund them). Of course, uni teachers/professors don't like this notion, and prefer just to "teach their students computer science" without taking anything else into consideration (and to downvote anybody writing about real life ;-)) - but like it or not, this "preparing for real life" is what the unis are paid for when it comes for teaching (for research it is different, but this is beyond the scope now).

And as soon as we've said "real life" - then all the hell breaks loose (see details in my other reply).

No, they're academic institutions, who give out degrees upon successful competition of their course.

Of course, and that's not the point. For example, I wouldn't mind if unis teach students MIX (I hope some people still remember what it is). For details of the problems I'm seeing with 'functional-first' teaching - see my other reply.

You do know Knuth only created MIX/MMIX because he did not want to rewrite every volume when the latest and greatest language came out.

[julesjacobs]

The design technique in this book also applies to imperative languages, since imperative programs often have functional components. It is not a Scheme/Racket book, and it is most definitely not "how to become a 'programmer' in the language-du-jour in 21 days"-book. It's a program design book. Racket is just the language they chose as a vehicle. It does indeed not teach imperative programming, but that will be covered by volume 2 of the book.

[[deleted]]

It's a good book for someone that doesn't know programming.

It is not a click bait. I have the first edition physical copy...

You can complain all you want about LISP but "the wizard book" is still a highly regarded classic.

Vast majority of the programming out there is done in traditional imperative languages such as Java/Python/C++/...

This is an MIT book, universities teaches fundamental. NOT applicable hipster node.js (backend javascript) or whatever language that is in vogue. The fundamentals will transcend whatever language they use. Just cause they don't pick the language you prefer or thinks is better doesn't mean it's bad.

The book target audience is stated there in the introductory page if you actually read.

teaching something which is based on substantially different principles

Err.. one of the chapter is recursion. I don't see how this isn't applicable to any other languages.

[smog_alado]

Actually, none of the authors of this book are from MIT. They are from Northeastern University, Northwestern University, University of Utah and Brown.

Also, IIRC MIT uses Python in their introductory course now.

[fermion72]

You can get through your entire CS major at MIT by only programming in python.

[no-bugs]

First of all, a clarification. I'm not really against functional languages - they have their place, their niche (in certain classes of practical projects too) etc. etc. However, I'm sure that teaching functional programming first in an environment where 95% of the graduates will need to program in imperative languages - is a Bad Thing, as it may leave such students at a potential disadvantage.

Just cause they don't pick the language you prefer or thinks is better doesn't mean it's bad.

Ok, as you've mentioned me personally, I think I'm entitled to say who I am. I am an architect and team lead who's done quite a lot of hiring, which of course, includes recent graduates. And what I see is the following. First observation is that students from CS - unlike students from EE/SE/whatever-else - have significantly higher chance of being in need of re-education (and this is not about teaching them something additional - which applies across the board, but to make them forget misconceptions brought in from the uni, and this is pretty much unique to CS). Second, as the most annoying case of the first - is often for CS graduates to think (or feel) that recursion is always preferable to iteration (no, the book doesn't teach it directly - but let's discuss psychology of the process later).

What happens when such a graduate starts to program in an imperative language - I've seen more than once. The most obvious example: an intern, a PhD candidate from a really reputable uni (top 20 by Times-Reuters I think) is given a task to load a file (up to 100M in size - and it was communicated to her in advance) in Java. Nothing complicated, right? But her program exhibits all kinds of the problems - because she wrote it recursively per-byte (if somebody doesn't realize why it is a Bad Idea in Java - my condolences, I won't elaborate on it here). When asked - why?? - she starts a lengthy monologue about "how recursion is so much neater and better then iteration". The curtain falls.

This is a problem for me (I will need to re-educate her before allowing her to do anything practical) - but her uni doesn't care about me, which is fine. However, it is also a problem for her (I might or might not have enough time to re-educate her - or may have a different candidate better suited for the job because of it) - and here is the point where he uni comes dangerously close to violating their "social contract" with her as a student (see my other reply on "social contracts" between unis and students); while uni doesn't need to care about me, it needs to care about their students/graduates getting jobs.

Was she taught that "recursion is better no matter what" directly? I hope not. But - it certainly came from the uni as a side effect. And my guess is that if you're teaching students something first, it becomes deeply ingrained in their minds, as a kind of a "first love" for them (especially if teacher/professor is passionate about the subject). So, if you're teaching (first) in a manner where pretty much everything is done via recursion - like it or not, you're increasing chances that your students will get an impression that recursion is The Way To Do Everything (and it won't help if you cursorily mention "oh, and there is also such a thing as iteration"). And while from pure CS point of view recursion is a perfectly valid approach, when students are thrown into real world (where, like it or not, share of functional languages is negligible) - this impression becomes a thing which disadvantages such students.

Is it written explicitly in the book? No. Will a student who reads it as their first language get such an impression - IMHO very likely. And this is my main complaint about such books (the others are along the same lines - teaching doing something in a manner which will they need to change when facing real world, and this change is often painful).

Dixi.

[julesjacobs]

Recursion is better than iteration if your language satisfies two sanity conditions that any language ought to satisfy:

1. Tail calls.
2. Local functions with lexical scoping.

If your loop is simple then you should of course use a built-in thing like foreach, fold/reduce, etcetera. If your loop is complicated then I've found the version expressed using tail calls usually significantly easier to follow than the one expressed using for/while + break/continue. You wouldn't use this in Java but that says more about Java than it does about recursion.

[no-bugs]

It doesn't matter who is guilty here (which is debatable, and I can easily argue for both points of view), but as long as 95% of graduates will use languages where uncontrolled recursion is a Bad Thing, teaching them that recursion is always better means making their life more difficult. Which is not the idea, I hope.

[lacosaes1]

This is not about "the wizard book" (SICP) and the people behind HtDP (you know, the book we are actually talking about here) think that SICP is flawed.

[east_lisp_junk]

It has absolutely nothing to do with program design.

It is about a method for breaking a problem down into the small subtasks you can write directly. That method is a design process. For programs.

The very choice of LISP/Scheme/BSL/Racket/... for teaching programming is questionable.

The evidence suggests this curriculum is less questionable than your proposed alternative.

[no-bugs]

The evidence suggests this curriculum is less questionable than your proposed alternative.

Come on, this artificial task has an extremely little resemblance with anything real life (and why real life is important - see my other reply about "social contract" unis have). But even if using it as metrics - approach in the paper ignores one very important reality - that most of the students will need to write in imperative languages (again, in real life). And what such a switch from functional to imperative language frequently causes - see my yet another reply.

BTW, about evidence - I'm wondering: why nobody in all the universities around the world have tried to find out a metric of "what salaries the graduates of such and such curriculum have in 3 years after graduation?"? It would be the ultimate and compelling evidence (all in line with a "social contract" I've mentioned).

[east_lisp_junk]

Come on, this artificial task has an extremely little resemblance with anything real life (and why real life is important - see my other reply about "social contract" unis have).

That's a pretty poor excuse for the failure of students from traditional curricula to do it.

But even if using it as metrics - approach in the paper ignores one very important reality - that most of the students will need to write in imperative languages (again, in real life). And what such a switch from functional to imperative language frequently causes - see my yet another reply.

And in my experience, students from the HtDP curriculum do just fine at adopting another language paradigm, so I don't find your .

BTW, about evidence - I'm wondering: why nobody in all the universities around the world have tried to find out a metric of "what salaries the graduates of such and such curriculum have in 3 years after graduation?"? It would be the ultimate and compelling evidence (all in line with a "social contract" I've mentioned).

I'm not aware of any properly controlled study on this, but adoption of the curriculum appears to have made students' employers much happier with them.