5 ms·

For me the biggest advantage of FP languages is exactly not have to deal with `GenericConverter`s, `AbstractDTO`s, `BaseEntity`s and other overly-complex constr

by islon 10y ago

For me the biggest advantage of FP languages is exactly not have to deal with `GenericConverter`s, `AbstractDTO`s, `BaseEntity`s and other overly-complex constructs that many OO languages inflict upon the programmer, but to create a small and simple sub-language that solves my problem without making it even more complex.

catnaroek 10y ago
When you really think about it, Haskell's mathematically inspired type classes are more or less the equivalent of Java's “`GenericConverter`s, `AbstractDTO`s and `BaseEntity`s”. The main difference is that their meaning is given by algebraic laws, rather than informally specified design patterns or fuzzy human intuitions about how “objects” interact with each other.
acjohnson55 10y ago
Sounds basically like the Kingdom of Nouns argument: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
kozikow 10y ago
You can horribly engineer things, regardless if you use haskell or Java. I've seen Java code like you described, but I've also seen big java projects written in clear, no-nonsense style. For example, look at any open source Java projects released by Google. I've also seen FP projects that require all engineers to learn category theory. Even when armed with programmers proficient in FP, project did not seem significantly more productive or less buggy from the outside. The approach-ability was lower - you couldn't just quickly glance how something works, even if you knew FP. The most successful approaches I have seen involved adapting good functional concepts - referential transparency, immutability, compos-ability, minimising local state, functions as objects. They rarely went dogmatically all-in on pure-FP/category-theory/DSL-all-the-things. I strive to write code adhering to those rules, even in non-FP languages, but ultimately favouring practicality and I believe that I get the best of both sides.

by islon 10y ago

catnaroek 10y ago

When you really think about it, Haskell's mathematically inspired type classes are more or less the equivalent of Java's “`GenericConverter`s, `AbstractDTO`s and `BaseEntity`s”. The main difference is that their meaning is given by algebraic laws, rather than informally specified design patterns or fuzzy human intuitions about how “objects” interact with each other.

acjohnson55 10y ago

Sounds basically like the Kingdom of Nouns argument: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

kozikow 10y ago

You can horribly engineer things, regardless if you use haskell or Java. I've seen Java code like you described, but I've also seen big java projects written in clear, no-nonsense style. For example, look at any open source Java projects released by Google. I've also seen FP projects that require all engineers to learn category theory. Even when armed with programmers proficient in FP, project did not seem significantly more productive or less buggy from the outside. The approach-ability was lower - you couldn't just quickly glance how something works, even if you knew FP. The most successful approaches I have seen involved adapting good functional concepts - referential transparency, immutability, compos-ability, minimising local state, functions as objects. They rarely went dogmatically all-in on pure-FP/category-theory/DSL-all-the-things. I strive to write code adhering to those rules, even in non-FP languages, but ultimately favouring practicality and I believe that I get the best of both sides.