I've spent the past month in the mountains in Ukraine, and it's been as low as -18ºC at times. Terrorists from russia have repeatedly knocked out power generation, and so on many days we have very little access to electricity in the house. Today we have 15.5 hours without power.
During the day, we'll be somewhere where they have a generator. At night, it's cold. But you can somewhat prepare for this. Two or three layers of duvets and blankets, paired with a hot water bottle somewhere in the middle of the bed under the covers will get you through the night.
> static types are not about “classifying the world” or pinning down the structure of every value in a system. The reality is that static type systems allow specifying exactly how much a component needs to know about the structure of its inputs, and conversely, how much it doesn’t.
That's an insular opinion piece that doesn't sway, especially in the age of AI agents, it has not aged well. Its shallow rejection of Rich Hickey's nuance, is also unconvincing. It is a polemical justification for a coding philosophy that is incomplete and dishonest about the benefits of alternatives. Thanks for reminding me that no one cares; important to reinforce that.
That's quite the shallow dismissal, and the bit about AI agents is a particularly weird non sequitur — King's argument is about what type systems can and cannot express. AI agents don't change the relationship between static types and open-world data processing.
It sounds like you're annoyed that Hickey's position was effectively challenged.
It's a design choice more than anything. Haskell's type safety is opt-in — the programmer has to actually choose to properly leverage the type system and design their program this way.
> In practice, much of the article seems to be about the problems introduced by rigid typing … But that's a non-issue in the FP languages mentioned above since they tend towards the use of unstructured data
Haskell doesn’t have this problem. None of the “rigid typing” languages have this problem.
You are in complete control of how strictly or how leniently you parse values. If you want to derive a parser for a domain-specific type, you can. If you want to write one, you can. If you want to parse values into more generic types, you can.
This is one of those fundamental misunderstandings that too many programmers have, and it seems like it’ll never die.
But naturally the more you type, the more benefits and costs you accrue associated with typing. I'm not sure what the misunderstanding is. Of course you could write a C program entirely comprised of void*, but why would you? Equally, of course you could write a Clojure program with rigid type enforcement, but again, why would you? You're fighting against the strengths of your tools.
You don't pick up Haskell just to spend all your time passing around unstructured data, any more than you opt into the overhead of TS just so you can declare everything as `any`.
> You do not understand how typing works in Haskell.
Possible! But a little hyperbolic, perhaps. I think we're more likely to be talking past one another.
> You are free to work with primitives as much as you like.
Sure, but what's the point? If all of your functions are annotated as `myFun :: a -> b`, where a and b are arbitrary type variables, why are you writing Haskell? You're effectively writing Ruby with extra steps. You're nether getting the benefits of your rigidly typed language, nor the convenience of a language designed around dynamism.
Yes, ML-esque type systems are quite neat and flexible. But the more granular the typing you opt into, the more of the usual cost of typing you incur. Typing has inherent cost (and benefit!). And if you're not into the typing, ML-esque typed languages are a curious tool choice.
So to return to the original point, if you're passing data around in Haskell, you have more likely than not opted into some level of typing for that data - else why use Haskell - and will run into the exact issues with rigid type systems mentioned above. Can you parse and type cast and convert and what not? Sure. But no-one ever said that you couldn't, and that's precisely the busywork that dynamic languages are generally designed to lead you away from.
> Possible! But a little hyperbolic, perhaps. I think we're more likely to be talking past one another.
Direct, certainly. More than would be typically expected socially. But I don't think it's hyperbolic — I think there is genuine fundamental misunderstanding here.
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! :) )
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.
> 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.
We're running GitHub Actions. It's good. All the real logic is in Nix, and we mostly use our own runners. The rest of the UI that GitHub Actions provides is very nice.
We previously used a CI vendor which specialised in building Nix projects. We wanted to like it, but it was really clunky. GitHub Actions was a significant quality of life improvement for us.
None of my colleagues have died. GitHub Actions is not killing my engineering team at any rate.
During the day, we'll be somewhere where they have a generator. At night, it's cold. But you can somewhat prepare for this. Two or three layers of duvets and blankets, paired with a hot water bottle somewhere in the middle of the bed under the covers will get you through the night.
reply