And some think asking your boss if it's okay is a good idea, (spoilers: they'll say no). That is just a way to pass blame for a decision you can't stomach.
You model a certain experimental ("discovery") thing, then you implement it then you analyses the result then you change the model etc.
And sure in many cases in practice people might not skip the modeling but don't properly write it down in any later one usable way. Especially during initial experimental discovery phases. Which isn't good. But understandable and can be fully ok. Honestly especially for boring simple web API's this is pretty common. It's just important to know when to stop ;=)
This IMHO makes most tools to generate code from models just painful to use.
But I still agree that you have no business programming something which you can't somewhat model in a higher abstraction level.
> SQL is the king of managing data
Hm, not so much IMHO. SQL Is terrible bad at it in some contexts because it's inherently made for a 2d table projection which is (more or less) only joined to larger 2d table projections of data which often in it's nature is neither 2d nor maps well to 2d representations. And while you can extend SQL to support that or work around it with e.g. recursive queries it's not very nice to do at all.
There's a fascinating book "Data Model Patterns: A Metadata Map" by David C. Hay that's pretty much a Pattern Language or catalog for data models. You can just implement the subset of Hay's patterns that make sense for your application.
The implementation itself just flowed, allowing me to focus on smaller details that can't be modelled (e.g. error handling). By copying the design of classes and function names, I didn't have to backtrack and redo anything, I didn't have to think about names of things - which were pre decided and so consistent throughout the codebase and my code dovetailed nicely with parts that other people implemented.
However, I've tried to figure out how to actually store and query data relationally in a language like C++ and haven't been able to figure out a good way. I don't want to use SQLite because of performance, this needs to be close to real time (like a game or something similar). I just want a way to store data relationally in memory in C++. I'm still trying to figure out the right approach here. C++ is very static which makes it difficult. I've been able to figure it out in Javascript though.
I agree with this part assuming that graphics and video along with the words are allowed.
>"I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably start over."
This is very narrow minded approach that will only work for a very limited set of possible domains. Simplest example to the contrary: the domain is a creation of efficient way of solving some math related problem. What query?
I challenge anyone to present a problem domain which cannot be meaningfully represented in terms of tables in a database. I would prefer if this were bounded by the set of problems you would use any software development strategy upon, but I welcome a more difficult problem as well.
I am being practical. There are many languages that are Turing complete but ill suited for particular domain. It's been proven that SQL is Turing complete as well. However should you propose using SQL to write implementation of say FFT you are not likely to find much of a sympathy.
Dimension = Customers, Accounts, Users, Widgets, Inventory
Higher-Order Logic = combining basic functional building blocks in order to compose more complex functionality. SQL enables direct, declarative access to the whole space of higher-order functions. E.g. You want the list of widgets made 3 quarters ago but scoped to one factory line, and only when a certain rotation of employees was on the factory floor? You got it. That's like 10-15 lines of SQL.
The term "higher order logic" typically means program logic that uses higher order functions. An object-oriented programming style is inherently higher order because objects typically contain functions and are passed to methods.
The term "higher order logic" can also mean a system of logic that allows statements about logical statements. [2]
[1] https://en.wikipedia.org/wiki/Higher-order_function [2] https://en.wikipedia.org/wiki/Higher-order_logic
If you are unable to describe, on paper, what your problem domain actually is, then you have no business opening up an IDE and typing out a single line of code.
I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably start over. Dimensionality and normalization are a big deal with your model. You have to be really careful about nesting collections of things within other things if you want to allow for higher-order logic to project required views. This is something we struggled with for a really long time. Every rewrite conversation began something like "well customer and account need each other in equal measure...". And it took us god knows how many iterations to figure out the relationship should not be an explicit property either way.
Put shortly, Modeling is the core of it all. Start with simple top-level collections of things. E.g. instead of modeling Customer.Transactions[], model Customers, Transactions and CustomerTransactions. This fundamental principle of keeping your model dimensions separated by way of relational types can help to un-fuck the most problematic of domains. These will start to look a lot like EF POCOs for managing SQL tables...
At the end of the data, data dominates, and SQL is the king of managing data. If you embrace these realities, you might be encouraged to embed SQL a lot deeper into your applications. I spent a long time writing a conditional expression parser by hand. Feels like a really bad use of time in retrospect, but I did learn some things. Now I am looking at using SQLite to do all of this heavy-lifting for me. All I have to do is define a schema matching my domain model, insert data per instance of the model, and run SQL against it to evaluate conditionals and produce complex string output as desired.
[1] https://users.ece.utexas.edu/~adnan/pike.html