5 ms·

> It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go. I'm not sure object oriented programming eve

> It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go. I'm not sure object oriented programming ever really caught on. The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go". > SQL is already a high level abstraction. SQL is a high level query abstraction, but we're talking about the data model. Again, a relation is nothing more than a set of tuples[1]. That is a very primitive data abstraction. Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures? > The models already exist in the database. Why build a repetitive model in the application language? Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code. > It's a cosmetic thing because people don't want to deal with string manipulation. String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory. [1] If we are being pedantic, SQL actually deviates from the relational model by not staying completely true to sets. But the terminology has stuck regardless.

acdha 4y ago
> The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go". What about Java, C#, and Python? The first two have been go-to at many businesses since the turn of the century. If C++ isn’t mainstream it’s because in no small part people picked those instead.
- randomdata 4y ago
  I expect Java was once confused as being object oriented because James Gosling came from a Smalltalk background and Patrick Naughton from an Objective-C background and as a result Java takes a lot of inspiration from those two languages. But it misses the part that provides orientation. Java's object model is much closer to C++'s in that regard, and C++ definitely isn't object oriented. The coiner of the term even once literally said so. Not sure why you think C# and Python are object oriented? They have what could be considered objects, but where does the orienting come into play?
  - fckgnad 4y ago
    The distinction between smalltalk and other oop languages is not relevant. The majority of the human race thinks of java as oop and is referring to such languages when communicating. Please do the same.
  - acdha 4y ago
    Because that’s how their creators describe them. C# started as COOL, as in “C-like Object Oriented Language”. Python incorporates that term in descriptions from the 90s and see e.g. http://python-history.blogspot.com/2009/01/introduction-and-overview.html http://python-history.blogspot.com/2009/01/introduction-and-... Both incorporate other paradigms like every other popular language but that doesn’t negate the huge influence OOP had on several generations of languages. If you’re on some weird purity bent where you insist mainstream usage is wrong, well, I can’t stop you but I’ve never seen that result in something insightful or educational.
    - randomdata 4y ago
      Looking over the Python spec again, I can maybe see how you might consider it object oriented. In my experience using Python in practice, I am not sure it is commonly used as an object oriented language, though. Not like the other three languages are. I expect this is more like saying Go is a functional language[1] because it has some functional-inspired features. C# didn't yield the same results. As you suggest, it even changed its name away from containing 'Object Oriented' during the project scope evolution to not confuse people about what it is. I can't find any primitives that would even allow you to write object oriented-style code. That said, I won't completely dismiss C# as being object oriented as it is the language I have the least familiarity with and very well could have overlooked the obvious. As before, I ask where the orienting comes into play. What language features at least come close the oriented paradigm? [1] And, indeed, many do call Go a functional programming language. They're not strictly wrong, but it can make communication hard when you're loose like that. In these sorts of discussions you do have to be a little more precise, otherwise you'll end up talking past each other.
fckgnad 4y ago
>I'm not sure object oriented programming ever really caught on. Uh they have. They were the dominant paradigm for a long time. You haven't been around long enough. I'm going to be real with you, a lot of what you say shows that you're relatively new. >Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures? Doesn't seem like a relation. Seems like your referring to a single table with no relationship to other tables specified. You took a tuple and converted it to a named tuple. In SQL named tuples or named sets is the exclusive syntax... all columns are defined by name and type, all columns are queried by name. Indexed ids must be explicitly defined and in SQL they are not the default. >Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code. This is incorrect. First off with an orm you are implementing your datastore in two places. You define the model in SQL and redefine it in application code. There is no separation here. The orm is by definition a leak. It destroys the concept of a single source of truth. Second. A change in schema in SQL necessitates a change in model in application code. It cannot be separate by definition. Otherwise your model in code doesn't match what exists in reality. >String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory. Where on earth does Json come from? No man. String manipulation is what an orm does for you. SQL databases can only operate on strings. If you don't have an orm then you are doing the string manipulation yourself because strings of SQL are literally the only interface these databases can accept. I don't think you fully understand the mechanism at work here. Your orm is sending strings to your SQL database over a network. That is what an orm is.
- randomdata 4y ago
  > 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.

acdha 4y ago

> The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go". What about Java, C#, and Python? The first two have been go-to at many businesses since the turn of the century. If C++ isn’t mainstream it’s because in no small part people picked those instead.

randomdata 4y ago
I expect Java was once confused as being object oriented because James Gosling came from a Smalltalk background and Patrick Naughton from an Objective-C background and as a result Java takes a lot of inspiration from those two languages. But it misses the part that provides orientation. Java's object model is much closer to C++'s in that regard, and C++ definitely isn't object oriented. The coiner of the term even once literally said so. Not sure why you think C# and Python are object oriented? They have what could be considered objects, but where does the orienting come into play?
- fckgnad 4y ago
  The distinction between smalltalk and other oop languages is not relevant. The majority of the human race thinks of java as oop and is referring to such languages when communicating. Please do the same.
- acdha 4y ago
  Because that’s how their creators describe them. C# started as COOL, as in “C-like Object Oriented Language”. Python incorporates that term in descriptions from the 90s and see e.g. http://python-history.blogspot.com/2009/01/introduction-and-overview.html http://python-history.blogspot.com/2009/01/introduction-and-... Both incorporate other paradigms like every other popular language but that doesn’t negate the huge influence OOP had on several generations of languages. If you’re on some weird purity bent where you insist mainstream usage is wrong, well, I can’t stop you but I’ve never seen that result in something insightful or educational.
  - randomdata 4y ago
    Looking over the Python spec again, I can maybe see how you might consider it object oriented. In my experience using Python in practice, I am not sure it is commonly used as an object oriented language, though. Not like the other three languages are. I expect this is more like saying Go is a functional language[1] because it has some functional-inspired features. C# didn't yield the same results. As you suggest, it even changed its name away from containing 'Object Oriented' during the project scope evolution to not confuse people about what it is. I can't find any primitives that would even allow you to write object oriented-style code. That said, I won't completely dismiss C# as being object oriented as it is the language I have the least familiarity with and very well could have overlooked the obvious. As before, I ask where the orienting comes into play. What language features at least come close the oriented paradigm? [1] And, indeed, many do call Go a functional programming language. They're not strictly wrong, but it can make communication hard when you're loose like that. In these sorts of discussions you do have to be a little more precise, otherwise you'll end up talking past each other.

fckgnad 4y ago

>I'm not sure object oriented programming ever really caught on. Uh they have. They were the dominant paradigm for a long time. You haven't been around long enough. I'm going to be real with you, a lot of what you say shows that you're relatively new. >Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures? Doesn't seem like a relation. Seems like your referring to a single table with no relationship to other tables specified. You took a tuple and converted it to a named tuple. In SQL named tuples or named sets is the exclusive syntax... all columns are defined by name and type, all columns are queried by name. Indexed ids must be explicitly defined and in SQL they are not the default. >Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code. This is incorrect. First off with an orm you are implementing your datastore in two places. You define the model in SQL and redefine it in application code. There is no separation here. The orm is by definition a leak. It destroys the concept of a single source of truth. Second. A change in schema in SQL necessitates a change in model in application code. It cannot be separate by definition. Otherwise your model in code doesn't match what exists in reality. >String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory. Where on earth does Json come from? No man. String manipulation is what an orm does for you. SQL databases can only operate on strings. If you don't have an orm then you are doing the string manipulation yourself because strings of SQL are literally the only interface these databases can accept. I don't think you fully understand the mechanism at work here. Your orm is sending strings to your SQL database over a network. That is what an orm is.

randomdata 4y ago
> 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.