9 ms·

Objects Have Failed (2002)

46 points by wsc981 4y ago

h2odragon 4y ago
(2002) The worm is probably about to begin turning; the strict typing and bondage and discipline fads will fade and we'll have self modifying code seen as a cool thing again. One might argue that the "API / SaaS" fad is the 2nd coming of Objects, we just misinterpreted where the independent black boxes fit in the overall architecture.
- eternalban 4y ago
  > bondage and discipline The borrow checker in the dungeon. Like it. Take these lashings of stack trace. > we just misinterpreted where the independent black boxes fit Yep. Some folks who had worked in Sun may have come to that realization at this point. Processes as objects.
abudabi123 4y ago
Whatever Tesla's teams in sw/hw/fsd are doing appears to be state of the art at industry scale, improving year on year. Certainly, more sophisticated than F-35 sw/hw vtol control.
- eddsh1994 4y ago
  Sarcasm?
js8 4y ago
I believe objects have failed because you want to compose types (data) and functions in a different way. So any form of encapsulation (not to be confused with modularity) is too limiting.
recursivedoubts 4y ago
I hope that, with the assistance of time, we can now adopt a more aristotlean/catholic "and" vs. a platonic/puritan "or" with respect to these various language features. Object oriented programming is a perfectly reasonable way to organize a code base and the basics provide for good encapsulation. Elaborate object hierarchies and the design pattern maximalism of the early java community that lead to the hilariously germanic ThingDoerFactoryFacadeFactoryInstaniatorService abominations are obviously bad, but the basics of OO do a good job if used reasonably. Increasingly we are seeing pragmatic integration of different language features: for example using classes/objects for data modeling but using functional-style closures for data structure manipulation. Pragmatic static type systems with 'escape hatches' when needed, or dynamically typed language adding support for some static typing. Etc. This is the right thing. Not "either/or" but rather "both/and" and using the right tool for the job. The manichaeism of early language discussions can be set aside and, rather than fighting about which language is "the right thing" we can talk about which language feature(s) is/are the right thing for this particular problem.
- thesz 4y ago
  Please, define "reasonably". Because these people who created hilariously Finnish ThingDoerFactoryFacadeFactoryInstaniatorService also thought they do a reasonably reasonable job. Per your comment on "use classes for data modeling" I would like to provide you with two historical facts: it took more than 25 years to get Simula (and OO) types right [1] and it took not more than 8 years for Per Martin-Loef to have intuitionistic type theory right [2]. [1] http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%20Simula%20User%20(ECOOP%20Prize).pdf http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... [2] https://en.wikipedia.org/wiki/Intuitionistic_type_theory https://en.wikipedia.org/wiki/Intuitionistic_type_theory Classes are much harder to reason about than other type systems.
  - sebastianconcpt 4y ago
    Reasonable in this context I'd understand as: 1. ThingDoerFactoryFacadeFactoryInstaniatorService trying to represent the reality of an abstraction meant to represent a reality (an indirection that isolates the domain in that level of abstraction of an abstraction). 2. ThingCreator. An abstraction named in a way that is closer to direct reality (and that can perfectly hide its own inner complexities using composition and they could be as many or more than the ridiculous example in 1). Note that people that, conscious or unconsciously, exclude the inverted pyramid principle fall into creating 1 and people that, conscious or unconsciously, embrace it, tend to create 2 in "a reasonable" way.
  - jkaptur 4y ago
    Definition of a reasonable paradigm: millions of developers can successfully use it to build software systems used by billions. Windows, iOS, Android, Photoshop, Excel, Chrome - these are complex products that use object-oriented programming. They exist and work well. They have shipped many new features over the years.
    - ihatepython 4y ago
      Those products don't need to be complex, at their heart they are actually rather simple. They are just written in such a way that they become unnecessarily complex, because they are poorly understood. I would argue that the examples you give don't work well (Windows, Android, Chrome, later versions of iOS). They get worse and worse over time. Even if they start out with a good design, it turns to crap eventually. Just because a piece of software is used by billions doesn't mean that it is well written.
gspencley 4y ago
Here we go again. I will note that this is from 2002. But the fact that it is being recirculated now suggests that this is a timely topic. I've been a programmer for 30 some odd years. 25 of those professionally. I started on BASIC, learned C as fast as I could because I wanted to program games and all the cool kids were writing games in C. Then OOP became hot and I learned C++ and Java and was introduced to OOP design patterns and threw myself into studying Gang of Four, PLOPD and other classic works on the subject. Yes, I remember the "hot-ness" of OOP in the 90s. Next, Java, even the marketing forces that led to calling ECMAScript "Java"Script and shoe-horning objects into what was intended by Brenden Eich to be a functional language came out of this idea that OOP was the next big thing in software development. But what I don't remember was anyone, at any point in my 25 year career history, saying that OOP is the "only way." In fact, I remember having a keen interest in LISP and FP as an aspiring novice in the 90s. I wanted to learn everything about languages, language theory and computer science that I could. People encouraged me to pursue that and never once said "stick with OOP and forget other paradigms." But what I do see today, are people being so trendy and fashionable that they ARE saying these things about Functional Programming. OOP is being thrown with the bathwater HARD while people claim that it has "failed" and that everything should be Functional. Both paradigms solve problems in different ways, have their own strengths, weaknesses and value judgments. OOP values custom types and encapsulating state whereas FP favours primitives, immutability and statelessnes. OOP sees conditional logic and the root of all complexity whereas FP views state as the root of all complexity. Neither is right or wrong and both points of view are provide better tradeoffs in different situations. In other words, do your job as an engineer and pick the right tool for the problem at hand. Stop pretending that we are going to achieve some utopian panacea where we finally resolve the Church / Turing hypothesis and can say, objectively and absolutely, that one approach is always better in every situation.
- renlo 4y ago
  If your first language is Java, like mine was, then you're not even taught that there is anything _but_ OOP. It seems to me that OOP is foisted onto newbies who don't know anything else exists (why would they?), by teachers/instructors/programmers who love OOP.
mpweiher 4y ago
It should be noted that this documented one of the starting positions of a panel discussion at OOPSLA 2002: Resolved: Objects have Failed. http://www.oopsla.org/2002/fp/files/pan-1.html http://www.oopsla.org/2002/fp/files/pan-1.html http://www.oopsla.org/2002/fp/files/pan-9.html http://www.oopsla.org/2002/fp/files/pan-9.html The starting position of the "Objects have not failed" panelists is also on dreamsongs: https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html And if you take both of these seriously, I think it becomes clear that the main failure of object-orientation is that it hasn't really been done yet. From Guy Steele's remarks: Procedural programming still has its place in the coding of methods. This is true, but it is an understatement. And the crux of the problem. The place that procedural programming has is absolutely central, and there is actually little else, because even object oriented programming is ~90% writing (attached) procedures, except we call them methods. So in a way OO wrote a check that it then didn't let us cash. We should be able to construct structures of objects, with attributes and substructure, and then connect those objects to each other using various communication mechanisms. But we can't. Well, we can implement it, but we cannot express it. All we can express is procedures and procedure invocations. So we can invoke procedures to create an object, and capture creating that object in a procedure. We can connect that object to another object using another procedure call, and the communication will also be mediated using procedure calls. Where's the structure, the connecting, the communication? Hidden. Invisible in the program's source text. ("In the comments". Ha!) Just like loops and other control structures were hidden in the patterns of gotos that Dijkstra complained about. So while OOP has delivered a lot it actually has failed to deliver on one of its core promises. Because it wasn't fully implemented.
- jeremyjh 4y ago
  A distinction without a difference; what is the difference between failure of the paradigm and failure to implement the paradigm? If it hasn’t been implemented after 4-5 decades then maybe the idea just isn’t workable.
  - mpweiher 4y ago
    "Heavier than air flying machines are impossible" -- Lord Kelvin, 1895
jrm4 4y ago
I'd say the most ridiculous thing that has occurred in this space is something I'm personally dealing with in the workspace: Governments (even well meaning, I mostly don't have a problem with this) sometimes get a say in promulgating teaching standards in higher ed, and now, not merely "programming," but "Object-oriented programming" is a required prerequisite in my college program. Sigh.
bediger4000 4y ago
Sure, it's obvious when you look at the code. There's hardly any "objects" per se, but there's tons of classes and class definitions and boilerplate regarding classes. What we generally call "object-oriented" is actually "class-oriented".
mariodiana 4y ago
> But with C++ and Java, the dynamic thinking fostered by object-oriented languages was nearly fatally assaulted by the theology of static thinking inherited from our mathematical heritage and the assumptions built into our views of computing by Charles Babbage whose factory-building worldview was dominated by omniscience and omnipotence. > > And as a result we find that object-oriented languages have succumbed to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair. And, there you have it. This is a big part of the reason that I never migrated from Objective-C to Swift. When I was programming in Objective-C, I always felt challenged by the idea that I had something to learn by embracing dynamic programming, and that it would be difficult, because the rest of the "OOP" world had forgotten all about it. What's left now is only a choice of straitjackets. "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things." – Alan Kay I wish OOP had explicitly forked, all those years ago, and the C++/Java stuff could have been called something else. That would have at least cleared things up, conceptually.
- ladyattis 4y ago
  >"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things." – Alan Kay This is probably why I love programming in Cuis, Pharo, and Squeak. The ability to just write my code in small chunk as I need it. Heck, the fact that block closures exist in the language spec makes it easier to even be kind of FP-like with the code as needed by just passing along function blocks where it fits best and then reverting to the OOP messaging where it's better suited.
- mobiledev2014 4y ago
  Not to sound dismissive, but I'm curious how that's working for you? Are you still in the industry? Seems the vast majority of jobs that pay well and expect obj-c experience are in the context of "single digit percentage of our codebase is still in that and we just don't touch it."
  - mariodiana 4y ago
samsquire 4y ago
I'm interested in object orientation from the perspective that an object is a process and it has behaviours with other objects and internal mechanisms. Similar to message passing. Unfortunately I rarely see interaction diagrams of compositional nature of objects, so it's not obvious how most software is meant to work without an example sample. Am I alone that Javadocs or Doxygen docs are not enough to understand an object orientated product? I think referring to "local understanding" of objects is a really good point. The more you can understand locally, the more you can actively include in your thinking.
beepbooptheory 4y ago
Just slightly tangential, but the quality of writing and thought from this person, whom I've read quite a bit at this point, just towers above the rest. Where did all the developers like this go? People who can talk seriously about fundamental things almost totally unattached from the business world or hype cycle. It's the kind of dev I imagined was everywhere before greeting reality. More a Stanley Cavell than a Steve Jobs. Its like a little portal into a world where the humanities are (correctly) taken seriously and actually used in a field that needs it most of all. Why are the good thoughtful writers like this? Why are the ones who do exist always lisp guys?
- rileyphone 4y ago
  rpg is a gem, I highly recommend his book Patterns of Software for both philosophizing about software and as a memoir of his career.
- jrvarela56 4y ago
  My hunch is that they are older ('Lisp guys') and, as more devs come online, are a smaller minority with each year that passes.
- testudovictoria 4y ago
  My guess is that the older folks who have the experience to speak deeply about these topics aren't interested in maintaining a blog. One of my most interesting college professors worked on chess engines professionally. He has a small online presence, but his commentary is usually in response to pointed questions or wild claims about chess engines. The guy has stories upon stories about both hardware and software design and their impact on performance at both high and low level. All of his tangents in class were downright fascinating.
dang 4y ago
Related ongoing thread: Objects Have Not Failed (2002) - https://news.ycombinator.com/item?id=34996807 https://news.ycombinator.com/item?id=34996807 - March 2023 (3 comments)
rco8786 4y ago
20 years later objects are alive and well though
pavlov 4y ago
OOP is still a good model for systems where most objects are long-lived, local, mutation latency is low, and the number of objects is reasonable. Like GUIs and simulations. (Not coincidentally those are the domains where OO was introduced.) It’s not a good fit for systems that respond to short-lived requests. If your objects’ lifetimes are never longer than a HTTP request, you shouldn’t be using OOP. It’s not the right model! (I call this “kamikaze OOP”: you build a complex piece of machinery in memory and crash it down the next instant.) At the other end of the spectrum, if your real-time system deals with potentially huge amounts of objects, then OO isn’t a good fit either because it doesn’t easily let you optimize memory layouts so you could loop over all that data. Something like ECS (entity component system) is probably a better fit.
- kaba0 4y ago
  I fail to see what does OOP, a paradigm, has to do with short-lived requests’ resource requirements or ECS. There is no reason why both couldn’t be handled by an OOP programing language. These are just implementation details.
hota_mazi 4y ago
This article gets reposted about every year and every year, it's demonstrated to be completely wrong :-)
H4ZB7 4y ago
"java trying to force its world view" is the correct way to design a programming language, just java is a bad language, and only half way forces its world view when it has to be 100% for this idea to work. in the sense that there shouldn't be things like int32 in a high level language. also the OOP paradigm makes no sense and is just pseudoscience. i can't even think of a valid reason to use objects once you get past the cat/dog/animal example which only makes no sense because the proposed problem has no concrete requirements. there are no small examples where objects make sense, and for any big example it would require days of analysis to reach a conclusion. there are lots of invalid reasons, like some syntactic convenience of x.fff().zzz(), this example being invalid because that syntactic benefit can be better achieved by a composition operator like in bash: x | fff | zzz if i look at any OOP codebase the first thing ill see is someone pointlessly loads up some data into an object and calls obj.method() which then just unloads the data as if they were just parameters to that function. why did you even make the object in the first place? because OOP braindamage, simple. you've been trained that this is somehow the ethically correct way to do things. the idea that objects provide some new type of abstraction is just nonsense. those constructs were already doable in ML as well as by convention in C or any imperative language, which is how most such languages are in fact written. all OO adds is interfaces which are done better by many other languages, and inheritance which is just a joke.
- zabzonk 4y ago
  > if i look at any OOP codebase the first thing ill see is someone pointlessly loads up some data into an object and calls obj.method() which then just unloads the data as if they were just parameters to that function. nope, never seen that. it seems you have only ever looked at bad code. or maybe only ever written it?
  - H4ZB7 4y ago
    [dead]
- nh23423fefe 4y ago
  > i can't even think of a valid reason to use objects once you get past the cat/dog/animal example Because you have internalized the braindamage you claim others have. If you think "an object in code corresponds to an object in the real world" then you are victim of the object=noun method=verb braindamage. An object is just a tuple. A method is just a procedure with an implicit param. OO is a way to factor code into pieces and to name and reuse those pieces. inheritance is for liskov substitution.

46 points by wsc981 4y ago

(2002) The worm is probably about to begin turning; the strict typing and bondage and discipline fads will fade and we'll have self modifying code seen as a cool thing again. One might argue that the "API / SaaS" fad is the 2nd coming of Objects, we just misinterpreted where the independent black boxes fit in the overall architecture.

eternalban 4y ago
> bondage and discipline The borrow checker in the dungeon. Like it. Take these lashings of stack trace. > we just misinterpreted where the independent black boxes fit Yep. Some folks who had worked in Sun may have come to that realization at this point. Processes as objects.

abudabi123 4y ago

Whatever Tesla's teams in sw/hw/fsd are doing appears to be state of the art at industry scale, improving year on year. Certainly, more sophisticated than F-35 sw/hw vtol control.

eddsh1994 4y ago
Sarcasm?

js8 4y ago

I believe objects have failed because you want to compose types (data) and functions in a different way. So any form of encapsulation (not to be confused with modularity) is too limiting.

recursivedoubts 4y ago

I hope that, with the assistance of time, we can now adopt a more aristotlean/catholic "and" vs. a platonic/puritan "or" with respect to these various language features. Object oriented programming is a perfectly reasonable way to organize a code base and the basics provide for good encapsulation. Elaborate object hierarchies and the design pattern maximalism of the early java community that lead to the hilariously germanic ThingDoerFactoryFacadeFactoryInstaniatorService abominations are obviously bad, but the basics of OO do a good job if used reasonably. Increasingly we are seeing pragmatic integration of different language features: for example using classes/objects for data modeling but using functional-style closures for data structure manipulation. Pragmatic static type systems with 'escape hatches' when needed, or dynamically typed language adding support for some static typing. Etc. This is the right thing. Not "either/or" but rather "both/and" and using the right tool for the job. The manichaeism of early language discussions can be set aside and, rather than fighting about which language is "the right thing" we can talk about which language feature(s) is/are the right thing for this particular problem.

thesz 4y ago
Please, define "reasonably". Because these people who created hilariously Finnish ThingDoerFactoryFacadeFactoryInstaniatorService also thought they do a reasonably reasonable job. Per your comment on "use classes for data modeling" I would like to provide you with two historical facts: it took more than 25 years to get Simula (and OO) types right [1] and it took not more than 8 years for Per Martin-Loef to have intuitionistic type theory right [2]. [1] http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%20Simula%20User%20(ECOOP%20Prize).pdf http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... [2] https://en.wikipedia.org/wiki/Intuitionistic_type_theory https://en.wikipedia.org/wiki/Intuitionistic_type_theory Classes are much harder to reason about than other type systems.
- sebastianconcpt 4y ago
  Reasonable in this context I'd understand as: 1. ThingDoerFactoryFacadeFactoryInstaniatorService trying to represent the reality of an abstraction meant to represent a reality (an indirection that isolates the domain in that level of abstraction of an abstraction). 2. ThingCreator. An abstraction named in a way that is closer to direct reality (and that can perfectly hide its own inner complexities using composition and they could be as many or more than the ridiculous example in 1). Note that people that, conscious or unconsciously, exclude the inverted pyramid principle fall into creating 1 and people that, conscious or unconsciously, embrace it, tend to create 2 in "a reasonable" way.
- jkaptur 4y ago
  Definition of a reasonable paradigm: millions of developers can successfully use it to build software systems used by billions. Windows, iOS, Android, Photoshop, Excel, Chrome - these are complex products that use object-oriented programming. They exist and work well. They have shipped many new features over the years.
  - ihatepython 4y ago
    Those products don't need to be complex, at their heart they are actually rather simple. They are just written in such a way that they become unnecessarily complex, because they are poorly understood. I would argue that the examples you give don't work well (Windows, Android, Chrome, later versions of iOS). They get worse and worse over time. Even if they start out with a good design, it turns to crap eventually. Just because a piece of software is used by billions doesn't mean that it is well written.

gspencley 4y ago

Here we go again. I will note that this is from 2002. But the fact that it is being recirculated now suggests that this is a timely topic. I've been a programmer for 30 some odd years. 25 of those professionally. I started on BASIC, learned C as fast as I could because I wanted to program games and all the cool kids were writing games in C. Then OOP became hot and I learned C++ and Java and was introduced to OOP design patterns and threw myself into studying Gang of Four, PLOPD and other classic works on the subject. Yes, I remember the "hot-ness" of OOP in the 90s. Next, Java, even the marketing forces that led to calling ECMAScript "Java"Script and shoe-horning objects into what was intended by Brenden Eich to be a functional language came out of this idea that OOP was the next big thing in software development. But what I don't remember was anyone, at any point in my 25 year career history, saying that OOP is the "only way." In fact, I remember having a keen interest in LISP and FP as an aspiring novice in the 90s. I wanted to learn everything about languages, language theory and computer science that I could. People encouraged me to pursue that and never once said "stick with OOP and forget other paradigms." But what I do see today, are people being so trendy and fashionable that they ARE saying these things about Functional Programming. OOP is being thrown with the bathwater HARD while people claim that it has "failed" and that everything should be Functional. Both paradigms solve problems in different ways, have their own strengths, weaknesses and value judgments. OOP values custom types and encapsulating state whereas FP favours primitives, immutability and statelessnes. OOP sees conditional logic and the root of all complexity whereas FP views state as the root of all complexity. Neither is right or wrong and both points of view are provide better tradeoffs in different situations. In other words, do your job as an engineer and pick the right tool for the problem at hand. Stop pretending that we are going to achieve some utopian panacea where we finally resolve the Church / Turing hypothesis and can say, objectively and absolutely, that one approach is always better in every situation.

renlo 4y ago
If your first language is Java, like mine was, then you're not even taught that there is anything _but_ OOP. It seems to me that OOP is foisted onto newbies who don't know anything else exists (why would they?), by teachers/instructors/programmers who love OOP.

mpweiher 4y ago

It should be noted that this documented one of the starting positions of a panel discussion at OOPSLA 2002: Resolved: Objects have Failed. http://www.oopsla.org/2002/fp/files/pan-1.html http://www.oopsla.org/2002/fp/files/pan-1.html http://www.oopsla.org/2002/fp/files/pan-9.html http://www.oopsla.org/2002/fp/files/pan-9.html The starting position of the "Objects have not failed" panelists is also on dreamsongs: https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html And if you take both of these seriously, I think it becomes clear that the main failure of object-orientation is that it hasn't really been done yet. From Guy Steele's remarks: Procedural programming still has its place in the coding of methods. This is true, but it is an understatement. And the crux of the problem. The place that procedural programming has is absolutely central, and there is actually little else, because even object oriented programming is ~90% writing (attached) procedures, except we call them methods. So in a way OO wrote a check that it then didn't let us cash. We should be able to construct structures of objects, with attributes and substructure, and then connect those objects to each other using various communication mechanisms. But we can't. Well, we can implement it, but we cannot express it. All we can express is procedures and procedure invocations. So we can invoke procedures to create an object, and capture creating that object in a procedure. We can connect that object to another object using another procedure call, and the communication will also be mediated using procedure calls. Where's the structure, the connecting, the communication? Hidden. Invisible in the program's source text. ("In the comments". Ha!) Just like loops and other control structures were hidden in the patterns of gotos that Dijkstra complained about. So while OOP has delivered a lot it actually has failed to deliver on one of its core promises. Because it wasn't fully implemented.

jeremyjh 4y ago
A distinction without a difference; what is the difference between failure of the paradigm and failure to implement the paradigm? If it hasn’t been implemented after 4-5 decades then maybe the idea just isn’t workable.
- mpweiher 4y ago
  "Heavier than air flying machines are impossible" -- Lord Kelvin, 1895

jrm4 4y ago

I'd say the most ridiculous thing that has occurred in this space is something I'm personally dealing with in the workspace: Governments (even well meaning, I mostly don't have a problem with this) sometimes get a say in promulgating teaching standards in higher ed, and now, not merely "programming," but "Object-oriented programming" is a required prerequisite in my college program. Sigh.

bediger4000 4y ago

Sure, it's obvious when you look at the code. There's hardly any "objects" per se, but there's tons of classes and class definitions and boilerplate regarding classes. What we generally call "object-oriented" is actually "class-oriented".

mariodiana 4y ago

> But with C++ and Java, the dynamic thinking fostered by object-oriented languages was nearly fatally assaulted by the theology of static thinking inherited from our mathematical heritage and the assumptions built into our views of computing by Charles Babbage whose factory-building worldview was dominated by omniscience and omnipotence. > > And as a result we find that object-oriented languages have succumbed to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair. And, there you have it. This is a big part of the reason that I never migrated from Objective-C to Swift. When I was programming in Objective-C, I always felt challenged by the idea that I had something to learn by embracing dynamic programming, and that it would be difficult, because the rest of the "OOP" world had forgotten all about it. What's left now is only a choice of straitjackets. "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things." – Alan Kay I wish OOP had explicitly forked, all those years ago, and the C++/Java stuff could have been called something else. That would have at least cleared things up, conceptually.

ladyattis 4y ago
>"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things." – Alan Kay This is probably why I love programming in Cuis, Pharo, and Squeak. The ability to just write my code in small chunk as I need it. Heck, the fact that block closures exist in the language spec makes it easier to even be kind of FP-like with the code as needed by just passing along function blocks where it fits best and then reverting to the OOP messaging where it's better suited.
mobiledev2014 4y ago
Not to sound dismissive, but I'm curious how that's working for you? Are you still in the industry? Seems the vast majority of jobs that pay well and expect obj-c experience are in the context of "single digit percentage of our codebase is still in that and we just don't touch it."
- mariodiana 4y ago

samsquire 4y ago

I'm interested in object orientation from the perspective that an object is a process and it has behaviours with other objects and internal mechanisms. Similar to message passing. Unfortunately I rarely see interaction diagrams of compositional nature of objects, so it's not obvious how most software is meant to work without an example sample. Am I alone that Javadocs or Doxygen docs are not enough to understand an object orientated product? I think referring to "local understanding" of objects is a really good point. The more you can understand locally, the more you can actively include in your thinking.

beepbooptheory 4y ago

Just slightly tangential, but the quality of writing and thought from this person, whom I've read quite a bit at this point, just towers above the rest. Where did all the developers like this go? People who can talk seriously about fundamental things almost totally unattached from the business world or hype cycle. It's the kind of dev I imagined was everywhere before greeting reality. More a Stanley Cavell than a Steve Jobs. Its like a little portal into a world where the humanities are (correctly) taken seriously and actually used in a field that needs it most of all. Why are the good thoughtful writers like this? Why are the ones who do exist always lisp guys?

rileyphone 4y ago
rpg is a gem, I highly recommend his book Patterns of Software for both philosophizing about software and as a memoir of his career.
jrvarela56 4y ago
My hunch is that they are older ('Lisp guys') and, as more devs come online, are a smaller minority with each year that passes.
testudovictoria 4y ago
My guess is that the older folks who have the experience to speak deeply about these topics aren't interested in maintaining a blog. One of my most interesting college professors worked on chess engines professionally. He has a small online presence, but his commentary is usually in response to pointed questions or wild claims about chess engines. The guy has stories upon stories about both hardware and software design and their impact on performance at both high and low level. All of his tangents in class were downright fascinating.

dang 4y ago

Related ongoing thread: Objects Have Not Failed (2002) - https://news.ycombinator.com/item?id=34996807 https://news.ycombinator.com/item?id=34996807 - March 2023 (3 comments)

rco8786 4y ago

20 years later objects are alive and well though

pavlov 4y ago

OOP is still a good model for systems where most objects are long-lived, local, mutation latency is low, and the number of objects is reasonable. Like GUIs and simulations. (Not coincidentally those are the domains where OO was introduced.) It’s not a good fit for systems that respond to short-lived requests. If your objects’ lifetimes are never longer than a HTTP request, you shouldn’t be using OOP. It’s not the right model! (I call this “kamikaze OOP”: you build a complex piece of machinery in memory and crash it down the next instant.) At the other end of the spectrum, if your real-time system deals with potentially huge amounts of objects, then OO isn’t a good fit either because it doesn’t easily let you optimize memory layouts so you could loop over all that data. Something like ECS (entity component system) is probably a better fit.

kaba0 4y ago
I fail to see what does OOP, a paradigm, has to do with short-lived requests’ resource requirements or ECS. There is no reason why both couldn’t be handled by an OOP programing language. These are just implementation details.

hota_mazi 4y ago

This article gets reposted about every year and every year, it's demonstrated to be completely wrong :-)

H4ZB7 4y ago

"java trying to force its world view" is the correct way to design a programming language, just java is a bad language, and only half way forces its world view when it has to be 100% for this idea to work. in the sense that there shouldn't be things like int32 in a high level language. also the OOP paradigm makes no sense and is just pseudoscience. i can't even think of a valid reason to use objects once you get past the cat/dog/animal example which only makes no sense because the proposed problem has no concrete requirements. there are no small examples where objects make sense, and for any big example it would require days of analysis to reach a conclusion. there are lots of invalid reasons, like some syntactic convenience of x.fff().zzz(), this example being invalid because that syntactic benefit can be better achieved by a composition operator like in bash: x | fff | zzz if i look at any OOP codebase the first thing ill see is someone pointlessly loads up some data into an object and calls obj.method() which then just unloads the data as if they were just parameters to that function. why did you even make the object in the first place? because OOP braindamage, simple. you've been trained that this is somehow the ethically correct way to do things. the idea that objects provide some new type of abstraction is just nonsense. those constructs were already doable in ML as well as by convention in C or any imperative language, which is how most such languages are in fact written. all OO adds is interfaces which are done better by many other languages, and inheritance which is just a joke.

zabzonk 4y ago
> if i look at any OOP codebase the first thing ill see is someone pointlessly loads up some data into an object and calls obj.method() which then just unloads the data as if they were just parameters to that function. nope, never seen that. it seems you have only ever looked at bad code. or maybe only ever written it?
- H4ZB7 4y ago
  [dead]
nh23423fefe 4y ago
> i can't even think of a valid reason to use objects once you get past the cat/dog/animal example Because you have internalized the braindamage you claim others have. If you think "an object in code corresponds to an object in the real world" then you are victim of the object=noun method=verb braindamage. An object is just a tuple. A method is just a procedure with an implicit param. OO is a way to factor code into pieces and to name and reuse those pieces. inheritance is for liskov substitution.