Real problems with functional languages

Post by agumonkey » Sat, Jun 29, 2019, 1:43 PM UTC

np_tedious wrote: post #10

skybrian wrote: post #8

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 i…

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 an…

Post by pbiggar » Sun, Jun 30, 2019, 5:17 PM UTC

skybrian wrote: post #8

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 i…