Comment by randomdata | Hacker News Reader

Comment by randomdata | Hacker News Reader

Parent Full thread

> They were the dominant paradigm for a long time. You haven't been around long enough.

I've only been programming for about 30 years, so yes still quite young, but during that time the C++/Java style object model has been king, and while it is based on objects, they are definitely not oriented. For orientation you need, at very least, message passing.

When was oriented programming popular and not just a cool novelty that rises up from time to time?

> Doesn't seem like a relation. Seems like you're referring to a single table with no relationship to other tables specified.

A table is represented by a relation[1], yes. A relation isn't a join. A relation is a set of tuples, by literal definition.

Does your confusion here stem from not being familiar with the relational model?

> String manipulation is what an orm does for you.

What string manipulation is required in the ORM phase? You must be thinking of query building, but that's a completely different level of abstraction. Many ORM toolkits also bundle query builders, but you could create an ORM toolkit that expects one to write SQL by hand. They are not intrinsically linked. In fact, most ORM toolkits, even those which come with query builders, do allow you to write SQL by hand if you prefer.

[1] Ignoring the peculiarities of SQL which deviate from the mathematically pure model.

If you've been programming for 30 years, it doesn't show. I'm sorry.

This is what a relation is: https://www.techopedia.com/definition/21677/relation in the context of relational databases.

I think you're confused.

>What string manipulation is required in the ORM phase?

You're just on some strange pedantic purity bent as the other person commented. Even the op refers to his "query builder" as an "orm". Most ORMs intrinsically tie "query building" and the orm together without even referencing the term query builder.

Despite all this it's fairly obvious you know what we mean and what we are trying to say. You're just playing a part here.

> This is what a relation is: https://www.techopedia.com/definition/21677/relation

"Relation is sometimes used to refer to a table in a relational database" – True, but a relation is any set of tuples. Joining multiple tables together also produces a relation. It's not just tables. It's the more abstract concept of rows and columns, basically.

But, as noted earlier, SQL actually deviates from the relational model here. It doesn't actually operate on sets. This is where you find a lot of the gotchas it is famous for. Something like QUEL, which Postgres used instead of SQL for the first 10 years of its life, is closer to Codd's original model. It actually has relations.

I expect that deviation is why we're having trouble communicating here. As SQL isn't actually relational, calling them relations is technically a misnomer. While I appreciate the purity bent you say you're off on, I have indicated multiple times that I use relation with acknowledgement of SQL's deviation from the term in its purest sense. Yes, again, SQL relations aren't truly relations, but for the sake of ORM they serve the same purpose.

> Most ORMs intrinsically tie "query building" and the orm together without even referencing the term query builder.

Such as? All of the ORMs with query builders I'm familiar with are like "You an use our query DSL and you can even write raw SQL!". They present a clear separation between the ORM and the query building phases. If they were tightly coupled in those toolkits, they wouldn't be able to enable you to use raw SQL queries.

>I expect that deviation is why we're having trouble communicating here.

No the deviation is deliberately manufactured here. The oop pedantism is obvious. Smalltalk was the first but the word as evolved, everyone knows that. Including you but you pretend not to know this.

>While I appreciate the purity bent you say you're off on,

I never said this It was said by me and another poster that YOU are the one off on this bent of being overly pedantic about terms.

I think you're just trolling now. This kind of thing is against the rules here fyi.

Funny that I am the one being called pedantic, despite flat out acknowledging that I am using the term informally. Yes, again, technically a SQL relation isn't actually a relation. I get it. But we all know what relation means with respect to the conversation, so what is to be gained by ignoring that context?

Formal definition matters only if you haven't reached a shared understanding. Before definitions entered the discussion we started at that end, but all the information necessary to understand what relation means in SQL-speak, particularly with respect to ORM, has been given. There is no value in hanging off any other definition and doing so is merely a straw man.

Whatever you want to call it, the abstraction that converts between the database's data model and the application's data model is not the same abstraction that builds queries. They are very much distinct operations and ORM is only concerned with one of them (hint: Not the one that builds queries).

You are being pedantic by virtue of even turning the conversation in this direction. Stop trolling.

The conversation hasn't turned. We are still waiting on examples of ORM toolkits that don't provide separation between the ORM and the query building operations. I suspect ad hominem entered the chat because one couldn't be found, but I'll continue to wait as I love to learn new things.

It turned when you decided to pretend that you thought all OOP meant smalltalk style OOP and when you chose to act like you were talking about relations in terms of sets and not sql. You pretended you didn't know the context when it's fairly obvious what the context is. You are playing a part.

You don't love to learn new things, that is not your objective here, your objective is to troll. This conversation is over.

OOP in the discussion was undefined prior to me choosing a definition. Smalltalk-style OOP is quite significant to the topic as what are probably the only respected ORM toolkits (CoreData, ActiveRecord) lean heavily on the facilities provided by what you call the Smalltalk-style OOP paradigm. I might even go as far as to say that the active record pattern is unusable without Smalltalk-style OOP. Other languages have certainly tried, but it gets janky really quickly.

Now, it's okay if OOP means something different to you. Words are just tools to help with communication, not some source of pride or identity. That is why definitions were laid out to ensure that we weren't just talking past each other. Despite this making you believe I am young, in my 30 years of development experience I've learned that you can't assume everyone uses the same definition. In software, it is actually quite rare to find any common definition across any sizeable group of developers.

There is no logical reason to leave a discussion because what OOP meant to me differs from what OOP meant to you. The OOP talk that was present early in this thread didn't even carry into the remainder of the conversation about ORM, so it is moot anyway. The reality is that this conversation has reached a dead end because there is nothing left to talk about. We've established that ORM and query building are different operations, which rounds out the entire topic of the thread, and that's that.

>There is no logical reason to leave a discussion because what OOP meant to me differs from what OOP meant to you

there is reason to do so if you're trolling.

Reply on news.ycombinator.com