3 ms·

Sure, but the world is bigger than CRUD apps, and even in CRUD apps, object mapping is more productive than hand written SQL slinging result sets around in proc

Sure, but the world is bigger than CRUD apps, and even in CRUD apps, object mapping is more productive than hand written SQL slinging result sets around in procedural code. In particular the ease at which OO enabled pluggable programs is invaluable in customizing in different ways for different clients or aggregating data from multiple sources. OO isn't about modeling facts about the world, it's about modelling behavior; objects aren't just structs with some data. > But even raw SQL is superior to effectively performing complex queries in a non-relational language, where the indexes are built by hand and passed around. I think that's a bit of a strawman, that's not what OO is. > In a heterogeneous world, the idea that you have an authoritative model defined in any one language, that merely uses the database for persistence, is untenable. That's not what OO is either.

barrkel 10y ago
CRUD apps are mostly about synchronizing a set of facts about the world with the world itself. Re complex queries in a non-relational language: I know that's not what OO is, but if you're trying to perform a map / filter / aggregate operation across several different collections (sometimes these kinds of things need to be done!), OO doesn't give you many tools, and the tools you can build are usually poor versions of what's available in functional languages, which are themselves less specialized and less declarative than relational languages. If you can represent your problem as a map/filter/aggregate operation, it (a) becomes more testable, (b) more parallelizable in both large and small and (c) more composable. I happen to think it ends up being easier to read, write and reason about too. So I try hard to make my problems look like this, because I know the tools in that area are very strong. Objects being more than structs with immutable data is exactly what's wrong with them. OO encourages you to reason about behaviour in terms of invariants: what's true before vs what's true after, or what is always true for an instance. I think that's strictly inferior to reasoning by transformation: what is the input vs what is the output. In particular, I think functional transformation is more composable than invariants. I'd feel happier about OO and its implicit invariants if they were made more explicit, and more than just like Eiffel: it needs to be in the type system, if possible.
- gnaritas 10y ago
  > CRUD apps are mostly about synchronizing facts about the world with the world itself. Yes, but as already stated, the world is bigger than CRUD apps and a big collection of facts about the world isn't very useful without any behavior attached to those facts. Once behavior is involved, OO becomes useful. > but if you're trying to perform a map / filter / aggregate operation across several different collections (sometimes these kinds of things need to be done!), OO doesn't give you many tools As those things are completely orthogonal to OO, so what? You can perfectly well use the database to do the map/filter/querying and still have an OO program; OO has nothing to do with map/filter/querying, so as I said already, this is a strawman. > Objects being more than structs with immutable data is exactly what's wrong with them. No, it's exactly what's right with them. It is the very reason they exist, it's entirely the point of OO to hide data and expose behavior instead through a message based interface. Structs aren't objects, so claiming objects being more than structs is what's wrong them is to claim that objects shouldn't exist and that claim is unsupportable. > I think that's strictly inferior to reasoning by transformation: what is the input vs what is the output. In particular, I think functional transformation is more composable than invariants. Functional programming is great, and mixes quite well with OO, but it's not what's being discussed, we're comparing OO to procedural programming as implemented by topmind and his table oriented programming here. Both of your replies are strawmen, you cast objects as data and then complain that they're bad at being data: but objects aren't about data, they're about pluggable behavior as I've already said. You have to step outside the "data is everything" mindset to actually see what OO is and where its value lies. Frankly you don't give me the impression than you actually understand object oriented programming, like topmind himself, you seem to be full of misconceptions related to an inability to step outside the "it's all data" mindset. I could be wrong, but that's the impression you're leaving. Take a basic example from a simple CRUD app; say I'm selling a CRUD app to many businesses, many of which already have corporate websites with global login systems and they want my app to use their member database and login system. The solution is simple and obvious, make my authentication system pluggable and for each big client that's worth the effort, implement a custom login provider that ties my authentication into their existing systems API. Can you describe a nice scalable procedural solution to this problem that's better than the obvious OO solution?

barrkel 10y ago

CRUD apps are mostly about synchronizing a set of facts about the world with the world itself. Re complex queries in a non-relational language: I know that's not what OO is, but if you're trying to perform a map / filter / aggregate operation across several different collections (sometimes these kinds of things need to be done!), OO doesn't give you many tools, and the tools you can build are usually poor versions of what's available in functional languages, which are themselves less specialized and less declarative than relational languages. If you can represent your problem as a map/filter/aggregate operation, it (a) becomes more testable, (b) more parallelizable in both large and small and (c) more composable. I happen to think it ends up being easier to read, write and reason about too. So I try hard to make my problems look like this, because I know the tools in that area are very strong. Objects being more than structs with immutable data is exactly what's wrong with them. OO encourages you to reason about behaviour in terms of invariants: what's true before vs what's true after, or what is always true for an instance. I think that's strictly inferior to reasoning by transformation: what is the input vs what is the output. In particular, I think functional transformation is more composable than invariants. I'd feel happier about OO and its implicit invariants if they were made more explicit, and more than just like Eiffel: it needs to be in the type system, if possible.

gnaritas 10y ago
> CRUD apps are mostly about synchronizing facts about the world with the world itself. Yes, but as already stated, the world is bigger than CRUD apps and a big collection of facts about the world isn't very useful without any behavior attached to those facts. Once behavior is involved, OO becomes useful. > but if you're trying to perform a map / filter / aggregate operation across several different collections (sometimes these kinds of things need to be done!), OO doesn't give you many tools As those things are completely orthogonal to OO, so what? You can perfectly well use the database to do the map/filter/querying and still have an OO program; OO has nothing to do with map/filter/querying, so as I said already, this is a strawman. > Objects being more than structs with immutable data is exactly what's wrong with them. No, it's exactly what's right with them. It is the very reason they exist, it's entirely the point of OO to hide data and expose behavior instead through a message based interface. Structs aren't objects, so claiming objects being more than structs is what's wrong them is to claim that objects shouldn't exist and that claim is unsupportable. > I think that's strictly inferior to reasoning by transformation: what is the input vs what is the output. In particular, I think functional transformation is more composable than invariants. Functional programming is great, and mixes quite well with OO, but it's not what's being discussed, we're comparing OO to procedural programming as implemented by topmind and his table oriented programming here. Both of your replies are strawmen, you cast objects as data and then complain that they're bad at being data: but objects aren't about data, they're about pluggable behavior as I've already said. You have to step outside the "data is everything" mindset to actually see what OO is and where its value lies. Frankly you don't give me the impression than you actually understand object oriented programming, like topmind himself, you seem to be full of misconceptions related to an inability to step outside the "it's all data" mindset. I could be wrong, but that's the impression you're leaving. Take a basic example from a simple CRUD app; say I'm selling a CRUD app to many businesses, many of which already have corporate websites with global login systems and they want my app to use their member database and login system. The solution is simple and obvious, make my authentication system pluggable and for each big client that's worth the effort, implement a custom login provider that ties my authentication into their existing systems API. Can you describe a nice scalable procedural solution to this problem that's better than the obvious OO solution?