Hacker News Reader

Comment by vemv | Hacker News Reader

This problem tends not to occur in Clojure codebases because Clojure is a data-centric (vs. model-centric) language.

In other words, all our core data is expressed as json-like data (e.g. EDN), so the translation is quite trivial - basically from one format to the other.

Building a codebase around plain old data is admittedly not for everyone, but it works! You certainly can still have a type-like system (in dev/test time) and validation (in production) using the various available mechanisms (Spec, Schema, Malli).

View on HN

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.

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.

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 (=='_') }

> 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.

I've written enough Clojure over the years to think that this is probably not the case. The reason this problem doesn't happen as much with Clojure is that the Clojure data structure is closer to JSON (and when using EDN instead of JSON, is identical.) If your serialization object model is close to your in-code object model, translating between the two is easy. If your serialization object model is distant from your in-code object model, then translation becomes difficult.

You can directly serialize and deserialize plain old Java objects to and from a native format and it's trivial to do so, but serializing to and from JSON is trickier because JSON is meant to represent dynamically typed data stored in maps and lists, but Java doesn't naturally store data in that manner. Java's manner is more obtuse, but if you could be certain that both the producer and the consumer of an object was going to be Java, creating a serialization format that could be transparently used would be a straightforward task. That is, so long as both the source and target of your serialization are in the same language, the problem is a lot simpler, and if your language happens to be closer Javascript (the source of JSON) it's also relatively simpler to write a JSON parser for it.

I see more similitudes than differences in our thinkings :)

One can make the problem easier in Java by using HashMaps instead of classes, just like one could make it harder in JavaScript by emulating rigid OOP.

Which is to say, practically all languages have all the necessary technology for JSON not to be a pervasive problem. The only impediments are social/ideological.

(An idea which resonates with the original article's message)

You might expect your service to only receive a particular JSON format, but it could really receive any JSON, or any String, or any bytes, etc.

At some point in the program you want to rely on your data already having been validated. HashMaps are not a good fit for this.

For me the neatest way to address both of these is to have a very narrow conversion window. Transform the data from bytes/string/hashmaps into well-typed objects only within the controller.

Reply on news.ycombinator.com