2 ms·

You're not disagreeing with anything I wrote. I said multiple inheritance is intrinsically complex in ways JOINs can be. JOINs can be used to do all kinds of wi

You're not disagreeing with anything I wrote. I said multiple inheritance is intrinsically complex in ways JOINs can be. JOINs can be used to do all kinds of wild and whacky things, they can also (easily) lead to horribly slow queries. They may be conceptually simple, but so is Universal Algebra.

catnaroek 13y ago
We are disagreeing. Multiple inheritance does not admit an elegant (per Dijkstra: simple yet effective) mathematical description. Since it is a programming construct, however, there must be some description of it, which we also know must be ugly - we have ruled out it being elegant. JOINs are not intrinsically complex in the way multiple inheritance is. And they need not have bad performance either: it is just that relational databases have not caught up yet with the advances in category and type theory, and suffer from that accordingly. Saying schema-backed databases are intrinsically bad because SQL databases suck is just like saying static typing is bad because it sucks in Java and C++. And, yes, Universal Algebra is one big source of inspiration of mine, precisely because it leads to simple descriptions of large classes of structures.
- Tloewald 13y ago
  Ok, i'm arguing that trading conceptually more complex multiple inheritance for conceptually simple JOINs isn't a win because multiple inheritance won't protect you from stuff blowing up. You"re just against multiple inheritance because it's a conceptual mess (I agree) without allowing for the argument that it might work better in practice (which I have anticipated and dismissed). Monopoly is concpetually more complex and less cleanly defined than Go, but not easier to play. I am saying that multiple inheritance is not Monopoly, but Go with extra, badly written rules. This is a pretty minor disagreement. You ignore a possibility, I mention it in passing and dismiss it. (Perhaps you're hung up on my stating that JOINs can be complex — conceptually complex is not the same as complex, just as universal algebra might breezily describe a realm of mathematics that has devoured the attention of geniuses for centuries.)

catnaroek 13y ago

We are disagreeing. Multiple inheritance does not admit an elegant (per Dijkstra: simple yet effective) mathematical description. Since it is a programming construct, however, there must be some description of it, which we also know must be ugly - we have ruled out it being elegant. JOINs are not intrinsically complex in the way multiple inheritance is. And they need not have bad performance either: it is just that relational databases have not caught up yet with the advances in category and type theory, and suffer from that accordingly. Saying schema-backed databases are intrinsically bad because SQL databases suck is just like saying static typing is bad because it sucks in Java and C++. And, yes, Universal Algebra is one big source of inspiration of mine, precisely because it leads to simple descriptions of large classes of structures.

Tloewald 13y ago
Ok, i'm arguing that trading conceptually more complex multiple inheritance for conceptually simple JOINs isn't a win because multiple inheritance won't protect you from stuff blowing up. You"re just against multiple inheritance because it's a conceptual mess (I agree) without allowing for the argument that it might work better in practice (which I have anticipated and dismissed). Monopoly is concpetually more complex and less cleanly defined than Go, but not easier to play. I am saying that multiple inheritance is not Monopoly, but Go with extra, badly written rules. This is a pretty minor disagreement. You ignore a possibility, I mention it in passing and dismiss it. (Perhaps you're hung up on my stating that JOINs can be complex — conceptually complex is not the same as complex, just as universal algebra might breezily describe a realm of mathematics that has devoured the attention of geniuses for centuries.)