4 ms·

> 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 bi

> 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
I think you're more interested in interfaces than objects, actually. All the problems of objects - inheritance most especially, but mutable state too - aren't relevant if you're primarily interested in "pluggable behaviour", which really is an interface-oriented mindset, not an OO one. You can certainly go very far with interfaces, as both COM and HTTP have shown. Neither are object oriented, but both abstract away implementation details to compose behaviour. How HTTP has evolved and succeeded compared to COM shows the relative strengths and weaknesses: such pluggable behaviour works best when composing larger systems, rather than in the small, at the level of implementation details. That's exactly where OO is poor. I will still contend that a cyclic graph of mutable objects (whether they look like message-passing interfaces or not) makes for a very marshy foundation. The reason is mutability and lack of idempotence. These are critical to why functional is a better approach compared to OO. To the degree that interfaces expose mutability, and they are composed in large enough mass, the same problems as OO will arise. There's a reason I keep harping on about mutability despite accusations of straw men: it is the fundamental flaw at the heart of OO. > Functional programming is great, and mixes quite well with OO It does not. You have to work very hard in most OO languages to get FP right; in statically typed languages, the type system isn't expressive enough, and most dynamically typed languages default to too much mutability. There was a chap back in the day who advocated object-oriented assembly, Randall Hyde. The discipline required reminds me of attempts to do FP in an OO language. The minimum needed for FP in OO is a decent lambda syntax (do you remember the horrible gymnastics with overloaded operators in C++ before lambdas? - boost::lambda etc); without that, it's not worth the syntactic overhead. With it, something can be accomplished. But nominal typing really sucks, and OO programmers love giving their types distinct names, explicitly preventing the reuse they allegedly are after. From several decades of observation, I have a theory that OOP programmers get caught up in a reward feedback loop around ceremony and prefabricated patterns, a quasi-religious endorphin rush from following formalisms that aren't strictly necessary to address the problem head-on. When a programmer isn't particularly good at crafting good solutions but can follow the OOP idioms, they can create a lot of stuff fairly quickly that looks like work, and if it fits together nicely it seems like it's elegant. But it's like carpentry focused on the joins instead of the structure: at risk of becoming baroque and unstable. Good developers can write good OO code, of course - good developers can write good code in any language. But I don't know of anything else with the same power to clarify thinking than functional composition - it levers the mind with a solid tool rather than a wobbly, lashed-together one. And objects compose to make wholes that are less stable than their parts - because they are mutable, and state spaces multiply. Mutability is always the problem in the end.

barrkel 10y ago

I think you're more interested in interfaces than objects, actually. All the problems of objects - inheritance most especially, but mutable state too - aren't relevant if you're primarily interested in "pluggable behaviour", which really is an interface-oriented mindset, not an OO one. You can certainly go very far with interfaces, as both COM and HTTP have shown. Neither are object oriented, but both abstract away implementation details to compose behaviour. How HTTP has evolved and succeeded compared to COM shows the relative strengths and weaknesses: such pluggable behaviour works best when composing larger systems, rather than in the small, at the level of implementation details. That's exactly where OO is poor. I will still contend that a cyclic graph of mutable objects (whether they look like message-passing interfaces or not) makes for a very marshy foundation. The reason is mutability and lack of idempotence. These are critical to why functional is a better approach compared to OO. To the degree that interfaces expose mutability, and they are composed in large enough mass, the same problems as OO will arise. There's a reason I keep harping on about mutability despite accusations of straw men: it is the fundamental flaw at the heart of OO. > Functional programming is great, and mixes quite well with OO It does not. You have to work very hard in most OO languages to get FP right; in statically typed languages, the type system isn't expressive enough, and most dynamically typed languages default to too much mutability. There was a chap back in the day who advocated object-oriented assembly, Randall Hyde. The discipline required reminds me of attempts to do FP in an OO language. The minimum needed for FP in OO is a decent lambda syntax (do you remember the horrible gymnastics with overloaded operators in C++ before lambdas? - boost::lambda etc); without that, it's not worth the syntactic overhead. With it, something can be accomplished. But nominal typing really sucks, and OO programmers love giving their types distinct names, explicitly preventing the reuse they allegedly are after. From several decades of observation, I have a theory that OOP programmers get caught up in a reward feedback loop around ceremony and prefabricated patterns, a quasi-religious endorphin rush from following formalisms that aren't strictly necessary to address the problem head-on. When a programmer isn't particularly good at crafting good solutions but can follow the OOP idioms, they can create a lot of stuff fairly quickly that looks like work, and if it fits together nicely it seems like it's elegant. But it's like carpentry focused on the joins instead of the structure: at risk of becoming baroque and unstable. Good developers can write good OO code, of course - good developers can write good code in any language. But I don't know of anything else with the same power to clarify thinking than functional composition - it levers the mind with a solid tool rather than a wobbly, lashed-together one. And objects compose to make wholes that are less stable than their parts - because they are mutable, and state spaces multiply. Mutability is always the problem in the end.