Was thinking about @shalabh's idea about abstracting away from DB We work with SQL table pretty much same way we would work with lists or sets locally. Find, select, filter, sort, insert. What if we split application in two distinct parts: 1) where we work with data, do business logic. We globally specify data structures we want to use (set, queue, stack, dict) and number of template requests that work with them. Then we just implement our business logic using these data structures. 2) where we configure storage for data structures defined in first part. This code takes info about used data structures and requests, statistics of use. It selects appropriate database engine (or may be several for different data structures) and generates schema that fits description given in 1). It should also be possible to manually specify desired database engine. The choice of database engines for different data structures is limited by how they are used. When description of used data structures is changed, then it may require migration in 2) This will greatly simplify programming. It reminds ORM, but taken on whole different level.

I think @jonathoda and @rntz would have things to add here. Jonathan on adding the database to code, and migrations, and Michael on making code data structure operations fast by using optimizations from the db literature

You mean like programming your business logic against Abstract Data Types (https://en.m.wikipedia.org/wiki/Abstract_data_type) and choosing appropriate implementations (dbs / data structures) afterwards?

Imagine that you work with job queue, and write business logic around it. There might be three different configurations of the same app: 1) in-memory queue 2) queue via table in postgresql 3) queue in redis You can use any of those without touching business logic that you've written, simply by changing configuration.

Is there a specific comment you are referring to @Vladimir Gordeev Most recently I tweeted a bit about how DBs shouldn't be a separate service: https://twitter.com/chatur_shalabh/status/1090677577918775296. In general I agree with your idea. In theory switching out a queue implementation is possible with class or module based abstraction but the 'coupling' of the higher level code is still deeper. E.g. the code that uses a simple list looks very different from something that uses a class that abstracts away writes to a queue service. Can we make it look like the simple case, but separately (in a separate layer?) map the higher level operations to the next lower level details, such as list X is local, list Y is a remote queue implemented here, etc.

In my design, the database and drawing system are tightly integrated into the language itself, so that one can define data structures (which imply some kind of database, that the program doesn't have to know the details of, just that it exists), and at the beginning of each program you define the data structures and type of quantity for each node of the graph database that will be filled in later with data. It is very much as Gordeev suggests. Then there is drawing code, event handling code, and a small bit of business logic related to operations triggered by the event handlers. The program is structurally segregated, which makes for easier comprehension. By the way, on every product i can think of the business logic was a small part of the overall code words; most of the words are devoted to drawing, which is always a very tedious aspect, especially now that we are in the era of extreme wide ranges of device resolutions.

E.g. the code that uses a simple list looks very different from something that uses a class that abstracts away writes to a queue service

when you use queue service, then read from queue may fail. Also you need to ack the consumption, which may fail too. We can define same interface that takes that into account for both remote and local queue.

Also, something like a queue is a distribution concern and perhaps not meaningful if we think about business logic? Is it possible to program with higher level models and how these get implemented would be specified in separate layers.

Finite State Machines are a big part of every game and almost every program has a few small FSM's inside. I devoted a special syntax to notate them, as it is such a common occurrence. However from a word-count point of view the FSM's are tiny. Since most programs imitate some human-evolved system, the logic just isn't that complex.

@Edward de Jong / Beads Project - interesting stuff - is there more information publicly available about the Beads Project?

there is some notes about it on my blog at e-dejong.com