undefined | Better HN

0 pointsfeoren2y ago0 comments

You're being condescending, telling me to "learn the theory". We've clearly had different experiences and work with different kinds of systems. You're automatically discounting what I say by assuming I must be a newbie because I disagree with you. No. We both have things to learn from each other and you telling me "go RTFM, newbie" is shutting down that opportunity.

> Virtually all of the systems I write have at least two back-ends to maintain that flexibility.

It sounds like that's a worthwhile tradeoff for you, but it is a tradeoff, giving up some of the unique power of each individual database in order to support both. Realize that most people don't do this.

> A good object model is NOT a relational model, and a good relational model is NOT an object model.

Maybe this is our biggest disagreement. I believe there is a model that can get the biggest benefits of both. I'm not alone in this; papers in Software Engineering, "Out of the Tar Pit", prescribes this as a possible solution to a lot of woes in software engineering:

"The classical ways to approach the difficulty of state include object oriented programming which tightly couples state together with related behaviour, and functional programming which — in its pure form — eschews state and side-effects all together ... We argue that it is possible to take useful ideas from both and that — when combined with some ideas from the relational database world - this approach offers significant potential for simplifying the construction of large-scale software systems"

https://curtclifton.net/papers/MoseleyMarks06a.pdf

I agree with them: Object Oriented Programming alone is nice for UIs but otherwise has failed to live up to its hype; Functional Programming is elegant and pure but hard to actually get anything done with; the Relational Model is simple and powerful but writing an application entirely in database procedures is a Lovecraftian Horror. So look for a model that takes the best from all three, and apply that model -- at least conceptually -- in both your database design and your application code. It is actually possible, and it's wonderful. But it will piss off the zealots on both sides.

I'm not sure what you consider "a good object model", but there is very little agreement in our industry on what exactly that looks like. If yours permits the CS 101 inheritance examples like "Dog : Animal" then I'd strongly disagree with you. Or maybe yours is the Smalltalk message-passing version: better, but still not immune to improvement. Don't assume that everyone who doesn't 100% line-toe bog standard OOP and bog standard SQL RDMSes needs to "RTFM".

>> SQL is disliked by the founders of the relational model.

> Citation required.

"SQL isn’t just user hostile, it involves some very serious departures from relational theory ... Suffice it to say that those departures are so serious that I honestly believe SQL has no real right to be called relational at all." -- Chris Date, who worked closely with EF Codd and helped spread his ideas.

https://red-gate.com/simple-talk/opinion/opinion-pieces/chri...

0 comments

blagie2y ago

Citations appreciated! I will not respond in-depth to most parts, because I agree with what you're writing. But I will make one or two points. To clarify a piece of confusion:

> Maybe this is our biggest disagreement. I believe there is a model that can get the biggest benefits of both. I'm not alone in this; papers in Software Engineering, "Out of the Tar Pit", prescribes this as a possible solution to a lot of woes in software engineering:

I don't necessarily disagree, Moseley does not describe an OO model. If you showed their proposal to someone who does e.g. just Java, they would puke.

> I'm not sure what you consider "a good object model", but there is very little agreement in our industry on what exactly that looks like

A more accurate statement is that there are many models. The very first one I learned formally was the Booch method, over a quarter-century ago. My productivity fell about tenfold when I began applying it. Second one was Java. Less than tenfold. Like you, I eventually rejected OO for most things other than UX, or relatively small objects which are more-or-less little more than data types.

-----

But onto the main point:

- Models have theoretical properties which work well in isolation.

- Mixing models often destroys those properties.

- For example, I can slice code vertically or horizontally. Either works well. If I mix the two, I have no abstraction or modularity left.

- Java got rid of MI for a reason. It's not that MI is bad, but it doesn't fit into the Java OO model.

- If I add a little bit of OO to functional, I get mutation, and almost all of the benefit disappears in a poof. (note: There are systematic ways to do this which maintain benefits of both)

- Aside from theoretical properties, models are a way to communicate. You know what to expect in code.

You can design hybrid models, but you can't just mix models. Code kinda falls apart. None of the OO models map cleanly onto relational, or vice-versa. It's possible to do other models that perhaps combine aspects of both, but they're no longer OO.

An ORM is a bastardization of the two models, by trying to mesh them together. In contrast, I like Moseley Marks a lot, which is it's own model.

-----

And a footnote: I no longer find it hard to get things done with functional programming. Most of my code is pretty close to pure functional, with a few well-controlled places with state (on the front-end, with Redux). Part of that is experience on my part, but part of that is that both Python and modern JavaScript surface many of the most useful aspects of functional in ways which are linguistically nice.

-----

As a second footnote: A lot of this is based on domain. For example, numerical code works great in functional, while as you pointed out, UX maps well onto OO.

j / k navigate · click thread line to collapse

0 comments

blagie2y ago

Citations appreciated! I will not respond in-depth to most parts, because I agree with what you're writing. But I will make one or two points. To clarify a piece of confusion:

I don't necessarily disagree, Moseley does not describe an OO model. If you showed their proposal to someone who does e.g. just Java, they would puke.

> I'm not sure what you consider "a good object model", but there is very little agreement in our industry on what exactly that looks like

-----

But onto the main point:

- Models have theoretical properties which work well in isolation.

- Mixing models often destroys those properties.

- For example, I can slice code vertically or horizontally. Either works well. If I mix the two, I have no abstraction or modularity left.

- Java got rid of MI for a reason. It's not that MI is bad, but it doesn't fit into the Java OO model.

- If I add a little bit of OO to functional, I get mutation, and almost all of the benefit disappears in a poof. (note: There are systematic ways to do this which maintain benefits of both)

- Aside from theoretical properties, models are a way to communicate. You know what to expect in code.

An ORM is a bastardization of the two models, by trying to mesh them together. In contrast, I like Moseley Marks a lot, which is it's own model.

-----

As a second footnote: A lot of this is based on domain. For example, numerical code works great in functional, while as you pointed out, UX maps well onto OO.

j / k navigate · click thread line to collapse