In Praise of Exhaustive Destructuring

In Praise of Exhaustive Destructuring(antoine.vandecreme.net)

19 points by avandecreme 5 days ago | 5 comments

The dangerous weather example seems like a poor example. Most fields I would add would be orthogonal to existing functionality, and if they weren't, I would account for things I need to change (e.g. the is dangerous function) during the specification phase.

As an example of what I mean: The spec for "is dangerous" would have specified what "dangerous" means, and if that included high speeds, then that would have been known in advance when I made a plan to implement the speed feature.

The reason I mention this is that agentic coding seems to be requiring us to move to "spec-driven development" and it behooves us all to learn how best to adapt to this new landscape.

A simple example of an inline spec (i.e., a spec living as a comment in the code file, a bit like literate programming) for "is dangerous" would be something like:

    /*
     * dangerous = anything that would cause a risk of getting hurt for a healthy adult, e.g. heat stroke, lightning strike, hypothermia, gale force wind, flood, hurricane, tsunami, earthquake
     * Not all of this is implemented now, but that is what this function should try to do.
     */

jasim 2 hours ago | |

But couple that with a deterministic system - the type checker with exhaustive destructing (and pattern matching, while we are it it) - that would become a fool-proof combination.

healthworker 2 hours ago | | |

Agreed. As long as we understand that the map (the code) is not the territory (the spirit of what the code should do), e.g., I can't have type-checking for earthquake if I don't have any earthquake-related concepts in the code yet, but earthquake could and should still be part of the aspirational aspect of the inline spec.