141–149 of 149 posts
Earlier quoted context omitted.
Years ago, I started an implementation of that book: https://github.com/linkdd/ooduck Never truly finished it, but it works well :)
Fyi, fwiw, the top-of-page "About Duck-Typing C library based on ooc.pdf linkdd.github.com/ooduck/ " link is currently 404.
Earlier quoted context omitted.
"plagiarized argument" I'm just curious what I plagiarized.
> "plagiarized argument" > I'm just curious what I plagiarized. You perfectly understand what "passive-aggressive" means. Just don't go around patronizing people like that, nobody died and made you god.
I've seen OOP inheritance in C before. It involves a table of pointers to functions, and a derived "class" would just point to a different table. It works, but all the machinery has to be handled manually. It's very, very easy to make a mistake. The question is, why do this? Just use C++ as "C with classes" and you'll be much better off.
the implementation in the article is basically what Golang is. and the question: "so much manual/repetitive work, why do this"... is still valid.
Earlier quoted context omitted.
https://news.ycombinator.com/item?id=34220101
This isn’t a religion. I really don’t see what is so controversial about suggesting OOP has clearly failed on the majority of its original stated goals. That’s not to say that nothing has been salvaged from the wreckage; languages like Rust are a great example of retaining what actually was useful.
Because it is not borne out by facts. The explosion of software since the 80's(?) was a direct result of OOD/OOP becoming the dominant paradigm.
Your posts remind me of this: https://twitter.com/awbjs/status/625082965257654272
Earlier quoted context omitted.
This isn’t a religion. I really don’t see what is so controversial about suggesting OOP has clearly failed on the majority of its original stated goals. That’s not to say that nothing has been salvaged from the wreckage; languages like Rust are a great example of retaining what actually was useful.
>I really don’t see what is so controversial about suggesting OOP has clearly failed on the majority of its original stated goals. Because it is not borne out by facts. The explosion of software since the 80's(?) was a direct result of OOD/OOP becoming the dominant paradigm. Your posts remind me of this: https://twitter.com/awbjs/status/625082965257654272
Please do go on and prove how the explosion of software since the 80s was the direct result of OOD/OOP. Please be sure to reference Linus, Joe Armstrong, Alexander Stepanov. Surely such undeniable facts will be supported by relevant leaders in the field?
This quote from Eric Lippert clearly sums your position well “ “It may be that this success is a consequence of a massive industry that supports and is supported by OOP.” which is true by virtue of it being tautological.
We can do better than a tautology to answer the question posed in the title of the piece by observing that OOP style directly and deliberately maps well to the typical hierarchical organization of large corporations. Why do we hate working in OOP? For the same reasons we hate working for inflexible, siloed, process-heavy, policy-heavy, bureaucratic, mutually-distrusting teams in corporations. Why is it a success? For the same reasons that those corporations are successful: organizations with those characteristics have historically been strongly correlated with creation of value that increases the wealth of the billionaire class, and therefore billionaires pay for the creation of those systems.
It should be no surprise that OOP style is popular in corporations; OOP is the reification in code of corporate thought patterns.”
I've seen OOP inheritance in C before. It involves a table of pointers to functions, and a derived "class" would just point to a different table. It works, but all the machinery has to be handled manually. It's very, very easy to make a mistake. The question is, why do this? Just use C++ as "C with classes" and you'll be much better off.
The main advantage of C++ isn't really OOP, its all the standard library features and smart pointers, but those are not always applicable (like when you want to manage memory as efficient as possible). So using C is often preferred.
Earlier quoted context omitted.
I wasn't too keen on this book. I read it hoping it would be more like the article in this post. But I felt it was more a case of someone re-inventing c++ with macros.
You mean "C with classes" ?
i was basically reiterating my comment from there.
Earlier quoted context omitted.
>I really don’t see what is so controversial about suggesting OOP has clearly failed on the majority of its original stated goals. Because it is not borne out by facts. The explosion of software since the 80's(?) was a direct result of OOD/OOP becoming the dominant paradigm. Your posts remind me of this: https://twitter.com/awbjs/status/625082965257654272
So my views are hopelessly uninformed opinions, while yours are undeniable facts? Please do go on and prove how the explosion of software since the 80s was the direct result of OOD/OOP. Please be sure to reference Linus, Joe Armstrong, Alexander Stepanov. Surely such undeniable facts will be supported by relevant leaders in the field? This quote from Eric Lippert clearly sums your position well “ “It may be that this…
In a sense, Yes; because you are the one who made blanket statements like "OO was just a failed paradigm anyway," which is objectively wrong.
To elaborate on my comments, almost every language since the 80's has had very good support for OOP. Almost all reusable libraries/frameworks (especially GUIs) also are implemented using the OOP paradigm so much so that nowadays the kids don't even know of a world before "Objects". The success of OOD/OOP in the industry is self-evident.
If certain aspects of OOD/OOP have to be used carefully (eg. Implementation Inheritance) and how abuse of OOP (eg. everything is an Object) can make a mess of things, then that can be debated, but to dismiss the whole of OOD/OOP is just plain silly.
Coming to your "appeal to authority", let me clarify the nuances in their writings/quotes.
Linus Torvalds: His objection is not to OOP per-se (indeed the Linux Kernel uses a lot of OO patterns itself; see the articles by Neil Brown on lwn.net; links in my past comments) but certain aspects of it and in particular; to the C++ implementation of those. These are valid for his Kernel but not for others.
Joe Armstrong: His focus was on "Concurrency Oriented Programming with no Shared State". From that pov his design of Erlang "Processes" is exactly as Alan Kay envisioned OOP. Here is Armstrong himself: https://elixirforum.com/t/the-oop-concept-according-to-erlan... More here: https://stackoverflow.com/questions/3431509/is-erlang-object...
Alexander Stepanov: His background is in Mathematics and hence he looks at Programming from the pov of Abstract Algebra. His issue is with straitjacketing "Interface Inheritance" within a single type hierarchy whereas logically a subtype can span multiple hierarchies. This is also the reason Bertrand Meyer called "Multiple Inheritance" indispensable.
Eric Lippert: Your listed quote doesn't make sense, i am almost sure he was saying it "tongue-in-cheek" to draw attention to the fact that dysfunctional OO codebases are similar to dysfunctional organizations. It is not a value judgement on OOD/OOP.
In summary; OOD/OOP is a way of structuring Procedural/Imperative programming where global state is partitioned into smaller pieces along with their transformers which helps you manage Modularization, Types, Type hierarchies, Modeling real world "Objects", Reusability, Extensibility and Maintenance.
Earlier quoted context omitted.
Using ADT to mean “abstract data type” does not mean anything more than what most people mean when they say “type”. Outside of distinguishing from other meanings of the word “type” there is no practical reason to ever say it. It doesn’t sound fancy, it just sounds like getting high on your own supply of acronyms. It is not an important term to learn as a beginner in the first chapters of a programming book. We should…
> Using ADT to mean “abstract data type” does not mean anything more than what most people mean when they say “type”. Abstract data type is a type where you don't get direct access to the information contained in it. The encapsulation is what makes it "abstract".