Apart from the fact it isn't; elements have specific order and that order matters.
SQL is SQL, it's not relational algebra or whatever bastardization of it you can think up. In fact when it comes to SQL the only use relational algebra has is to tell that you that anyone talking about it has never used SQL.
But it's useful to learn the foundational mathematics of these things as there is a direct relationship between them.
SQL has semantics that can be understood by relational algebra of relational bags. It's of course not a 1:1 translation, but the mathematical underpinnings are explained there. It's useful to learn the simpler, more abstract thinking tool in order to understand the concrete programming tool.
Also wrong for Turing Machines, it really is infinite. That's a big difference to arbitrarily large. The halting problem is undecidable for TM's but not for arbitrarily large (you'll need precise definitions though).
The machine with 7918-states, Z, stops (well, Z cannot be proven to run infinitly long) iff. ZFC is consistent. For this it needs a finite amount of space but we cannot calculate how much. If we could calculate an upper bound we've proven ZFC is consistent.
There's only so many that you can buy.
It's not exactly the same thing, but the underlying lessons and mental model matter.
Of course, the move back towards nonrelational data stores these days may make the point moot.
You must be a delight to work with.
How many database programmers do you know who ever did anything involving relational algebra when creating or tuning up a database?
This point is specially pointless with the prevalence of ORM frameworks.
> There’s math and science behind concurrency and parallelism, and the coordination thereof.
Please find me the best example you can come up of what you see as math being put to practice in concurrent programming.
> Network programming is a practical application of several parts (...)
This is too much grasping at straws. Just show what you feel is the absolute best example.
> There’s more that is often left out.
There is nothing. You showed nothing as your best examples, and once you showed nothing you were left with nothing else to show.
Enough with this silly "but it is math" nonsense. You can come up with a math formalization of an egg but that does not mean a degree in math will help you boil one. Enough with this nonsense.
...and this explains why database designs are what they are. It's also why you don't learn SQL and if you do you never admit it: It condemns you to a lifetime of maintaining CRUDs written by people who don't understand relational algebra.
You mean good enough?
Are they, though? Or are you just trying to put up a strawman?
Because I assure you plenty of highly reliable infrastructure is running 24-7 without the faintest concern over normalization.
Writing from personal experience. I can also assure you that a lot of this highly reliable infrastructure works only because a lot of tears and cursing that could have avoided if the designers had any idea what they were doing.
Formalising 3rd normal form and giving it a rigorous definition so that we can test if data is properly normalised is a big deal. Ditto having algorithms in concurrent systems that we can guarantee don't have logic bugs in them.
If those things aren't math to you, then what are you willing to accept? Do you mean programmers have to sit down and draw an integral sign or it doesn't count? You're correct that doesn't happen, and you're probably setting yourself up to be steamrollered by someone who sees a well known pattern that the academics have been researching for years.
The typical corporate database has big tracts that have been "designed" by someone doesn't appear to have thought very much about how to store data in an organised fashion. It raises the question of what fuzzy thoughts go through their brain since they are only interacting with a database because they have a need to store data in an organised fashion. Hopefully their thoughtlessness doesn't matter, but doing better than that is a low bar.
It isn't. Half the world already relies on ORM frameworks that barely require any input from the developer to setup relational databases, let alone knowledge on how to normalize them.
On the rare occurrences a project feels that specialization on relational database design is relevant, more often than not it's far more useful to require expertise on specific RDBMS than trivia tricks.
> If those things aren't math to you (...)
You're missing the whole point. No one is arguing that you have math formalisms. The whole point is that those formalisms do not add any value at all. Don't you understand that?
I mean, I can whip out a web app with multiple services running in the backend and with datastore using both DynamoDB and S3, and build a business around it. We can do this without ever knowing who Jack or Joe or Jim or Jose Cobb was, let alone what he wrote. What does it tell you?
I'm going to go a bit further than just not understanding, I'm actively disagreeing with you. Based on your arguments here, in a workplace I would advocate not letting you make any decisions about database schema.
Sounds like the feeling might be mutual there though. Not saying you're bad at whatever it is you do; just I want to have to have schema designed by someone who has thought deeply about schema design. Databases usually outlive all the employees assembling it, can outlive an entire organisation and getting the design right can save days to months of work.
The academics have got entire classes of bugs that they can demonstrate don't exist in normalised data, there are benefits to everyone coordinating around a standard shared view on how to lay out data and usually drifting away from the standard it turns out not to lead to real benefits long term. You can believe that is valueless or isn't math or whatever, but there is no point aggressively introducing opportunities for bugs when there is no reason for it. And to avoid doing that, the person making the decisions needs to understand the theory.
It's unfortunate that most people these days prefer unstructured blobs of json to formal relational databases. It's impossible to get up to speed in these types of environments because every time you think you "understand" the data, you find out about a random property that gets set in rare occurrences that throws off the whole relational model you intuitively built in your mind.
This also does not hold up well in an operations heavy environment. Like all things in programming, a well balanced approach is necessary. Some combination of formally structured data with some flexibility for future requirements is probably the best course of action here, but that's too much work for programmers these days.
There’s math and science behind concurrency and parallelism, and the coordination thereof.
Network programming is a practical application of several parts, each of having foundations in math and science. From coding/decoding, to state machines. Wires are all about math and physics too.
There’s more that is often left out. Specifically holistic systems and their research. Lisp, Smalltalk, Self etc. These systems reach into math, HCI, compilers, JITs…