(1) The book is not finished yet. But it will appear with MIT Press, and I expect it to appear over the next year and a half or so.
(2) Realm is best read after HtDP [1e or 2e] or some other course on plain programming (not necessarily program design). It teaches (simple) programming in Racket.
(3) HtDP [2e] does NOT teach programming in Racket. It uses several teaching languages, each matching a stage in the convex hull of the design recipes (tactics) of a certain part of the book. HtDP's design tactics do away with the usual "everything is a Turing machine so learn by coping me" approach.
As a student of NEU, I personally swear by this resource. Having been a part of the staff of the course for 3 years now, I can say that students love to bitch about Racket at the start, but few curse it's name by the end.
I wish more people were as excited by Racket as I am.
As a freshman who took the course that uses this book, I can say I'm still cursing the name. I figure some of the value will become clearer, but aside from commenting functions clearly and testability of code, I don't think I got much of value from it.
I've seen the benefits of teaching freshman (and anyone) functional programming first.
The "comments" are really an introduction to type systems, along with general good practice.
The ability to describe a function by purely it's signature without the presence of mutation makes reasoning through hard problems more straightforward.
I'm coming to NEU this spring and excited to see Scheme there. I followed few chapters from SICP some time ago, and am curious how similar/different is HTDP from SICP?
I especially like their introduction on how to create a web service, using continuations for handling session, a technique also used "Beating the averages":
This is an invaluable resource (next to McConnell's Code Complete) that has influenced the way I program even to this day. Happy to see that my old university is still using HtDP as its curriculum's primary guidance.
UBC's introductory CS course (CPSC 110) uses HtDP/2e as its "textbook". Given the progress that the majority of students make throughout the term, I think it's quite successful in terms of teaching the fundamentals, despite not being based on a more "conventional" language like Python or Java.
How to Design Programs is a conventional college textbook. Felleisen and the PLT Group have a specific pedagogy developed during his decades as as educators with a deep interest in teaching computing [not just computing in general].
Realm of Racket is designed more or less as a self paced tutorial. It is in the tradition of Land of Lisp. It is targeted at a broader and more general audience.
I haven't read either cover-to-cover, but from the chapters I've read, Realm of Racket is a lot more conversational. It feels slightly gimmicky with the emphasis on games. Also Realm assumes you have some programming experience in other languages.
How to Design Programs starts at the very beginning and has a lot more principled of an approach, focusing on FP and programming as calculation of values. It's by far my favourite introductory programming text.
Quote from that page:
"Good programming requires thought, but everyone can do it and everyone can experience the extreme satisfaction that comes with it."
That contrasts directly with my opinion after 20-years of development experience working on applications across a number of industries and in teams of 1 to 100. Not 'all' programmers can be or are good, and definitely this is not true for 'all people' in general.
After such a start, why then should I read further? I'm genuinely interested to know the answer.
You should read further to find out why the authors disagree with your opinion (including how they explain your experience), and how they propose approach the problem you think is insoluble.
Well, except that seems to be covered better by the preface to the firat edition.
Replace 'programming' with 'guitar playing' or 'painting' and I would still think the same way. 'Programming' is not a special case. Thanks, though, I will read ahead a bit and try and keep an open mind.
What makes a good guitar player, or painter anyway?
They practice.
Your idea that some people "have it" and some don't is just not true with almost anything in reality. Prodigies are extremely rare, and everyone else who "has it" got there by practicing in their field. Anybody (assuming no other learning disabilities) can become a programmer, and a good one at that, if they honestly believe they can do it, study the foundational skills they need for it, then practice and practice.
Try to remember how you became a programmer - chances are you started learning at an early age - you already had the foundational skills in language, math and science etc, because you were competent in school, and you probably spent a large part of your youth engaged in programming. You're no prodigy, and you didn't have it to begin with. Instead of saying "I can't do it", your probably the type to ask "how can I do it?".
The "bad", or non-programmers are more likely to be the ones who say "I can't do it", "it's too complicated for me", etc. You can crush the chance of these people ever being competent by simply agreeing with them that they can't - because if they don't have the belief that they can, they won't bother spending hours learning the foundational skills they need, or the thousands of hours practicing which would turn them into good programmers.
From my teaching experience, the learner's belief is by far the most important factor in their learning. Those who have no belief will simply not put any effort into learning, and will never progress. The author obviously understands this too, and invites the reader to first believe they can do it, so that they continue reading.
Try to write some educational material for programming, and introduce it by saying "You probably won't ever get good at this, you suck, why are you still reading?", and see how many engaged readers you get.
At one of the coffee shops local to me works a woman who was encouraged into programming as a career. She believed she could do it, did a BSc, worked as a dev for a year, hated it, now works at the coffee shop scratching her head about what to do. My last IT director had a similar experience. He became a business analyst after hating dev for two years, having become a dev by having the prescribed requirements. Programming simply is not for everyone, and telling those people to just practice ignores the fact that they couldn't do so and retain their sanity. I think it's fair that we don't expect people to forego their sanity, and therefore that they won't be able to practice, and therefore that they will never be good programmers.
The authors don't think programming-as-a-career is for everything, they think that programming-as-a-skill is something that, taught properly, is accessible to anyone and has value that extends well beyond programming-as-a-career.
The preface to the first edition expressly made this clear, introducing the book as "the first book on programming as the core subject of a liberal arts education", and proceeding to lay out the case for programming as a liberal arts core subject [0]. It specifically notes that "traditional forms of programming are useful for just a few people." (emphasis in original)
There is a big difference between saying "programming simply is not for everyone" and "not everyone can learn to program".
The book is saying that everyone can be good (although like guitar, through practice). That's very different from "everybody will be good" or "everybody will enjoy it" or "programming is for everyone"
Sometimes it's hard to know if its for you or not until you've immersed yourself in it for long enough. Unfortunately for the woman you mentioned, this was likely many years of her time. Other people know immediately. Either way it doesn't mean that they couldn't learn or get nothing out of it.
You don't have to be a chef for knowing how to cook nice things to be a useful skill to have.
There is a difference between being able to be good at something, and that thing being what you like to do. Generally they go hand in hand because you are more likely to spend time doing something you like.
The statement at the start of the book is just saying that anyone can be good, but it doesn't say everyone will.
"There is a difference between being able to be good at something, and that thing being what you like to do."
That depends on the degree to which you like or dislike that thing. If you don't like something to the point that you can't stand to pursue the practice that would make you good, then you are not able to become good at it. If you aren't able to practice, then you aren't able to be good. Not everyone will, agreed, but nor can those who can't stand the necessary practice.
They practice. And have enough innate natural ability so that the amount of practice time required to achieve competence doesn't exceed the amount of time they actually have.
"Anybody (assuming no other learning disabilities) can become a programmer, and a good one at that.."
I still haven't seen any actual evidence to support this statement, and have seen plenty that does not support it across my career and interaction with many programmers. It should be obvious, I would think, that with all jobs there are some people who are good and some who are not. Why is programming so special that everyone can be 'good'? It's not.
"Those who have no belief will simply not put any effort into learning, and will never progress."
This might sound harsh, but this is fine by me. I like the idea that programmers / doctors / musicians / etc have been and are highly-motivated and dedicated, and weren't molly-coddled throughout their career. If they need to be babied into doing something, they can do something else.
I don't believe there is such thing as "innate natural ability" which can triumph over dedication. Sure there is some genetic influence on intelligence and learning ability, but most of it is nurtured - usually at an early age. Unless there is some underlying learning disability, any person can become competent at something they desire if they have the willpower, the resources and direction. Also, despite popular belief, you can teach an old dog new tricks.
Usually, if someone struggles progressing, it's because they're lacking some foundational knowledge to understand it. I see this most often with math, people put off by type theory and such because "ooh, scary notation", which needs learning before you can even begin to read the literature. Even basic math is a no-starter for some people, because they were unable to grasp the way arithmetic was taught to them in infant school, they just think "I'm terrible at math" for the remainder of their life - rather than what they should think - that they weren't taught properly to begin with. It's actually quite fun to teach the basics to adults who always thought they were crap at something, because you see them transform into hating a subject into loving it. Perhaps the "bad" programmers you speak of have simply lacked someone to mentor them and bring out the best in them?
I think you're holding the bar too high for "good" too. What do we even mean by a good programmer - one who writes few bugs, solves problems the quickest, writes independent, cohesive modules, or a combination of many factors? - surely then we'd have a mix of people who are good at some of these and bad at others - then there's nobody who's going to be "good" at all of them. If writing few bugs makes a good programmer, then such programmers are extremely rare. Good means competent enough to solve problems with code - it doesn't mean everyone is "exceptional".
I don't believe that I could become an exceptional author for example, but that doesn't stop me from writing. Imagine we only taught writing to children who show the aptitude to become authors? Of course, this can't happen - the opportunity needs to first be there for one to consider dedicating themselves to it, and you don't motivate someone into trying by telling them they can't do it. Writing has practical use besides being an author - it can act as "external storage" for our brains, and it's a communication tool - as is math, and programming has the potential to be far more useful than both of these, if people didn't see it only as a career path.
As for being "moddy-coddled", you'll probably find that most talented individuals have had good mentors at some point in their lives - who can point them to the most suitable material to learn from. Autodidactism only gets you so far, because you don't really know what it is you're learning until you've learned it - if you're trying to specialize in something, it's not very efficient.
> This might sound harsh, but this is fine by me.
I don't think that's harsh, but I think everyone should have the opportunity to learn before brushing them off as incompetent. From personal experience, I have little time for people who don't want to put in the effort to learn and progress, but I'll give hours of my time away for free to those who genuinely put in the effort. It's not the case that some have the ability to begin with - it's that I need to find the right way to explain something in a way they understand.
Because it says more about the author's pedagogical approach than it does about the content of the book itself. There are probably more important indicators of the book's value further along.
>After such a start, why then should I read further?
Because the stated assumptions aren't always reflective of the actual design principles of a product. HTDP is a solid course that in practice does not compromise on quality for the sake of popularity.
That everyone could (and should) learn to program is also a popular thing to say these days. This generally means that you can discount the importance of any one person saying it to that person's beliefs.
Does any know what software was used to generate the book? I assume, because of the CC license, the source might be in some github repo, but I was unable to find it.
(1) The book is not finished yet. But it will appear with MIT Press, and I expect it to appear over the next year and a half or so.
(2) Realm is best read after HtDP [1e or 2e] or some other course on plain programming (not necessarily program design). It teaches (simple) programming in Racket.
(3) HtDP [2e] does NOT teach programming in Racket. It uses several teaching languages, each matching a stage in the convex hull of the design recipes (tactics) of a certain part of the book. HtDP's design tactics do away with the usual "everything is a Turing machine so learn by coping me" approach.