4 ms·

> Relational algebra is math. SQL is a practical application of relational bags. How many database programmers do you know who ever did anything involving rela

> Relational algebra is math. SQL is a practical application of relational bags. 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.

oriolid 4y ago
> How many database programmers do you know who ever did anything involving relational algebra when creating or tuning up a database? ...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.
- simplotek 4y ago
  > ...and this explains why database designs are what they are. You mean good enough?
  - oriolid 4y ago
    Good enough as in constant burden but not bad enough to fail the whole project.
    - simplotek 4y ago
      > Good enough as in constant burden 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.
      - oriolid 4y ago
        > Or are you just trying to put up a strawman? 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.
roenxi 4y ago
> 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. 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.
- simplotek 4y ago
  > Formalising 3rd normal form and giving it a rigorous definition so that we can test if data is properly normalised is a big deal. 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?
  - roenxi 4y ago
    > The whole point is that those formalisms do not add any value at all. Don't you understand that? 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.
wankle 4y ago
Agree, I've programmed in various languages at various companies for three decades, do not have a degree and yet every point you made is 100% accurate and precise.
deleted 4y ago
[deleted]

oriolid 4y ago

> How many database programmers do you know who ever did anything involving relational algebra when creating or tuning up a database? ...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.

simplotek 4y ago
> ...and this explains why database designs are what they are. You mean good enough?
- oriolid 4y ago
  Good enough as in constant burden but not bad enough to fail the whole project.
  - simplotek 4y ago
    > Good enough as in constant burden 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.
    - oriolid 4y ago
      > Or are you just trying to put up a strawman? 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.

roenxi 4y ago

> 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. 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.

simplotek 4y ago
> Formalising 3rd normal form and giving it a rigorous definition so that we can test if data is properly normalised is a big deal. 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?
- roenxi 4y ago
  > The whole point is that those formalisms do not add any value at all. Don't you understand that? 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.

wankle 4y ago

Agree, I've programmed in various languages at various companies for three decades, do not have a degree and yet every point you made is 100% accurate and precise.

deleted 4y ago

[deleted]