I haven’t used Swift, but my understanding is that its structs are what the article calls “data” and its classes are “objects”. Basically, as far as I understand it, the reason Swift has structs is so that it can have a non-reference type which has equality, e.g. “data”.
Structs are direct and can live on the stack or inside another struct or class. Classes are always heap-allocated and ref-counted. Structs are always passed by value, classes by pointer/reference. As a consequence, only classes support inheritance.
I was actually wondering when he was going to mention Swift structs.
Highly recommend the whole series of articles. For me personally, this was by far the most informative source about software architecture.
A lot of my Haskell programs have objects in them. There are several ways to do it when it’s the right choice. This even includes mutable objects aka actors (though those are the right choice less often)
In before @hwayne pops up with a copy of Data and Reality.
did someone say Data and Reality
tbf the op is using “data” differently than Kent did. Kent talks about data as a representation of the world in our system, Ted is talking about data as a category of programming values.
You know you’ve been on lobste.rs too long when this is hilarious.
I think the way elixir ties structs with modules is probably what the OP is looking for, besides which it inherits the things OP likes about erlang
Weird to go through all that without mentioning clojure.
Maybe they don’t have clojure experience. Why would you have liked to see it added?
Its design philosophy is pretty specific about the limitations of OO for handling data and managing state transitions.
Clojure’s covered in a follow up article to a follow up article: https://www.tedinski.com/2018/03/06/more-on-the-expression-problem.html
Tangentially: Weird to see another article calling NoSQL a fad that ended. What does he think the really big players store their vast data sets in? Not Postgres or MySQL and increasingly not any other relational db.
Key value stores, mostly, which are not normally considered the NoSQL idea of queriable blobs.
Sounds like a No True Scotsman kind of argument, then.
An interface over HTTP where you PUT new data and DELETE old data and GET data, would that be a NoSQL database? I would posit not. And thus you can draw a line.
That hypothetical thing, which I agree is not a database, is not what I’m talking about. (I work for Couchbase, which is not as visible a database as some, but our customer base skews toward very large enterprises like Apple, eBay, Adobe, etc. rather than the small shops that use e.g. MongoDB.)
I would also say S3 is not a NoSQL store
I’m a few days late to the article, but it was a great read and it’s something I’ve been trying to articulate often in internet discussions here, on HN, and Reddit. In my opinion, “objects” are only objects if they represent mutable state- whether that’s actual mutation in the programming language terms, or something like an HTTP or database client (even though it may be described in code as an “immutable” instance of a thing in memory).
One minor thing that I take issue with in the article is in that first table that compares/contrasts data and objects. In the abstraction row, the author says that data has “exposed internals” and that objects have access to encapsulation. I disagree. A data type can absolutely hide its internals and maintain invariants. I do it all the time when I define a type like “PositiveInt” or “NonEmptyString” in my statically typed code. These kinds of types do not have to expose the storage details, but they are certainly just plain-old-data and not objects.