Re:Please do not attempt to simplify this code
by weberc2 on Friday December 28, 2018 @09:58AM
(#18777044)
Even experiences FP folks complain about how difficult it is to program in Haskell due to its purity. Further, the high barrier to entry you describe is an even bigger deal to organizations than to individuals. It’s a cost that needs to be paid for every employee. And it’s not just the language features, but FP languages tend to have issues like poor documentation, poor editor integrations, multiple standard libraries, multiple build tools, multiple string types, home-grown project file syntax, multiple preludes, many extensions, etc. All of these boost the learning curve in addition to the issues with the language itself.
[ Parent
| on HN ]
Re:Please do not attempt to simplify this code
by allemagne on Friday December 28, 2018 @12:11PM
(#18777968)
In my limited experience with functional programming, I've come away with the impression that the problems you're describing are why you don't see a lot of companies that use FP exclusively.
But I think the advantages that OP is lauding are also there, and "space shuttle code" might just be where it shines. Reading that comment in this post made me immediately think of Haskell. The Clojure components at my company fits the "space shuttle" description of importance, and its dependability is striking compared to the rest of our code. Part of it may be that being written in a different language allows its concerns to be separate from the rest of the application too, but I do think the FP paradigm is simply good in this domain.
Re:Please do not attempt to simplify this code
by weberc2 on Friday December 28, 2018 @12:37PM
(#18778139)
Sure, but I doubt all of Kubernetes is written in this style, so it’s probably not worth writing everything in Haskell. Note also that there’s nothing about FP that prohibits it from addressing the aforementioned practical problems. Some Haskell-like could swoop in and totally steal Go’s lunch if they would simply prioritize practicality over experimentation.
Re:Please do not attempt to simplify this code
by bb88 on Saturday December 29, 2018 @02:50AM
(#18782529)
> Some Haskell-like could swoop in and totally steal Go’s lunch if they would simply prioritize practicality over experimentation.
I don't know. It seems like it would be easy enough to build an AST to make sure there were no unknown conditions that didn't lead to a return statement.
Re:Please do not attempt to simplify this code
by weberc2 on Saturday December 29, 2018 @09:24AM
(#18783685)
I don’t understand how your post relates to mine. I was saying that if a static functional language focused more on simplicity, readability, good tooling and documentation, etc then it would eat Go’s lunch without trading off any of Haskell’s important characteristics (I.e., robust type safety).