For example, I think design, as they mean it, could be described as "how to get that thing we care about". The correct amount of design depends on how exacting the outcome and outputs needs to be across different dimensions (how fast, how accurate, how easy to interpret, how easy to utilize as an input for some other system). For generalized things where there's not exacting standards for that, AI works well. For systems with exacting standards along one or more of those aspects, the process of design allows for the needed control and accuracy as the person or people doing the work are in a constant feedback loop and can dial in to what's needed. If you give up control of the inside of that loop, you lose the fine grained control required for even knowing how far you are away from theoretical maximums for those aspects.

Importantly, I think there's only so much advancement you can get out of people by investing in economies of scale and iterating on process (and people, as icky as that idea is), while there's a huge amount of advancement to get out of machinery, including moving to whole new categories of machinery (which depending on how far you want to take the "slaved are machines" metaphor is waht a shift away from slaves was in the first place). In that respect maybe what you're noting is just that the shift from slaves to machines was the first in an iterative process which is speeding up over time.

> If we'd abolished slavery in Roman times we might have terraformed Mars by now.

I think maybe the right was to look at it is if we were able to abolish slavery and keep the same output (which might have required an economic or social system that incentivized farm consolidation for economies of scale that plantations were able to more easily achieve), then yes, we would have terraformed mars by now, but probably just because we happened to be along the tech tree earlier in the timeline.

Perhaps most importantly, it not being an immediate change allows the entrenched interests time to shift their strategies and portfolios over time to take advantage of the more economically advantageous option. Many people aren't happy with the time frames that generally requires, but they also seem to be very happy with reliable energy and and economy that doesn't collapse overnight and having invested a year or two ago in a car which would become worthless tomorrow.

I wonder how much of that was because of economies of scale (Even if it's forced scale). Plantations are large and have many workers, and can scale without having to worry (to a degree) about retaining workers, since workers are for most intents just machines you invest in and pay to keep up in that system, which allows for easier scaling.

We've seen increasing consolidation of farms into large entities over the centuries, so perhaps this was just a system that made that much, much easier to do.

Groups of people can and do have bias, but I also think it's much harder to control the outcome (for better or worse) when inputs are more diverse.

I ask you what to use instead, and how to deal with datastore versioning.

You say you're talking about how we don't have type safety that extends to the remote systems we're interacting with.

I ask how that helps versioning problems with these systems where you need to deal with applying changes across distributes systems, which specifically is not solved by having types in lockstep definition between systems, because in application of change there are problems to work thought.

You note we did all this deliberately and we didn't have to. I keep asking you what the other option is, because you keep acting like there is one, but refusing to give an example of what that would be, because a monorepo is no solution for the problems being discussed here in the article, which to be clear, are not limited to code.

You've made it very clear you think we should have done "something" else, but refuse to articulate what that is. If it's not known, or not explored, then I posit we didn't "choose" this path, it's the path that was open to us.

> You’re discussing how to live in the house after the foundation cracked.

You keep saying we should have used something else for the foundation that wouldn't crack, but refuse to explain what this mythical material is.

What is your proposed alternative, or are you just waxing theoretical?

I came away with some additional understanding of the problem, and thinking there are various nascent techniques to address this problem, none of them entirely sufficient, but that it's being worked on from multiple directions. I'm not sure the article was aiming for more than that.

And that helps when you are dealing with schema changes that need to be rolled out at AWS, your local DB, a Kafka cluster, how? The whole point of this article was how to approach the problem when there are different components in the system which make a monorepo and what it provides for this infeasible or impossible.

> I know it's not "practical" but that's not my point. My point is that there's a huge portion of problems with "systems" that are literally obviously solvable and with obvious solutions it's just I'm too lazy to write a production grade database from scratch, sorry guys.

The article talks about database solutions that help with this problem.

I'm uncertain how to interpret your responses in light of the article, when they seem to be ignoring most of what the article is about, which is solving exactly these problems you are talking about. Is your position that we shouldn't look for solutions to the harder problems because some people aren't even using the solutions to the easy problems?

> I felt as though this article was, through its headers and overuse of specific rhetorical devices, constantly trying to grab my attention in that same shallow manner.

I think perhaps you're quick to assess a certain type of writing, which many see as done quite well and in a way that's approachable and is good at retaining interest, as AI. Perhaps you just don't like this type of writing that many do, and AI tries to emulate it, and you're keying on specific aspects of both the original and the emulation and because you don't appreciate either it's hard for you to discern between them? Or maybe there is no difference between the AI and non-AI articles that utilize these, and it's just your dislike of them which colors your view?

I, for one, found the article fairly approachable and easy to read given the somewhat niche content and that it was half survey of the current state of our ability to handle change in systems like these. Then again, I barely pay any attention to section titles. I couldn't even remember reading the ones you presented. Perhaps I've trained myself to see them just as section separators.

In any case, nothing in this stuck out as AI generated to me, and if it was, it was well enough done that I don't feel I wasted any time reading it.

Even if you were to reduce the database to a simple API, the question then remains how do you make sure to version it along with the other portions of the system that utilize it to prevent problems. The point of the article seems to be to point out that while this is a much harder problem (which I think you are categorizing as "things that can't really be easily solved"), there are actually solutions being developed in different areas that can be utilized, and it surveys many of them.

That isn't very useful by itself. What's your suggested alternative that aligns with your advice of "don't"? How does it deal with destructive changes to data (e.g. a table drop)?

This method of test passing wasn't okay when Volkswagen did it, and it's not appropriate for employees at a company that asks them to take the test, for the exact same reason.

Is it needless? It's useful specifically because he is someone influential, and someone might say "Lua was antirez's choice when making redis, and I trust and respect his engineering, so I'm going to keep Lua as a top contender for use in my project because of that" and him being clear on his choices and reasoning is useful in that respect. In any case where you think he has a responsibility to be careful what he says because of that influence, that can also be used in this case as a reason he should definitely explain his thoughts on it then and now.