131–139 of 139 posts
Earlier quoted context omitted.
You realize data is immutable when you first try to implement history. Mutability is just a hack to save some memory.
> just a hack to save some memory .. and time. If we needed to compute an account balance by summing all the debits and credits since the account was opened...
Earlier quoted context omitted.
You realize data is immutable when you first try to implement history. Mutability is just a hack to save some memory.
I think when you start pulling on that string you eventually end up at event sourcing because once you are keeping comprehensive immutable history of all your changes keeping the mutable record anywhere just starts to look like a liability.
this is anti-OOP
Principle #2 always bothers me. "Model the data part of the entities of your application using generic data structures (mostly maps and arrays)." and example function createAuthorData(firstName, lastName, books) { return {firstName: firstName, lastName: lastName, books: books}; } For a simple, obvious object like "person" it might work, but for a complicated domain object with many other composed objects this starts…
These two slides in the Clojure, Made Simple talk are my favorite counterpoint to even shallow objects being easier to work with than data. See starting at 50:00:
If you don’t want to click through, the list of HttpServletRequest methods is bigger than the map itself! Each one is its own little DSL, and they are not consistent with each other. To do anything with the data, you first have to figure out which method gets the bit you want out of the thing. And that’s a simple case—the complexity only goes up from there.
The map OTOH is just a map; you have hundreds of simple, composable functions that you can use to slice and dice the data however you need.
Want the keys? (keys request)
Want the keys of the headers? (keys (:headers request))
The user-agent value? (get-in request [:headers “user-agent”])
None of these are specific to a servlet request; they will work on any piece of data. And it’s trivial and transparent to build more specific functions out of them that fit your problem domain.
Wouldn’t this be the exact opposite of Domain-driven design and modeling behavior? Isn’t the behavior of a system more critical than its data elements?
Reminds me of the quote: > Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. -- Fred Brooks, The Mythical Man Month (1975) I don't think they're inherently contradictory. You can have plain data objects representing the domain, and functions that act on these objects representing the behaviors/actio…
Data accuracy is critical. Data storage is critical. Analytics and warehousing are critical. But none of these things reflect the nature of a business, which are the behaviors of its domain and sub-domains.
> One could argue that the complexity of the system where code and data are mixed is due to a bad design and data an experienced OO developer would have designed a simpler system, leveraging smart design patterns. Indeed he (or she) would have made use of traits/protocols/categories/whatever, to separate behavior from data, while keeping the design extensible (via polymorphism). This is something I usually find in OO…
Alan Kay and Rich Hickey discuss the merits of data vs data with interpeters: https://news.ycombinator.com/item?id=11945722
Earlier quoted context omitted.
Yes, for sure it is. But what is the alternative? A compiler can only complain on a monolith, it can't scratch boundaries out of the system it compiles (and still within that monolith, encapsulated system the data might be inconsistent). For distributed systems this has been solved in the last two decades (if not even longer), but still systems are pressing against formality, how come? Continue to write the code to d…
How has this been solved for distributed systems?
Earlier quoted context omitted.
Evidence that "DOP works so much better than OOP" is scant imo. The rise and fall of paradigms that present themselves as panaceas is instructive. You have "structured programming", "object oriented programming", "functional programming" and now "data oriented programming". What I'd like to see is paradigms paired with "where this works well" rather than paradigms sold based on "this will solve the software crisis",…
That's because data oriented programming has already succeed on a large scale, you just might not recognize it. SQL is about as data-oriented as it gets, you have a programming model that's constrained and focused on data layout, structure and performance over being a general purpose language. There's a good article a while back about ECS that I can't find which talks about how most performant ECS start to mirror SQL…
Earlier quoted context omitted.
That's because data oriented programming has already succeed on a large scale, you just might not recognize it. SQL is about as data-oriented as it gets, you have a programming model that's constrained and focused on data layout, structure and performance over being a general purpose language. There's a good article a while back about ECS that I can't find which talks about how most performant ECS start to mirror SQL…
what is ECS in this context