Was thinking about @shalabh's idea about abstracting away from DBWe 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.
3 years ago
I recently added some thoughts to a "Christopher Alexander" channel. But the channel is invite-only (oops!), so here it all is again in a thread (see replies) where it is discoverable.(Note: C.A. is the source of software Design Patterns, and inspired a whole software "Patterns" movement. This largely failed, but Agile came (in part) out of the aftermath)
One alternative to an idea maze for sorting ourselves may be for each of us to list principles, so that we can build up some sort of adjacency matrix to figure out who overlaps most with us. Here's a list for myself I came up with after chatting with @Peter Abrahamsen last week, trying to be opinionated rather than bland:• Longevity over adoption.
• Implementation matters. - Transparency over abstraction.
- Minimize dependencies. No,
really. - Minimize number of languages used.
- Conciseness of language is secondary.
• Rewarding curiosity about implementation should be a first-class design goal.
- Doesn’t matter what the architecture is;
can others tell what the architecture is? - Encode knowledge first about the outside. Environment/context over algorithms. (tests)
- Encode knowledge in the repo. No other place to look at. “Don’t make me talk to you.”
- Knowledge automatically complains when it goes out of date. (tests)
- Keep it easy to update. (domain-independent traces over domain-specific immediate UIs)
- Organize knowledge autobiographically, in a cleaned up version history. (layers)
• Make it tractable to delete features.
- Encourage more forks.
• Don’t charge for software. Messes with long-term incentives. (Charging for hosting/operational services is ok.)Comments most appreciated. I also worry that I'm too verbose in my comments, so feel free to tell me that 🙂
Couple of meta-questions from a newcomer after skimming through the history of this channel (and https://futureofcoding.org/ - maybe this could be in the topic?).Context for the questions is an incongruence between our own startup and the apparent, somewhat abstract and academic focus of this community.