4 ms·

This is one of the reason I think FP is better than OOP for business development. You can still have entities (that are plain maps, possibly annotated with typ

by m45t3r 6y ago

This is one of the reason I think FP is better than OOP for business development. You can still have entities (that are plain maps, possibly annotated with types so you can keep your sanity), but the business logic now works with simple data structures: you input some data and gets another more data back. Do this transformation a few more times and very complex business requirements can be expressed. Testing is also easy since most functions are pure. Now you need to transform the data? Ok, convert this data to another data format and pass it to serializer. Same thing for deserializing. Traditional OOP really makes this last step more complicated than it should, since now you have an object, and the object should be opaque so you don't leak implementation details. To serializer you possible have a complex hierarchy of objects so your serializing logic is more complex too. Of course OOP doesn't need to do this, but the FP model seems so much simpler to enforce this data processing part.

monsieurbanana 6y ago
I'm not so sure whether this is truly a benefit of FP. Is it the same in languages like haskell or ocaml? (haven't used them in any significant way) As for clojure, it's described as a "data-driven programming", which is almost as important as it's FP designation. I think it's that data-driven part that brings a lot of the benefits you're talking about.
- mrkeen 6y ago
  Yes, smooth sailing in Haskell. Define the datatype and let GHC generics and the Aeson library handle the rest. The worst-case scenario is when keys in your JSON conflict with keywords or existing functions: 'id' and 'data' are pretty common. It means you need to rename your datatype fields to something like '_id' and '_data', and provide a mapping function to Aeson. Where the 'fully automatic' declaration looks like: instance FromJSON Coord The declaration where you remap to avoid name clashes could look like: instance FromJSON Coord where parseJSON = genericParseJSON defaultOptions { fieldLabelModifier = dropWhile (=='_') }
- m45t3r 6y ago
  > I'm not so sure whether this is truly a benefit of FP. Yeah, it is not. But like pure functions (that are also not necessary something from FP, you can have pure functions in probably any language out there), it is easier to apply in FP and also more idiomatic there. Like, you can simply generate a map or dict in most languages and have it transformed and converted in most languages out there, but once things gets complicated probably someone somewhere will say in a Pull Request "this is not the idiomatic way in OOP, you should create a data object and store this data there" and blah blah blah. FP doesn't have this kinda of baggage.

by m45t3r 6y ago

monsieurbanana 6y ago

I'm not so sure whether this is truly a benefit of FP. Is it the same in languages like haskell or ocaml? (haven't used them in any significant way) As for clojure, it's described as a "data-driven programming", which is almost as important as it's FP designation. I think it's that data-driven part that brings a lot of the benefits you're talking about.

mrkeen 6y ago
Yes, smooth sailing in Haskell. Define the datatype and let GHC generics and the Aeson library handle the rest. The worst-case scenario is when keys in your JSON conflict with keywords or existing functions: 'id' and 'data' are pretty common. It means you need to rename your datatype fields to something like '_id' and '_data', and provide a mapping function to Aeson. Where the 'fully automatic' declaration looks like: instance FromJSON Coord The declaration where you remap to avoid name clashes could look like: instance FromJSON Coord where parseJSON = genericParseJSON defaultOptions { fieldLabelModifier = dropWhile (=='_') }
m45t3r 6y ago
> I'm not so sure whether this is truly a benefit of FP. Yeah, it is not. But like pure functions (that are also not necessary something from FP, you can have pure functions in probably any language out there), it is easier to apply in FP and also more idiomatic there. Like, you can simply generate a map or dict in most languages and have it transformed and converted in most languages out there, but once things gets complicated probably someone somewhere will say in a Pull Request "this is not the idiomatic way in OOP, you should create a data object and store this data there" and blah blah blah. FP doesn't have this kinda of baggage.