An Update On Typed Racket For HtDP

I was hopeful in my switching to Typed Racket for the rest of my time with HtDP; hopeful that it would give me practice in creating more robust programs with static type checking. That it did—and this was good, valuable practice—but my pace became glacial and my motivation faltered.

In beginning to use Typed Racket I sought to refactor previous exercise solutions for practice before continuing on to those I was yet to encounter. It took me around seven hours to refactor exercises 161-170 to use Typed Racket and a further seven hours to create solutions to exercises 171-174. I’m happy with these few, they’re well-tested and the tests are well-organised into suites. Combined with the static type checking, they are robust solutions that I enjoyed creating. Their quality is well above my prior solutions. Perhaps, however, their quality is too high, considering they are just exercise solutions.

Continuing at this pace for the remaining 354 of the total 528 exercises would see me taking hundreds of additional hours to make my way through the book, compared to if I were to create more minimal solutions. Which, of course, would mean a great delay in exposure to an enhanced design recipe and the more advanced concepts later discussed. While I still believe that the practice of developing such solutions remains valuable, I suspect this exposure without delay would be more valuable.

My closing remark in the original article remains true: for my programs I would prefer static typing. Though I see these now not as programs but as they truly are—exercise solutions that need no such rigour—so I will be returning to my prior small deviations from the teaching languages so that I can keep to the book’s core lessons.