I've been programming on and off both professionally and as a hobby for years and recently realized that the design and architecture of programs is a huge weakness for me. I tend to learn a language and then not know what to do with it because I don't know how to architect anything beyond the smaller-style examples and exercise solutions. To that end, I started working through HtDP a few weeks back and am enjoying the journey, but recently have started wondering if it's actually going to teach me what I want to know.
For example, one of the things I find difficult (and I know I'm definitely not alone here) is how to properly handle shared, mutable program state. As I've spent a reasonable amount of time with languages like Clojure, I understand FP in general doesn't embrace such things, but even Clojure has ways of handling it. I'd also like to gain an understanding of how to deal with state (and design in general) in lower-level, more imperative languages like Rust, which is the prime example of a language I "learned" but then didn't know how to build anything with.
My question is: will HtDP teach me (mutable?) state management and other, more non-FP techniques, or am I in the wrong place? I'm sure it will help with FP style design, but does the knowledge generalize to other styles of programming?
I strongly believe that the only way to really improve programming skills is by actually programming. So, if you feel that you don't really understand how to architect a larger program with shared state, the only real way to learn how is by doing it. So, try writing a large program the requires shared mutable state!
You will run into problems and have to really think about them in order to solve them. Once you've encountered some problems first hand, other materials might come in handy, but there is just no substitute to finding and solving problems yourself.
I completely agree with the hands-on learn by doing approach. My issue becomes knowing when I'm doing things "the right way" so that I'm not reinforcing bad habits. There can be a huge gap between something working and something that's been properly designed/architected. I was hoping that HtDP would give me better instincts in this area and was curious if the book covered the material I was interested in.
General notes. (1) HtDP is an introduction to systematic program design — for novices. The design recipe and the design guidelines scale up, but I wouldn’t expect a novice to recognize this. Then again, an experience developer may see how “every function needs a purpose statement, before you start” turns into “every module needs a purpose statement, before you start” and so on.
(2) The book consists of parts. Parts II thru romanN are organized systematically. The first chapter shows an example of something that can’t be designed with what a reader has learned so far. The second one extends the design recipe (a matrix of data complexity x process steps) to include this new concept. The remaining chapters illustrate this point with examples, and on occasion, they add a design guideline.
(3) Parts I through IV are structural design, ideas derived from the literature on FP. V is about generative recursion, usually covered in Algo, and VI is about equipping the design recipe from I through V with accumulator. (For those who understand the connection between FP and Math, “it strengthens the induction hypothesis and exploits it for efficiency.” Accumulators come in 2 varieties: function and data accus.)
1e Specific. Parts VII and VIII expand the design recipe to imperative features (variable assignment, field assignment, but really design of problems that need 0, 1 or 2+ state changes.)
2e Specific. It drops part VII and VIII but they remain available via on-line book sales and the web site. ~~ The book also adds functional event-handling programming, from day 1. (If you know JS think React w/o DOM but 10 years older.) This excites students because even the “hello world” program is more exciting than print(“hello”).
People w/ experience. Someone with experience (and without fear) should just read all chapters and sections whose title contains the word “design”. If any one of those poses a challenge, backtrack and read the preceding section or chapter. My teaching assistants for upper-level courses (typically with an BS degree, 1 year MS study, and 2-3 years of industry experience) always claim that they get a lot out of such a “scan”. Perhaps they are just overly nice and don’t want to disappoint me.
Thanks for taking the time to write such a thorough reply! I hadn't considered "skimming" the design chapters, nor did I know that the imperative-style sections were present in the first edition.
Would working through the removed sections of the first edition after finishing the second be confusing or would they follow fairly naturally?
Thanks. Alternatively, and out of curiosity, is there a different text you'd recommend that covers similar material but is aimed at a more experienced audience?
HTDP is way more beginner focused, leaning toward the "I have never programmed before in my life" camp. I would not read the book, I've read like 3 chapters in and I get burned out, the live course curriculum is great but in text form it's a mess.
Dan Grossman's PL course(free) is really good and rigorous, I think it was the missing link to understand languages from a designers perspective in some ways, and various programming styles : Dan Grossman, Instructor | Coursera
I've been caught up in the "design and architecture" loop before, its paralyzing, because it feels like you're always doing things "messy and sloppy"? And as you alluded to, it's being stuck in trying to find the "right way".
Somebody was saying on the forums a while back that they felt like the code is too messy and again I really want to stress the fact that I dont really want to tell people the way they code is wrong, I feel like that leads to a lot of pendantic arguments that arent particularly constructive, but what I can say is nobody in my mind should be thinking that this code is messy, this code is exactly what it should be. It’s code that we’re writing to figure out how we want to structure our program and if you’re spending time right now thinking about how to make this code “not messy”, whatever that means to you, then essentially what you’re doing is wasting time. You’re spending time that should have been spent on the problem, thinking about the code, and the end state of your program is not to have clean code, it’s to have good working code. Cleanliness has nothing to do with those things, if you have the ugliest code in the world that someone would look at and call very messy but it has no bugs and runs great, then it didn’t matter, so to the point we care about how clean code is, we only care about that in so far that it has an effect on our end product, and what we’re trying to do right now is trying to define the structure of the code, so none of the code will ship in the game or if it does, it got pulled out and changed around a little, and put into its proper place, and so we know it will clean up overtime as we learn what it should be, but prematurely cleaning it is actually worse than wasting time but it may lead us down to wrong paths and end up making us have to to girations to make stuff work together because we segregated in a bad way too early on. If the way you look at code is that you think of it as messy or clean, that is a very bad habit IMO. Instead think about the problem you’re trying to solve. When you are done and to your satisfaction solved that problem in however messy a way as you can, then that is the time to start thinking about cleanliness of code, and what we mean by that is, can we find the bugs in it easily, is it easy to understand, is it easy for me to re-use it, in the places where I need to reuse it, etc, and NEVER some set of perscribed set of rules based on what the code looks like, it’s only based on what the usage looks like and what the debugging process looks like, and this is what seperates good programmers and bad programmers. - Casey Muratori