> Languages should be dumb. Standard libraries should be smart. Not the other way around.
This is a strong argument for Clojure. The language makes helpful and readable guarantees about data shape, and provides a wealth of functions that operate on its core data structures.
Kotlin has a bunch of inferred classes, and Java has a bunch of explicit ones. Clojure recognizes that data does not look like either of those: it’s fundamentally a sequential list of things or a key/value map of things. Everything else is a special case that only your program cares about, and it gives you the tools to build a system to work with them as generally or specifically as you need it to.
That is data. Not every problem is fundamentally about data though — the special case you mention may very well be the whole problem domain. Eg. what percent of data does a compositor work with vs state-holding objects with proper structures like WindowLayoutEngine and the like?
I’m not familiar with compositors, so unfortunately I don’t have a ready answer, only more questions.
What makes a WindowLayoutEngine “a state-holding object with proper structures?” How is it different from “a data tree with proper structure,” except that the former includes methods inside the class instance while the latter relies on functions to operate on the data tree?
This is a strong argument for Clojure. The language makes helpful and readable guarantees about data shape, and provides a wealth of functions that operate on its core data structures.
Kotlin has a bunch of inferred classes, and Java has a bunch of explicit ones. Clojure recognizes that data does not look like either of those: it’s fundamentally a sequential list of things or a key/value map of things. Everything else is a special case that only your program cares about, and it gives you the tools to build a system to work with them as generally or specifically as you need it to.