As a professional dev who has made a career out of working in oo languages and codebases, I agree, and it took me far too long to realize that when it comes to oo, the emperor has no clothes.
To this day, oo advocates can't even agree on what oo even is or means.
Apparently oo as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently.
Why? Who knows! It was never really explained why literally one of the most complex systems imaginable, one that we still really have very little idea how it even works, should be the model for what could and should probably be a lot simpler.
Today's modern oo languages are probably very far from what Kay envisioned (whatever that was), but it's remains unclear why classes and objects are "better" than the alternatives.
And before anyone goes and comments aksully code organization blabla like yes but code organization can be great or shit in oo or fp or procedural codebases, it has nothing to do with the "paradigm".
Let alone that the entrenched, canonical, idiomatic coding styles of most modern oo languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. Granted, most have now started to come around and are adopting more fp features and ideas every year, but still.
Kay's ideas are about building complex systems from isolated components ("cells") which may evolve independently. The web is an example: there's a server and a page and a browser and the user's extensions, all changing without reference to each other. How can they all work together?
Answer: keep them isolated (no direct function calls), defer most choices to runtime, make it easy to interrogate each others' interfaces. I think that sums up OO. "Call this function if it exists at runtime" is trivial in JS, but a crisis in Haskell.
You may not need that stuff. If you're statically compiling your code and all dependencies, it seems pointless. But if you're building a system which talks to code not under your control, code you cannot just refactor at will, then I don't know of any better techniques than OO.
Really depends upon what you're talking about. Examplle you can have a `Maybe (IO ())` data which would indicate "call this for side effects if it is present, otherwise do not". You could also model this as e.g.
foo :: [(Text, IO ())]
so thsi would be a list of capabilities, each with a name.
Ofc this is a bit tricky, you would have to do a lot of heavy lifting in C to pull this off; but it wouldn't be hard to do in e.g. JS at the FFI layer before Haskell.
Apparently oo as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently.
Why? Who knows!
A very probable good mental model for what was intended is Erlang/OTP or the Actor Model generally. The idea of encapsulated systems which interface opaquely is very well represented there. And the reasoning and benefits are as well.
Don't get me wrong, it's an interesting idea which deserves pursuing, if nothing else but to satisfy our curiosity and seeing to what if anything it's applicable and suited. (and even if the answer turns out to be "nothing", we've still learned something!)
But going from there to making strong claims about it being a more or less universally superior paradigm for computing and writing code, with little to zero evidence, that's a huge, huge stretch.
To the degree Erlang and Actors work, I think that's kind of a happy coincidence, and not due to any rigorous work on Alan Kay's part.
You may want to spend time with Joe Armstrong’s take on the matter. If nothing else it’ll be interesting.
And the elegance of something may or may not speak to rigor, but that doesn’t mean rigor doesn’t bear it out. It’s not as if Erlang is some flash in the pan, it’s been an incredibly important part of large scale real world computing.
On my first year I honestly thought java was working like Erlang (which I didn't know of at the time). Objects being independent parallel threads sending messages. Then teacher laughed at the idea.
IMO, Robert C Martin is to Computer Science what Nassim Taleb is to Economics and Finance and what Jared Diamond and Graham Hancock are to anthropology and archeology - they're psuedo-intellectual quacks pushing a bunch of impressive and authoritative sounding absolute bs with zero evidence behind it on unsuspecting victims.
A lot of Robert C Martins pieces are just variations on his strong belief that ill-defined concepts like "craftsmanship" and "clean code" (which are basically just whatever his opinions are on any given day) is how to reduce defects and increase quality, not built-in safety and better tools, and if you think built-in safety and better tools are desirable, you're not a Real Programmer (tm).
I'm not the only one who is skeptical of this toxic, holier-than-thou and dangerous attitude.
Removing braces from if statements is a great example of another dangerous thing he advocates for no justifiable reason
The current state of software safety discussion resembles the state of medical safety discussion 2, 3 decades ago (yeah, software is really really behind time).
Back then, too, the thoughts on medical safety also were divided into 2 schools: the professionalism and the process oriented. The former school argues more or less what Uncle Bob argues: blame the damned and * who made the mistakes; be more careful, damn it.
But of course, that stupidity fell out of favor. After all, when mistakes kill, people are serious about it. After a while, serious people realize that blaming and clamoring for care backfires big time. That's when they applied, you know, science and statistic to safety.
So, tools are upgraded: better color coded medicine boxes, for example, or checklists in surgery. But it's more. They figured out what trainings and processes provide high impacts and do them rigorously. Nurses are taught (I am not kidding you) how to question doctors when weird things happen; identity verification (ever notice why nurses ask your birthday like a thousand times a day?) got extremely serious; etc.
My take: give it a few more years, and software, too, probably will follow the same path. We needs more data, though.
I agree with your comments, but interestingly Taleb applied to SWE would be on the polar opposite of Clean Architecture. As the comment you quoted: the "data" comes from practice and caring, the "Clean Architecture" is the pseudo-science that derived from theory instead of practice. Another viewpoint is DHH's keynote where he aligns most of web development to writing (Information System) instead of trying to derive hard rules from theory.
Comments
As a professional dev who has made a career out of working in oo languages and codebases, I agree, and it took me far too long to realize that when it comes to oo, the emperor has no clothes.
To this day, oo advocates can't even agree on what oo even is or means.
Apparently oo as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently.
Why? Who knows! It was never really explained why literally one of the most complex systems imaginable, one that we still really have very little idea how it even works, should be the model for what could and should probably be a lot simpler.
Today's modern oo languages are probably very far from what Kay envisioned (whatever that was), but it's remains unclear why classes and objects are "better" than the alternatives.
And before anyone goes and comments aksully code organization blabla like yes but code organization can be great or shit in oo or fp or procedural codebases, it has nothing to do with the "paradigm".
Let alone that the entrenched, canonical, idiomatic coding styles of most modern oo languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. Granted, most have now started to come around and are adopting more fp features and ideas every year, but still.
Kay's ideas are about building complex systems from isolated components ("cells") which may evolve independently. The web is an example: there's a server and a page and a browser and the user's extensions, all changing without reference to each other. How can they all work together?
Answer: keep them isolated (no direct function calls), defer most choices to runtime, make it easy to interrogate each others' interfaces. I think that sums up OO. "Call this function if it exists at runtime" is trivial in JS, but a crisis in Haskell.
You may not need that stuff. If you're statically compiling your code and all dependencies, it seems pointless. But if you're building a system which talks to code not under your control, code you cannot just refactor at will, then I don't know of any better techniques than OO.
Really depends upon what you're talking about. Examplle you can have a `Maybe (IO ())` data which would indicate "call this for side effects if it is present, otherwise do not". You could also model this as e.g.
so thsi would be a list of capabilities, each with a name.Ofc this is a bit tricky, you would have to do a lot of heavy lifting in C to pull this off; but it wouldn't be hard to do in e.g. JS at the FFI layer before Haskell.
I generally agree but in case it helps anyone:
A very probable good mental model for what was intended is Erlang/OTP or the Actor Model generally. The idea of encapsulated systems which interface opaquely is very well represented there. And the reasoning and benefits are as well.
Don't get me wrong, it's an interesting idea which deserves pursuing, if nothing else but to satisfy our curiosity and seeing to what if anything it's applicable and suited. (and even if the answer turns out to be "nothing", we've still learned something!)
But going from there to making strong claims about it being a more or less universally superior paradigm for computing and writing code, with little to zero evidence, that's a huge, huge stretch.
To the degree Erlang and Actors work, I think that's kind of a happy coincidence, and not due to any rigorous work on Alan Kay's part.
You may want to spend time with Joe Armstrong’s take on the matter. If nothing else it’ll be interesting.
And the elegance of something may or may not speak to rigor, but that doesn’t mean rigor doesn’t bear it out. It’s not as if Erlang is some flash in the pan, it’s been an incredibly important part of large scale real world computing.
On my first year I honestly thought java was working like Erlang (which I didn't know of at the time). Objects being independent parallel threads sending messages. Then teacher laughed at the idea.
Clean architecture is worth a read. I like his description.
"Object-Oriented programming imposes discipline on indirect transfer of control."
I've read all of Uncle Bob's books.
IMO, Robert C Martin is to Computer Science what Nassim Taleb is to Economics and Finance and what Jared Diamond and Graham Hancock are to anthropology and archeology - they're psuedo-intellectual quacks pushing a bunch of impressive and authoritative sounding absolute bs with zero evidence behind it on unsuspecting victims.
A lot of Robert C Martins pieces are just variations on his strong belief that ill-defined concepts like "craftsmanship" and "clean code" (which are basically just whatever his opinions are on any given day) is how to reduce defects and increase quality, not built-in safety and better tools, and if you think built-in safety and better tools are desirable, you're not a Real Programmer (tm).
I'm not the only one who is skeptical of this toxic, holier-than-thou and dangerous attitude.
Removing braces from if statements is a great example of another dangerous thing he advocates for no justifiable reason
https://softwareengineering.stackexchange.com/questions/3202...
Which caused the big OSX/iOS SSL bug in 2014, see https://www.imperialviolet.org/2014/02/22/applebug.html
This link and thread on hackernews is good too
https://news.ycombinator.com/item?id=15440848
Some of the biggest messes I've had to clean up in my career were created by inexperienced people blindly following Uncle Bob's principles.
Pragmatism should come before all else in software IMO.
I'd be keen to hear more of this story if you've got the time to share?
That bug would be possible with braces as well. That copy paste error will not automatically disappear by using braces.
I agree with your comments, but interestingly Taleb applied to SWE would be on the polar opposite of Clean Architecture. As the comment you quoted: the "data" comes from practice and caring, the "Clean Architecture" is the pseudo-science that derived from theory instead of practice. Another viewpoint is DHH's keynote where he aligns most of web development to writing (Information System) instead of trying to derive hard rules from theory.