Thread by @ShriramKMurthi

1/n Over the months we've gotten several questions about how our new book, DCIC [dcic-world.org], relates to HtDP (How to Design Programs). They are deeply similar, but even from 30K feet there are some salient differences. A thread on how they compare. 🧵

2/n At a high level they are very similar. Both are built around the centrality of data structure. Both want to provide methods for designing programs. Both start with functional programming but transition to (and take very seriously) state/imperative. ↵

3/n Both are built around languages carefully designed with education in mind. Yes to special support for writing examples & tests; error reporting designed for beginners; built-in images, reactivity; no to weird language gotchas. Etc. Always, put the student first. ↵

4/n To call these "similarities" is, of course, a profound disservice. HtDP often pioneered these things; DCIC copied them.

Now for the differences. Note that they are differences TODAY. Some ideas from DCIC are going to HtDP, and over time more may intermingle. ↵

5/n The most obvious is that DCIC is in @PyretLang. HtDP has tons of good ideas, all ignored because of *syntax*. We built Pyret to embody good ideas we'd learned from @racketlang student languages and other good ideas of our own, but package it in a familiar syntax. ↵

6/n The next most obvious thing is that DCIC also includes Python. HtDP has a (not published) follow-up that teaches design in Java [felleisen.org/matthias/HtDC/…]. Whereas we wanted to integrate the *transition* to Python into DCIC. There's much to be learned from the contrast! ↵

7/n In particular, Pyret and its IDE were carefully designed around pedagogic ideas for teaching state. Python was not despite, the ubiquity and difficulty of state! So there's a lot to be gained, when introducing state, to contrast them. (That material is being upgraded.) ↵

8/n Next, DCIC has algorithmic content. It covers big-O. It even has a section on amortized analysis. It goes up through some graph algorithms. I cover these in my accelerated intro class; most intro courses will not touch this. That's fine, it's there for those who want it. ↵

9/n I also have notes, waiting to be converted, a few more advanced/whimsical topics for students who want to go farther. They're really for the student like me: the kind who loved the footnotes in SICP. These will be marked clearly as bonus material. ↵

10/n Okay, so those are most of the differences. They're visible (some even evident) from glancing through the book or the ToC. However, there is one very deep difference that will not be apparent to most readers. Let me explain it in the rest of this thread. ↵

11/n HtDP is built around a beautiful idea: the data structures shown grow in complexity in set-theoretic terms. So: atomic, then fixed-size (structures), then unbounded collections (lists) of atomic, pairs of lists, lists of structures, etc. Build it up bit-by-bit. ↵

12/n IMO, this has a downside. You have to *imagine* what the data represent (this num is an age, that's str a name, that list is of GDPs), but they're idealized. In a way the most real data are actually images! After that (which come early), it's all "virtualized". ↵

13/n My take is that many interesting data are lists of structures. (Remember those? They're complicated and come some ways down the progression.) You say "Huh?!?" To which I offer you another name for them: tables. Tables are ubiquitous. Even primary school kids know them. ↵

14/n Even better, lots of real-world data are provided as tables. You don't have to imagine things or make up fake GDPs like 1, 2, 3. You can get actual GDPs or populations or movie revenues or sports standings or whatever interests you. Ideally, cleansed and curated. ↵

15/n I believe that just about every child is a nascent data scientist: at least when it's convenient to them. Even an "I hate math" kid will often gladly use statistics to argue for their favorite actor or sportsperson or whatever. We just have to find what motivates them. ↵

16/n But there's a BIG catch! A key feature of HtDP is that for every level of datatype, it provides a Design Recipe for programming over that datatype. Lists-of-structs are complex. So is their programming recipe. And we want to put them near the beginning! ↵

17/n The Design Recipe is dangerous to ignore. Students struggle with blank pages and often fill them up with bad code, which they then get attached to. The DR provides structure, scaffolding, reviewability, and much more. It's cognitively grounded in schemas. ↵

18/n So over the past few years, we've been working on different program design methods that address the same ends through different means. A lot of our recent education research has been putting new foundations in place. It's very much work in progress. ↵

Many of our recent papers are related to aspects of DCIC. It's fabulous to get to do this with an amazing team: @KathiFisler @joepolitz Ben Lerner but also the @Bootstrapworld team and our Bootstrap collaborators (eg, ideas from school math ed have improved collegiate CS!). •