> if you understood King's point, I don't understand how you can be arguing that Haskell idiomatically leads you into rigidity at version boundaries
Why would understanding his argument necessarily mean finding it persuasive or exhaustive?
> you parse the cases you care about and ignore the rest
What language would not allow this?
> The "path of desire" you're describing isn't a property of the language.
If a tool tends, more often than not, to lead to certain use, is that not a property of that tool? It is theoretically possible to use a hammer for interpretive dance, sure, but it doesn't seem to happen nearly as often as banging the hammer on things.
Equally, I think it's pretty easy to see how a language designed for robust typing is going to lead to, more often than not, robust typing.
I rather think you're engaging with a point that no one ever made - that typed languages are inherently incapable of dealing with uncertain, incomplete, or variable data - in lieu of the argument that was actually made - that languages with rich DX around rigid typing encourage an architecture that's rigidly typed, and that rigidly typed codebases tend to come up against predictable issues.
The original article identities a series of such issues and misattributes them to FP, when they don't have much to do with FP at all. That's all I was saying.
> Why would understanding his argument necessarily mean finding it persuasive or exhaustive?
Alexis King is a woman.
> that languages with rich DX around rigid typing encourage an architecture that's rigidly typed, and that rigidly typed codebases tend to come up against predictable issues.
Why would understanding his argument necessarily mean finding it persuasive or exhaustive?
> you parse the cases you care about and ignore the rest
What language would not allow this?
> The "path of desire" you're describing isn't a property of the language.
If a tool tends, more often than not, to lead to certain use, is that not a property of that tool? It is theoretically possible to use a hammer for interpretive dance, sure, but it doesn't seem to happen nearly as often as banging the hammer on things.
Equally, I think it's pretty easy to see how a language designed for robust typing is going to lead to, more often than not, robust typing.
I rather think you're engaging with a point that no one ever made - that typed languages are inherently incapable of dealing with uncertain, incomplete, or variable data - in lieu of the argument that was actually made - that languages with rich DX around rigid typing encourage an architecture that's rigidly typed, and that rigidly typed codebases tend to come up against predictable issues.
The original article identities a series of such issues and misattributes them to FP, when they don't have much to do with FP at all. That's all I was saying.