[mumblemumble]

For my part, I am rather disillusioned with data-oriented programming. I admit I haven't spent a lot of time using Clojure professionally, but, in a recent experience of having to learn a large pre-existing codebase, I found that the difference between, "everything is a map," and, "the application's entire data model is a big indistinguishable ball of mud," seems to be commenting discipline. And commenting discipline is always terrible.

Officially, by the book, you're supposed to use data access functions to give everything distinguishable names and keep it clean. What I ran into is that some nice language features for writing code quickly and tersely, such as map destructuring, actively discourage you from doing that. And without that, the difference between a map full of data and a class is that a class has a single file you can read to find out what's in it, while a map may have been built up in a completely ad-hoc manner.

I think the code maintenance story may have actually been a little bit better back when I was using lisp, because lists. It's actively painful to use raw functions like cdadr to unpack your data structures. Whereas assoc-in is a fun toy and encapsulating it so you don't get to use it as much would be a bummer.

[Scarbutt]

"the application's entire data model is a big indistinguishable ball of mud," seems to be commenting discipline. And commenting discipline is always terrible.

From Rich Hickey's "History of Clojure"[1]:

Not all is rosy. Users perennially report dissatisfaction with the error reporting from the compiler and various macros. They are confused by Java’s stack traces. They face challenges maintaining and understanding, e.g., the data requirements of a codebase when a discipline around documentation has not been maintained.

Hickey is signaling here that "commenting discipline" is a must for working with Clojure.

[1] https://download.clojure.org/papers/clojure-hopl-iv-final.pd...

[ithrow]

It's like difference between having to use something like mongodb vs postgres, in mongodb you have great flexibility but must have very high commenting discipline, in postgres, less so.

[tragomaskhalos]

When doing Python I find myself using namedtuple all over the place - I neither want nor need the ceremony of a class, don't like the laxity of a map, and want to be able to see what the fields are at a glance.