Joe Is Wrong (2009)
goran.krampe.se
Joe Is Wrong (2009)
1–10 of 86 posts
Re: Joe Is Wrong (2009)
#2Re: Joe Is Wrong (2009)
#3There are a bunch of topics like this, in my own area you see the same four or five topics come up repeatedly with nothing new or interesting said on them.
I'm kind of intrigued if anyone has any thoughts on how to shock life back into these zombie debates?
Re: Joe Is Wrong (2009)
#4Re: Joe Is Wrong (2009)
#5I'm surprised that the original anti-Object Oriented Programming article says "data structures and functions should not be bound together" since in functional programming (if we take that as the extreme opposite of OO) they are still kinda bound together. Like if you have a JS array ['cricket', 'football', 'badminton'] it is both data and almost like a function at the same time, since you can iterate through the items and make code execute for each
For example in a webpage if there is a div id=football then you can select it using:
['cricket', 'football', 'badminton'].forEach(function (i) { document.getElementById(i); } );
In my mind this type of code really blurs the line between variables and functions
Re: Joe Is Wrong (2009)
#6OO has it’s place in the space of possible patterns to choose from based on the kind of solution you need. I think these overarching claims of superiority are missing the point completely. I personally like a combination of function and OO concepts that can work synergistically together and play the kind of role that they excel in individually.
Re: Joe Is Wrong (2009)
#7I would like to see someone do a language that enforces all of the OO paradigms and best practices on the programmer, just to see what the resulting code would look like and behave.
For instance, I'd love to see a compiler than throws a error if you violate the single responsibility principle. Much of the OO spaghetti code I've seen have been because objects are basically just structs with methods and 10 different ways and object could change state.
For practical purposes I doubt I'd ever use such a strict language, but it would be interesting to see if the result is safer and clear code. I suspect it's more code though.
Re: Joe Is Wrong (2009)
#8I can see that Erlang and Joe's (RIP) insights about OO might conflict with your view of the world, but IMHO that's just because of the OO indoctrination people grew up with.
Recommend learning key concepts of OTP/Erlang/Elixir first, and then revisit your initial opinions.
You might even conclude Joe Was Right
Re: Joe Is Wrong (2009)
#9What I've found with all these "paradigms" is that they're only beneficial some of the time, usually not most of the time, never all of the time. It takes some experience and and an anti-dogmatic attitude to judge, for example, when a black box is a good choice and when plain old data is a good choice. Woe to those who attempt to shoehorn their idea of purity unto every application domain they encounter.
Sounds boring, but judgement is what the work is about. When you're talking about a specific system you can say "I think we should use OO for this" because so-and-so. But each system needs its own explanation.
Re: Joe Is Wrong (2009)
#10The thing I find interesting about revisiting these old pieces is that the debate about the merits of OOP is effectively stymied. This post and the article it replied to posted yesterday ( https://news.ycombinator.com/item?id=26586829 ) could effectively have been written today. And the debate in the comments tends to be pretty formulaic as well. It's one of those perennial topics that generates a lot of heat from re…
Instead of rehashing "Is OOP good, actually?", we should explore the boundaries of the paradigm by making a popular language that's based on prototypes, or that privileges composition over inheritance, or pulls apart the various pieces of OOP into standalone concepts that can be mixed and matched. If we get inspired, maybe come up with some new pattern or language affordance that's similarly groundbreaking to functions, objects, classes, message-passing, threads, or whatever. Maybe the obviously-better development paradigm of 2050 hasn't been articulated, yet.