Less Wrong Than Yesterday

On Rich Hickey's "Maybe Not"

Typically, there is controversy around this talk. I thought it was interesting. I like the distinction between schema and selection. I think the idea of selecting down into a tree is promising, and it'll be interesting to see how it works out in practice.

However, had I been asked, I would have suggested some improvements based on things I've absorbed as an outsider to static typing who started with, roughly, Hickey's biases. None of them would weaken the technical point of the talk, just its positioning of the work with respect to other people's. I think that positioning is misleading.

Continue Reading...

Tinkerable Software

This is a post I wrote for Software Testing and Quality Engineering magazine (now https://www.stickyminds.com) and subsequently published on a long-defunct site of mine. Laurent Bossavit asked that I recreate the web version. It was originally published in 2001.

Last night, I dreamt we'd just bought a new house, my ideal house: enough bedrooms, a nice lawn, fully furnished, the works.

The first thing I noticed was that some electrical outlets weren't in the right place. Not being handy with electrical work, I found an electrician in the phone book and called him in. He set to

Continue Reading...

On designing with sum and product types

I understand product types in statically-typed FP languages; they're records:

I understand sum (or union) types; they're cool:

As I learn Elm, I'm been having considerable trouble combining the two: should I model the problem as a sum type inside a record? as records in a sum type? For a good while in my Eecrit project, I bounced around alternatives like these:

The worst part was that I was developing iteratively, and new features kept breaking my model: I didn't find my design converging in the way that I'm used to from TDD and dynamic languages (be they OO like

Continue Reading...

Phoenix, Elm, and multiple single-page apps

In the running example used in Programming Phoenix, client-side apps are launched from the master app.js file. The Javascript that's loaded for every page checks to see whether this page has the id it's looking for. If so, the code to launch the app is run.

That's fine for the book, as it avoids irrelevant complexity, but I found it awkward as my overall app grew. Multiple clauses of this form:

const ivDiv = document.querySelector('#iv-target');  
if (ivDiv) {  
    Elm.IV.embed(ivDiv);
}

... are untidy. I'd rather have the "start the client-side" code exist only on the single page

Continue Reading...

Customizing `mix phoenix.gen.*` tasks

Because I am who I am, I've deviated from some default Phoenix file layouts. For example, rather than models having a single changeset function with two parameters you combine in different ways, I've tentatively decided I'd rather have variants like new_action_changeset, create_action_changeset, update_action_changeset, etc. That means a model should start out looking like this:

Similar changes are needed in the controller - and in model tests - and in controller tests. It would be tedious to run the default mix.phoenix.html task and then edit those files to support my quirkiness, so I

Continue Reading...