> What we really need is a less shitty version of SQL. My view is the opposite. The power of SQL perpetuates a low-quality software culture. The root issue is

> What we really need is a less shitty version of SQL. My view is the opposite. The power of SQL perpetuates a low-quality software culture. The root issue is a dev culture that can't see past databases. A lot of software design runs like this: (1) translate business patterns into a relational schema; (2) build interactions with that schema; and (3) as that gets harder, use SQL arcana and ORMs and views and stored procedures to squeeze out flexibility. I worked like this for the first decade of my career. My systems got some use, and struggled along, but they are failed projects. Repeatedly I had this feeling: the project is almost done, but there are some concurrency issues where I would not even know how to start addressing them. The database-centric design made it impossible to work past that. After much searching, I came to this: Stored State is a brittle and unwieldy thing, and you want as little of it in your life as possible. The more you have, the harder you have to work to get anything done. Databases are an institution of Stored State. As an alternative, you can derive state from messages.