Re:Real problems with functional languages
by np_tedious on Saturday June 29, 2019 @09:33AM
(#20312468)
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
Re:Real problems with functional languages
by agumonkey on Saturday June 29, 2019 @09:43AM
(#20312519)
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.
"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