I used to be a die-hard destructurer! I liked the readability aspect, but ultimately two core problems emerged that pushed me towards dot-accessors:
1. It's highly verbose, especially in a language like TypeScript where you're often defining properties in types and then destructuring the same properties, making the whole thing look quite duplicative.
2. If you're passing an object through different functions doing similar things, I would quite often have to rename a destructured property in TypeScript because I would want to reuse the same name in a function-scoped variable.
I think for exhaustive switches, destructuring can be fine, but in general as long as you've got a well-defined set of types backing everything up, dot-access is neater.
--
Also on the point about optional parameters:
> let's suppose some stations now have an anemometer and are able to record wind speed
I find that discriminated unions are so much better at dealing with these kinds of problems. Also tends to work better with dot-access because you're not then destructuring undefined properties.
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.
*/
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.
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.
We might be moving towards putting more intent - in text - into the code itself, for agents. We should've been doing that for other humans in the past, but it wasn't always encouraged - "code should be self-explanatory, and comments are a sign of poor naming and abstraction", and all that.
These days I run a prompt of this shape to ensure that my code contains as much tacit knowledge as I have -- "I want to make sure all the implicit invariants and structures and concepts described in these plans, are present in the code comments, namings, comments around major types and modules. So even if the original plan file is not present, we should still be able to understand it (Peter Naur - Programming is Theory Building)"
However - I still need the type system as another preserver of invariants and intents. Coding agents still make subtle mistakes and miss very obvious things as the code gets more intricate and conceptually large.
A type error where an expected case is not handled - that is a feedback that can ground it back and force it to think through whether windspeed matters to is_dangerous or not. And the choice of is_dangerous in the article is a bit misleading, because anyone can at first read make the connection from windspeed to is_dangerous. It is a pretty bold variable name and attention grabbing situation.
However codebases are made of far more mundane but widespread and braided sets of tiny invariants that wouldn't catch either a human's or a coding agent's attention without needing a more firmer hand, and so I still do love my type systems despite my best laid comments.
I used to be a die-hard destructurer! I liked the readability aspect, but ultimately two core problems emerged that pushed me towards dot-accessors:
1. It's highly verbose, especially in a language like TypeScript where you're often defining properties in types and then destructuring the same properties, making the whole thing look quite duplicative.
2. If you're passing an object through different functions doing similar things, I would quite often have to rename a destructured property in TypeScript because I would want to reuse the same name in a function-scoped variable.
I think for exhaustive switches, destructuring can be fine, but in general as long as you've got a well-defined set of types backing everything up, dot-access is neater.
--
Also on the point about optional parameters:
> let's suppose some stations now have an anemometer and are able to record wind speed
I find that discriminated unions are so much better at dealing with these kinds of problems. Also tends to work better with dot-access because you're not then destructuring undefined properties.
Rust has it own limitations making destructure to be not the only option.
So Rust has work in progress to improve.
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:
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.
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.
We might be moving towards putting more intent - in text - into the code itself, for agents. We should've been doing that for other humans in the past, but it wasn't always encouraged - "code should be self-explanatory, and comments are a sign of poor naming and abstraction", and all that.
These days I run a prompt of this shape to ensure that my code contains as much tacit knowledge as I have -- "I want to make sure all the implicit invariants and structures and concepts described in these plans, are present in the code comments, namings, comments around major types and modules. So even if the original plan file is not present, we should still be able to understand it (Peter Naur - Programming is Theory Building)"
However - I still need the type system as another preserver of invariants and intents. Coding agents still make subtle mistakes and miss very obvious things as the code gets more intricate and conceptually large.
A type error where an expected case is not handled - that is a feedback that can ground it back and force it to think through whether windspeed matters to is_dangerous or not. And the choice of is_dangerous in the article is a bit misleading, because anyone can at first read make the connection from windspeed to is_dangerous. It is a pretty bold variable name and attention grabbing situation.
However codebases are made of far more mundane but widespread and braided sets of tiny invariants that wouldn't catch either a human's or a coding agent's attention without needing a more firmer hand, and so I still do love my type systems despite my best laid comments.
I think your comment is more persuasive than the original article. =)
[dead]