How to Design Programs 2nd Edition

https://htdp.org/2023-3-6/Book/part_preface.html

by noob_eng • 3 years ago

253 102 3 years ago

htdp.org

ChicagoDave5• 3 years ago

I would not follow any of this book anymore.

Abstractions lead to coupling and complexity.

So many outdated principles I can’t enumerate them all.

Hypergraphe• 3 years ago

In fact, that could be useful to ellaborate a bit.

ChicagoDave5• 3 years ago

Primarily this book completely ignores communication with subject matter experts and the business. This is fundamentally more important than any language, process, or platform.

geokon• 3 years ago

I also found the outside-in way they solve problems (using stubs for inner calls) very bizarre. I could be wrong.. But I don't think anyone codes like that

regularfry4• 3 years ago

"Using stubs for inner calls" is literally a top-level description of London-style TDD.

ryanjshaw• 3 years ago

I code like that. I got burned one too many times spending hours/days on an inner call that turned out to be unnecessary. When you solve outside-in, you are sure you're solving the right problem in the right way without overcommitting to intermediate steps.

atoav• 3 years ago

Abstractions lead to coupling and complexity.

So you write everything in assembly and rewrite it completely for every new target system? Seems a bit tedious to me /s

Just kidding abstraction serves it's function and the right amount of abstraction makes things better, more transferable, easier to maintain etc. I think for example about hardware abstraction layers (HAL) in embedded programming. But abstraction in programming is never a value in itself and its use needs to be weighed carefully.

I think it is best to teach people to stick to the data and to think about transformations between said data. If they don't know abstraction (aka beginner's spaghetti code) it is worth telling them about it.

SanderNL5• 3 years ago

I think ORMs fit that bill. For some reason they were (are?) incredibly popular, but I don't think they stood the test of time. In the case of SQL, it's already an abstraction. No need for elaborate wizardry to hide the fact you're about to JOIN a table or two. Just write the damn join.

Every. Single. Project. I see using ORMs resulted in a baseline 20+ queries being fired under the hood for every screen. They are not bad in and of themselves, I think that they attract or are amenable to a certain type of development mindset that ends in bad results.

I have a very hard time thinking of any kind of object oriented abstraction that turned out to be a very good idea.

taneq• 3 years ago

But abstraction in programming is never a value in itself and its use needs to be weighed carefully.

I think this generalises well to anything in (or outside) programming. Slavish adherence to any principle without consideration for the underlying merits of the situation is likely to become a negative.

pjmlp• 3 years ago

Actually it would have to be numeric codes, as Assembly is also an abstraction. :)

stinos• 3 years ago

Abstractions lead to coupling and complexity.

The wrong abstractions can lead to coupling and complexity. The right ones on the other hand are all about reducing coupling and complexity.

ChicagoDave5• 3 years ago

We have a history of abstraction-based code that’s turned applications into frozen balls of mud.

We have so many tools to help write good code that the short-term savings of shared libraries is superseded by having distinct codebases that can be modified without those dependency concerns. Same is true for finding bugs in many places and easily setting those up for maintenance releases.

jasfi• 3 years ago

I agree, besides, there's really no getting away from abstractions to manage complexity.

GiorgioG• 3 years ago

Over time all abstractions become “wrong” as requirements change.

simplotek5• 3 years ago

The wrong abstractions can lead to coupling and complexity.

This comes to the old quote:

* "Make everything as simple as possible, but not simpler.” Albert Einstein.

Abstractions undoubtedly add complexity that quickly becomes unmanageable. By now everyone is already aware of the horror that's the enterprise version of Hello World, and YAGNI/gold plating are renowned antipatterns. Many codebases have already succumbed to the perils of premature generalization, where the good old rule of 3 of refactoring serves as a shield against it.

But still some developers succumb to the siren song of abstracting away things.

oslac• 3 years ago

Having read through the old version I cannot recommend that one either.

ericjmorey2• 3 years ago

Would you care to elaborate?

ericjmorey2• 3 years ago

Could you share a few examples of what you consider outdated principles?

favadi• 3 years ago

Abstractions lead to coupling and complexity.

Without abstractions, we would still programming using punched cards.

mumblemumble3• 3 years ago

Abstractions lead to coupling and complexity.

If you're in the habit of programming in anything other than machine language, I think you'll have to agree that the real story is more nuanced than that.

I haven't actually read this book so I'm not prepared to defend it. But I would happily run my mouth and say that the truth is more that abstractions are a double-edged sword. They can be very effective in skilled hands, but they are dangerous in the hands of the untrained. Unfortunately, what makes a good abstraction (IMO it's algebras or GTFO) is not something in which most of us receive sufficient training.

Joker_vD3• 3 years ago

If an "abstraction" leads to coupling, then it's not an abstraction.

qumpis• 3 years ago

This might not be a perspective of a programmer, but the code I've reviewed and tried to understand from academics is always easier to manage when it's not abstracted too deeply. Especially when reading the code is the main reason for trying to understand the underlying idea.

Unless you have an extensive (visual?) representation of how the code flows, abstracted code for beginners might be a hindrance towards understanding what's happening at the lowest level while still maintaining the contours of the whole thing.

Of course when everyone's on the same page and has similar understanding, this is no longer a concern.

taeric2• 3 years ago

Would be nice to see at least a few of the principles called out. What makes them outdated?

And coupling/complexity are a touch on the weasel word space for our domain. They can mean things, sure, but they are often used for the emotion attached more than anything else. Worse, as programs grow, they probably should be coupled heavily. Loser coupling is almost always more complex to maintain and of diminishing returns. Is why the tires on your car can't be used on another vehicle. We probably could engineer the "one true wheel", but it would be done at the expense of capability. Not in pursuit of it.

adamors• 3 years ago

Posted just 3 weeks ago by the same user no less https://news.ycombinator.com/item?id=35478871

medo-bear• 3 years ago

i found out about it today

jmnicolas• 3 years ago

Not in vain since I just saw it today.

avinassh• 3 years ago

Why one should read this book? If you have read this book, what were your big takeaways from this?

soegaard5• 3 years ago

It's all about systematic program design.

The authors has the following to say in the Preface.

PREFACE

Many professions require some form of programming. Accountants program spreadsheets; musicians program synthesizers; authors program word processors; and web designers program style sheets. When we wrote these words for the first edition of the book (1995–2000), readers may have considered them futuristic; by now, programming has become a required skill and numerous outlets—books, on-line courses, K-12 curricula—cater to this need, always with the goal of enhancing people’s job prospects.

The typical course on programming teaches a “tinker until it works” approach. When it works, students exclaim “It works!” and move on. Sadly, this phrase is also the shortest lie in computing, and it has cost many people many hours of their lives. In contrast, this book focuses on habits of good programming, addressing both professional and vocational programmers.

By “good programming,” we mean an approach to the creation of software that relies on systematic thought, planning, and understanding from the very beginning, at every stage, and for every step. To emphasize the point, we speak of systematic program design and systematically designed programs. Critically, the latter articulates the rationale of the desired functionality. Good programming also satisfies an aesthetic sense of accomplishment; the elegance of a good program is comparable to time-tested poems or the black-and-white photographs of a bygone era. In short, programming differs from good programming like crayon sketches in a diner from oil paintings in a museum.

No, this book won’t turn anyone into a master painter. But, we would not have spent fifteen years writing this edition if we didn’t believe that everyone can design programs and everyone can experience the satisfaction that comes with creative design.

Indeed, we go even further and argue that program design—but not programming—deserves the same role in a liberal-arts education as mathematics and language skills.

A student of design who never touches a program again will still pick up universally useful problem-solving skills, experience a deeply creative activity, and learn to appreciate a new form of aesthetic. The rest of this preface explains in detail what we mean with “systematic design,” who benefits in what manner, and how we go about teaching it all.

For more details on "System Program Design" means in practise, see the last section of the preface. https://htdp.org/2018-01-06/Book/part_preface.html

marai22• 3 years ago

I read this book when I was learning functional programming. Since I started learning fp with Haskell, I couldn't figure out in the beginning how you create any meaningful programs with it. All I had were small toy programming problems from the Haskell book I was reading. This book hand-held me through learning fp and the two things that, for me, helped connect the dots were the Space Invaders type game that you build in one of the chapters of HTDP2 and Scott Wlaschin's Domain Modeling Made Functional by Scott Wlaschin. The Space Invaders game showed me how you can create a bigger program that actually is of moderate complexity by composing little functions together!

However the book is an introductory book, so there is a lot of basic stuff if you already know programming.

JustSomeNobody• 3 years ago

I love the look of scribble docs. I don't really use Racket though. Are there alternatives that anyone knows about that have this look?

wodenokoto• 3 years ago

The copyright says 2014, the foreword says they spent 15 years on the 2nd edition since 1995-2000.

It also says it was released the 6th of March 2023

So is it new or not?

tjr• 3 years ago

I remember the 2nd edition coming out in printed form years ago.

Perhaps there was some update in March of 2023, or perhaps this particular set of HTML files was published in March, but overall, the book has been out for a while.

marai22• 3 years ago

There is a version number at the top: "v8.8.0.8". I believe they keep making updates to the book probably to fix typos/errata. The original link I had bookmarked https://htdp.org/2018-01-06/Book/index.html and this one look mostly the same - content wise.

But it would be nice if there was a CHANGES file or description about what does change between these versions.

photochemsyn• 3 years ago

I think this approach to the issue of 'what language to start with' has a serious flaw for basic programming instruction:

"Our solution is to start with our own tailor-made teaching language, dubbed “Beginning Student Language” or BSL."

The only time the use of a toy language makes sense is if you're learning how to create a programming language in the context of understanding compilers, e.g.

https://llvm.org/docs/tutorial/MyFirstLanguageFrontend/index...

Otherwise it's doing the students a disservice as they'll never use the language again and will have to relearn a whole new syntax later on. It's also far better to learn in a widely used language because there will be a wide variety of resources that can help you solve simple problems (and this is even more true in the era of ChatGPT).

The argument that a simplified language makes it easier for students to grasp high-level concepts doesn't work either: instead just use a restricted well-defined subset of a language like C, C++, Java, Python, Javascript - and explain to the students the rationale for doing so.

Athas• 3 years ago

I thought BSL was a subset of Scheme, so it avoids most of those problems you mention. Or do I misremember?

jxy• 3 years ago

They should have just used standard R7RS small. Creating a variant only serves more confusion.

soegaard5• 3 years ago

It's not one "toy" language. It's a series of languages that becomes gradually larger. It has the exact same syntax and semantics as the "real" Racket.

If a language is small, the compiler can give very precise beginner friendly error messages. I'll call someone who has programmed one or two weeks for a beginner.

As an example, in the beginner language all function calls begins with a name, so `((foo) 42)` gives an error message, that says function calls must start with a name. Note that beginners often use too many parentheses.

Later on when first order functions are introduced, the call `(foo)` might return a function, so `((foo) 42)` is okay. The beginner friendly "function call must start with a name" message is now no longer true.

There are four language levels used in the book - and they follow the progression in the book.

soegaard5• 3 years ago

An experience report "On teaching how to design programs" from Norman Ramsey.

https://www.cs.tufts.edu/~nr/pubs/htdp.pdf

I am quoting section 4.1.

For over ﬁfteen years I have taught programming languages using little languages (Kamin 1990; Ramsey 2016). With this experience as background, I cannot praise the Racket teaching languages highly enough. The language design is lapidary. I was especially impressed that functions in Beginning Student Language may not have local variables. At ﬁrst I thought this restriction was crazy, but after observing students at work, I see that not only is the language simpliﬁed, 7 but without local variables, students are nudged to create helper functions—a notorious point of difﬁculty for beginning students

taeric2• 3 years ago

I'm tempted to say that, at large, every program is already a de facto toy language. Worse, they are often toy taxonomies. Nowadays, they are often toy algebras.

Which is a disservice to all of them. They aren't toys. They are models. You can either do the model at the level of the language, or at the level of the constructs the language gives you. Starting users off with fewer constructs helps them stay free of the distractions that come with them.

cardanome• 3 years ago

Otherwise it's doing the students a disservice as they'll never use the language again and will have to relearn a whole new syntax later on.

They will have to to learn many new syntax in their career so that is a good start.

I never understood some people acting as if syntax were a big hurdle. Do people really need more than a few hours to learn a new syntax? From APL to C to Haskell to Lisp, I can't ever remember struggling with the syntax of a language.

It's also far better to learn in a widely used language because there will be a wide variety of resources that can help you solve simple problems (and this is even more true in the era of ChatGPT).

This can be a pro and a con. While students should learn how to use publicly available information form search engines, stack overflow and so on, it can also be valuable to teach them ways of not having to rely on them. Learning to read proper technical documentation and working you way through a problem without had-holding is a great skill.

That said, shere is an good argument for using a "real-world" languages for teaching though: Studends will be be more motivated to learn them. Getting them interested in a "toy" language is just a hard sell. Motivation is what determines learning success more than having a technically perfect learning path.

kqr3• 3 years ago

Yes, for beginner programmers syntax is a huge deal. Sticking to something consistent as one starts out prevents conflating variations of design (encapsulation, coherence, atomicity) with variations of punctuation.

carapace• 3 years ago

Bit of a tangent but it seems to me that the talking, self-programming computers will make questions like 'what language to start with' completely obsolete.

When I read the title I thought, "You're writing this for the AIs now." as in the machines are the target audience ( since human programmers will no longer need to design programs, not more than once anyway.)

rozap• 3 years ago

It's not hard to learn a new language. It is hard for a complete beginner to get hung up on all the warts of C++.

todd8• 3 years ago

There's a lot of speculation about the approach used by this book to teach programming. It's the book that my own daughter used as a freshman in college. It was her first programming class, and she ended up deciding to major in CS.

The programming language taught in this book is Scheme. Students are introduced to programming concepts and language features gradually and the assignments are intended to be implemented using a growing subset of Scheme features as the students learn the language. By the end of the semester my daughter was familiar with much of Scheme and was comfortable with subjects like recursion, lambda functions, list handling, map functions, and closures. I'm not sure but I don't believe that she learned about continuations or macros.

Some comments mention the "toy" languages used in the book, but these aren't really toys, just subsets of Scheme that provide guard rails to keep the students from wandering into parts of Scheme that they haven't yet learned.

Another notable feature of the How to Design Programs 2nd Edition is its introduction of a defined sequence of steps for breaking a problem down into parts that are implemented as collection of functions that make up the solution.

How to Design Programs 2nd Edition

Related Stories