4 ms·
A simple thing like a DNS resolve is much simpler in non FP. FP shines when it's more complex, but not when it's simple. I find Go-lang a reasonable crossover w
by isodude 7y ago
A simple thing like a DNS resolve is much simpler in non FP. FP shines when it's more complex, but not when it's simple. I find Go-lang a reasonable crossover where you could do a lot of FP in it where it is needed and keep it simple and boring in the rest.
It's like me as an engineer: Don't use me for simple tasks because I will make them really complex.
- apta 7y ago> I find Go-lang a reasonable crossover where you could do a lot of FP in it When people talk about FP, they usually include things like pattern matching and generics, none of which golang has. Not to mention it actively prohibits chaining functions that return errors because of the botched way it decided to handle errors as a product type instead of the correct way as sum type. golang is a very imperative language with very little going for it.
- isodude 7y agoAgreed, it's still relatively possible to invent stuff that is missing though. It will grow :)
- apta 7y agoNot without having a proper way to handle errors, and generics at the very least.
- n4r9 7y agotbh if you have the ability to easily treat functions as first class citizens in a language then it's fair enough to say you can code functionally in it. I think the attitude "X is inherently a functional language" is being replaced by the idea that there are clusters of language properties with labels like "functional" or "object-oriented" or "array-based" or whatever, and that a language may overlap with bits of various clusters to a greater or lesser degree.
- itsbruce 7y agoThere's more to the admittedly fuzzy-edged concept of functional programming than function application. I'd agree with you that the feature list is more important than a vaguer title. That's something Robet Harper talks about: http://www.cambridgeblog.org/2017/05/what-if-anything-is-a-programming-paradigm/ http://www.cambridgeblog.org/2017/05/what-if-anything-is-a-p... But the selection of features has limited value if the selection isn't coherent and the features don't compose. Within both FP and OOP there are languages whose design choices represent coherent choices with synergy... and ones that don't. Go's feature set doesn't provide that coherence and synergy for functional abstractions. Frankly, it's an awkward obstacle in that direction. Beyond that, its feature set is deliberately designed to place arbitrary limits on abstraction.
- n4r9 7y agoThanks, this is a measured response that's made me think a little deeper and refine my opinions.