Re:Why Functional Programming Matters (1984) [pdf]
by KirinDave on Thursday December 08, 2016 @10:35AM
(#13130893)
I'm not sure why we keep pretending Haskell is supposed to work well. It's half prorgramming environment, half research environment. This shows in MANY ways. And don't get me wrong, the Haskell team tries, but ...
There really isn't a serious attempt to build an industry-friendly programming language with functional features and laziness as a default. You'd make many different decisions than Haskell:
- No more language extensions, you'd fix the feature set.
- Better transparency on memory growth and GCs in tooling
- It'd be easier not to generate a ton of garbage, so the GC could be designed such that very large working sets could be handled with low latency.
- You wouldn't structure IO the way the have. Modern programs have demands for many, many side effects and threading an IO monad through every place they can touch is common practice, but not useful. A reduced power version of IO that would let developers push events to an IO-enabled functional reactor would be in the stdlib.
We shouldn't hold Haskell as the perfect expression of functional and lazy programming. It was never meant to be and it shows. It's just the tool we have right now to go to bat with.
Re:Why Functional Programming Matters (1984) [pdf]
by cousin_it on Friday December 09, 2016 @10:42AM
(#13139314)
Thanks! After your comment I finally got around to checking out PureScript, and it looks nice (aside from the crazy tooling requirements which are typical for 2016).
There really isn't a serious attempt to build an industry-friendly programming language with functional features and laziness as a default. You'd make many different decisions than Haskell:
- No more language extensions, you'd fix the feature set.
- Better transparency on memory growth and GCs in tooling
- It'd be easier not to generate a ton of garbage, so the GC could be designed such that very large working sets could be handled with low latency.
- You wouldn't structure IO the way the have. Modern programs have demands for many, many side effects and threading an IO monad through every place they can touch is common practice, but not useful. A reduced power version of IO that would let developers push events to an IO-enabled functional reactor would be in the stdlib.
- Monad Transformers would almost certainly not be included, preferring: http://lambda-the-ultimate.org/node/4786
We shouldn't hold Haskell as the perfect expression of functional and lazy programming. It was never meant to be and it shows. It's just the tool we have right now to go to bat with.