Huh? In the commercial model, why would an individual still pay for "a lot of crap art". What you call "no taste" is just "taste," right? Nobody who gets to pick is going to pick the crap stuff.
I've liked 100% of the art I've ever purchased (that's why I purchased it)
Also currently working on a book (shameless plug: buy my book!) and feel no pull or need to involve AI. This book is my mine. My faults. My shortcomings. My overuse of commas. My wonky phrasing. It has to have those things, because I am those things (for better or worse!).
One of the coolest things I've encountered at an aquarium was a sleeping octopus wildly shifting its colors. It seems truly alien to behold -- like it shouldn't be possible.
My googling after the fact says that who knows why they actually do it or what's going on, but, I really like the thought of them having little octopus dreams.
Sure! The core dividing line between the two books boils down to how they approach representing data in a program. Yehonathan's book advocates for immutable data stored in untyped data structures (for instance, Map<Object, Object>). My book takes the opposite approach. It advocates for building around immutable data that's strongly statically typed. It aims to capture the stuff in our domain using algebraic data structures.
This modeling difference has pretty far reaching implications. They lead to very different kinds of code bases, and thus very different books.
Here are the repos for the two books. Poking around those should give you a good overview for how radically two things both called "data-oriented" can differ :)
Very much excited to read your book. I'd remember conversations on old Scala forums that often talked about how their code bases made it impossible to enter invalid states through strong typing. Excited to see those ideas become mainstream Java concepts.
reply