Real problems with functional languages(medium.com)
medium.com
Real problems with functional languages
https://medium.com/darklang/real-problems-with-functional-languages-efe668c5264a
6 comments
https://outline.com/mu3Vwk - same article, but without "Pardon the interruptions" nags from Medium
The leadPlayer() and chooseCaptain() example is not so good. My first instinct, as a DYNAMIC programmer, is "Why the hell is chooseCaptain() fed an empty list? You can't have a team with no players!" I think the article's proposed fix is painting over the real bug.
There is an interesting idea here but I'd like to see more details about how they handled the tricky bits:
"The way this works is that you don’t actually change types in Dark. Instead, you make a copy of the type, and make your changes on that new copy. This allows you to prototype with the new type and test your change easily, making cheap iterations (and new types) as you try out new ideas. Once you are confident in your new type, you replace the uses of the old type (with semi-automated tooling to handle all the changes, including changes that are way down the call-stack)."
If both types exist at once, there are going to be function calls where the old type needs to be converted to the new type, or vice-versa. What happens there?
"The way this works is that you don’t actually change types in Dark. Instead, you make a copy of the type, and make your changes on that new copy. This allows you to prototype with the new type and test your change easily, making cheap iterations (and new types) as you try out new ideas. Once you are confident in your new type, you replace the uses of the old type (with semi-automated tooling to handle all the changes, including changes that are way down the call-stack)."
If both types exist at once, there are going to be function calls where the old type needs to be converted to the new type, or vice-versa. What happens there?
Author here. That's an open question, since we haven't been using this enough to see what people need or how it plays out. My hypothesis is that we'll need editor tooling to propagate the changes easily for you, including potentially adding the conversion functions (which we may be able to create automatically or semi-automatically).
Similar to this line:
"In most FP compilers, your whole program either compiles or it doesn’t, making it difficult to make small scale changes. If I’m programming in Python, and I want to test out a quick hacky change in some component, I can do that immediately to discover whether the hack will even solve my problem."
Strikes me as an intriguing pragmatism. The language seems tightly coupled to an upcoming editor and possibly even http framework. Hopefully it's good enough to justify that lock in and flexible enough that cli scripts, thrift / grpc, etc remain possible
"In most FP compilers, your whole program either compiles or it doesn’t, making it difficult to make small scale changes. If I’m programming in Python, and I want to test out a quick hacky change in some component, I can do that immediately to discover whether the hack will even solve my problem."
Strikes me as an intriguing pragmatism. The language seems tightly coupled to an upcoming editor and possibly even http framework. Hopefully it's good enough to justify that lock in and flexible enough that cli scripts, thrift / grpc, etc remain possible
I never used it but I think hole types are used to inverse the "burden of proof". You write your changes with holes and let the type checker guide you into completing the logic.
Misleading post. Bait and switch in action. The important part of the title is in small script. Probably I wouldn’t have clicked on it otherwise ️
This is Hacker News taking things out of context. Some titles aren't intended to be standalone.
Tiresome.