Clojure uses objects for connections and things, but POJOs are harmful IMHO because it makes manipulation and collecting data a bespoke task every time. Every time you change the data, you have to change a class to represent the JSON and the ORM class and .... this is all just data

Well, that’s what Java records are for. As for having to change the type description, that’s more of a static typing discussion, though it can be generated — having a single source of truth and generating others is imo the best approach.

Java records weren't even a gleam in the eye of James Gosling when Clojure was solving these problems at its inception.

Standard ML had records since the '70s. Both Clojure and Java would benefit from taking more from what came before, though Java at least had the excuse of being designed for low-powered set-top boxes.

According to the link below, ML records are mostly handled by hash-maps in Clojure, except that there’s no canonical key/val order or strict typing by default.

ML record:

  {first = "John", last = "Doe", age = 150, balance = 0.12}

Clojure hash-map:

  {:first "John", :last "Doe", :age 150, :balance 0.12}

Destructuring a record in an ML function:

  fun full_name{first:string,last:string,age:int,balance:real}:string =
    first ^ " " ^ last

(It’s unclear from the example whether or not all of the destructured values are required in the function signature. I hope they are not, but I left them in since I don’t know. The caret positioning raises further questions.)

Destructuring a map in a Clojure function:

  (defn full-name [{:keys [first last]}]
    (str first “ “ last))

I don’t know if I’m missing something that ML offers with its records aside from more strict typing, which you can also have in Clojure when it’s useful. In both cases, it looks like it’s applied at the function declaration and not the record declaration.

https://www.cs.cornell.edu/courses/cs312/2008sp/recitations/...

Clojure has records too.

In his eyes? It definitely was a thing, records are just nominal product types, these are probably the single most used building block of programming languages.

I really like Clojure, but I really don’t know what some of its fans think (also true of other lisps), like there is a healthy pollination of ideas between languages, lisps are not God’s language.

I think OOP (object oriented programming) is abused and is not the optimal paradigm for most software services. It succeeds best at providing inter-operability structure for API design. "Objects", as mentioned here, are an abstraction. Stateful data can be organized and manipulated elegantly without use of the OOP paradigm. Many small systems that employ OOP hamper their maintenance and extendability by unnecessary dependence upon encapsulation and data ownership. Mutability is a villain here as well -- when data structures are immutable, there is little fear of panoptic architectures designed without ownership constraints. Here software is no longer corralled into walled gardens of "objects"; large complex types and their brittle method associations are avoided, greatly simplifying software architectures as a result.

Connection pools exist precisely because the code outside of the connection management piece shouldn’t have to care much whether or not there is an active connection. It’s all boilerplate, except for handling the “unable to connect” case.

When you call a connection or connection pool object, you’re querying its current state. This is absolutely data.