undefined | Better HN

0 pointstroad1mo ago0 comments

I just don't think I have the misunderstanding that you think I do. I spent most of my programming career working in statically typed systems, including two years in Rust recently. Nothing in that article is new or surprising to me. Some of it is downright elementary.

If I may be so bold, I'd posit the misunderstanding is on your part. No one is saying things are impossible to model in rigidly typed systems - this is your key misapprehension about what is being said. What I'm saying is that different languages have different paths of desire, and the kinds of problems identified in the original article are more the kind of problems that tend to crop up with heavy use of types, than they are the kind of problem that has much of anything to do with functional programming.

You're thinking categorically, but I am not, so we're talking at cross-purposes. Perhaps too much static typing has crept into your thinking! (I jest, of course! :) )

0 comments

yakshaving_jgt1mo ago

If that's the case, then yes I think we're talking past each other. Although it's hard to square this with the argument you've been making — 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. The whole thrust of King's article is that this is a mischaracterization.

> What I'm saying is that different languages have different paths of desire, and the kinds of problems identified in the original article are more the kind of problems that tend to crop up with heavy use of types, than they are the kind of problem that has much of anything to do with functional programming.

I don't think this is correct at all. I don't think TFA has anything at all to do with types or FP (despite the clickbaity title), as numerous other people here have already pointed out. The article isn't attacking rigid types. The author's point is that no single-program analysis — typed or untyped — covers the version boundary (or system boundaries more generally).

A Haskell service that receives an unknown enum variant doesn't have to crash — you parse the cases you care about and ignore the rest. The "path of desire" you're describing isn't a property of the language.

I suppose "path of desire" here is a matter of opinion. In my experience, crashing on unknown inputs is not idiomatic Haskell, nor is it desirable.

troadOP1mo ago

> 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.

yakshaving_jgt1mo ago

> 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.

I agree with neither of these points.

1 more reply

j / k navigate · click thread line to collapse

0 pointstroad1mo ago0 comments

You're thinking categorically, but I am not, so we're talking at cross-purposes. Perhaps too much static typing has crept into your thinking! (I jest, of course! :) )

0 comments

yakshaving_jgt1mo ago

I suppose "path of desire" here is a matter of opinion. In my experience, crashing on unknown inputs is not idiomatic Haskell, nor is it desirable.

troadOP1mo ago

> 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.

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.

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.

yakshaving_jgt1mo ago

> 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.

I agree with neither of these points.

1 more reply

j / k navigate · click thread line to collapse