TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

No, that's not why OO sucks

76 pointsby johndcookalmost 13 years ago

20 comments

fusiongyroalmost 13 years ago
As time goes on, my bafflement at our collective need to swear allegiance to our tools is turning into bewilderment. Our tools have objective, technical merits and flaws, but our love and hate for them is subjective and mostly useless. Cargo cult behavior is the real problem, and the endless bickering and correcting that articles like Joe's and this one contain only serve to perpetuate it.
评论 #4251441 未加载
评论 #4251865 未加载
评论 #4251527 未加载
评论 #4251511 未加载
评论 #4252771 未加载
glassxalmost 13 years ago
I really don't know why people seem to think that post is the <i>final</i> position of Joe Armstrong about OOP. It's a very old post, without any context, and since then he has gone on record praising Smalltalk and Alan Kay's take on objects many times:<p><a href="http://infoq.com/interviews/johnson-armstrong-oop/" rel="nofollow">http://infoq.com/interviews/johnson-armstrong-oop/</a> <a href="http://erlang.org/pipermail/erlang-questions/2010-August/052836.html" rel="nofollow">http://erlang.org/pipermail/erlang-questions/2010-August/052...</a>
greghinchalmost 13 years ago
I've noticed a pattern with people who rally against OO, that when you get down to the core of their argument and what irks them, they really just don't like Java, with all its superfluous-feeling ceremony code. Maybe try a lighter OO implementation first before you decry an entire methodology.
评论 #4251870 未加载
评论 #4251647 未加载
评论 #4252009 未加载
评论 #4255555 未加载
评论 #4251983 未加载
AndrewOalmost 13 years ago
I think the author and Armstrong have significantly different ideas of what a "type" is. That's not a huge surprise—depending on background, you'll often get several definitions from different people.<p>One way to see types are things with fundamentally different access pattern: individual entities, sequentially retrieved ones (e.g. lists), fixed-length ordered lists whose elements are accessed positionally (e.g. tuples/vectors, fixed-length maps whose keys are known at compile-time/records/objects can also be viewed this way), unordered collections of distinct entities (sets), etc. I'd argue Armstrong's view is similar to this based on what he put in Erlang.<p>I can't tell what the author's view is, aside from "a class is a data type". This suggests that he equates a type with the set of functions that can be called on something and not have the compiler or runtime blow up (or perhaps, the set of functions that the programmer, by putting them in the same file, has explicitly said won't blow-up, whether or not that set is correct or complete). This throws fundamentally different things like lists, tuples, sets onto the same level as Person, Account, and PayrollRecord—which are often just short-hand names for tuples with different arities or names for their elements' positions.<p>If one has the later view, confusion over the point 3 is understandable: creating a new type for time is easy, just do class Time and define a bunch of properties and methods. In Armstrong's example, time is just a 6-tuple (or 3-tuple if all you want is hms). If you wanted to store it or send it over the wire, anything that could handle a tuple of integers would already know how to use it. If one function calls the last member "sec" and another "second", they're local names, so it doesn't matter as long as they're both accessing the same member.<p>One can object that it's easy to write serializers or that a compiler or library could figure it out, or that having different names for the same data elements indicates inconsistency in code that should be caught earlier. De gustibus non est disputandum. But, don't throw up your hands and say "this makes no sense!" without considering another perspective first.
评论 #4253260 未加载
shin_laoalmost 13 years ago
Objection 1: The OP should take a look at the STL.<p>Coupling N algorithms and M structures may lead to M * N implementations where you really want only N + M implementations.<p>Additionally, decoupling algorithms and structures will probably make you write better interfaces for your structures.
评论 #4251778 未加载
评论 #4251972 未加载
aidenn0almost 13 years ago
A better "functions should be separate from objects" is for the fairly common case where there is a function that takes arguments of two (or more) different classes as arguments; which class should that belong to? It gets even worse when the function is commutative.
评论 #4251455 未加载
pfrazealmost 13 years ago
Not sure where I sit on the issue, but I wanted to add this:<p>By putting the functions in the class definition, they become locked into that class. Other data structures could potentially make use of the function, but now they don't own it. I would say the alternative is a namespace, which you don't instantiate.<p>Armstrong's grief is the idea that the functionality for classes can then only come from direct lineage. As I understand it, though, the OO-heavy languages (Java, C#, probably others) lean much more heavily on interfaces now to mix in behavior, which gets away from that specific problem.<p>[EDIT] I forgot that interfaces don't give implementation, so the mixing is pretty limited.<p>Not sure what I think of the state issue, though. Too green on the functional stuff to say how else it should work. I would point out, though, that programs hide state from each other; couldn't objects just be the same thing on a smaller scale? (That is, an opaque interface with a few access points.) It really comes down to how well it's made in both cases.
评论 #4251349 未加载
评论 #4251386 未加载
gueloalmost 13 years ago
I think in practice most OO programs end up with two general kinds of classes. Some are more for data structures, e.g. User or Address classes, and others are more for functions like IOWriter or DAOs.<p>But there aren't strict dividing lines between these two types, you end up mixing and matching functions and data as you see fit to help organize things. So you might put state into your function classes, such as the DB connection in a DAO:<p><pre><code> db = DBGetter.get("serverAddress;dbName;username;password;") userDao = new UserDao(db) User user = userDao.getUserById(123) </code></pre> You might also end up putting functions in your data classes, but you might not. As an example, to calculate the distance between two addresses you could put the function in the Address class:<p><pre><code> float miles = address1.distanceTo(address2) </code></pre> Or you could create a DistanceCalculator class that mostly just holds functions:<p><pre><code> float miles = distanceCalculator.distanceBetween(address1, address2) </code></pre> There are pros and cons to either design, personally I would go with the second one, but the point is that you have a choice. OO provides a flexible framework and there are many ways to design your classes. That's why there are a bunch of books on OO patterns and best practices, to help design the structure of classes. You can even work in a very functional/stateless style if you want to.<p>What OO gives you are tools for organizing your code but you can organize in many ways, some ways that help and some that hinder. As others have said, it's just a tool.
评论 #4251620 未加载
MatthewPhillipsalmost 13 years ago
&#62; The basic idea of OO is that data and functions are bundled together, which is an idea that Armstrong seems to hold a grudge against (objection 1). But he gives no arguments as to why this is a bad idea.<p>Code reuse. Functions that are tied to a data type are less likely to be reused, and if you find that you want to reuse one it will, a lot of the time, require major refactoring (perhaps you have to move the function to a parent class, or create an entirely new class that represents the thing that is common between this data type's use and other data types' use of the function).<p>Whereas if your data and function are never coupled you actually wind up writing more generic functions that don't care about the type they are operating on.
评论 #4251995 未加载
sbmasseyalmost 13 years ago
OO is a good fit for programming a lot of important types of software, such as GUI's or 3D graphics, where it is convenient to model the program data as consisting of widely different types of data structure, having a common interface, and which are easy to add new types to without having to change existing code.<p>Other than that, most use of OO is really just applying the language's OO structures to software idioms that exist outside OO, such as modules, or data hiding, or closures, and so forth.<p>The only times OO actively sucks is when you're trying to do non-OO stuff in a highly-OO language, such as trying to do algorithmic code in Java.
pjmlpalmost 13 years ago
I think that most people that bash OO fail to understand how to use it properly.<p>From my experience many are also pretty bad at doing ADTs in module based languages.<p>OO has quite a few powerful concepts, and not all languages that are OO based explore the same set of concepts.<p>This is why the best languages to work with, are the ones which offer multi-paradigms, allowing the developers to pick the best abstractions for each scenario.
评论 #4253778 未加载
评论 #4252026 未加载
ww520almost 13 years ago
I don't get how state being evil. Pure functional program also has state. Its state are the arguments passed around between functions.<p>What people talk about the evilness of state really is the scope of the state. In a typical program, there could be global state in global variable, local state in function local variable, and the state passed around in function parameter. OO adds the instance level scope state for instance variables.<p>All these different levels of scoping are tools for programmers to manage the complexity in a program. If you don't like global scope, don't use it. If you don't like instance level scope, don't use it. Pure functional code are NOT appropriate 100% of the time. A global variable can be simpler and cleaner to get the job done. There are times for different tricks in a toolset. Use the right tool for the right problem.<p>edit: added the NOT. Bad omission completely changed the meaning.
评论 #4252884 未加载
评论 #4251980 未加载
halaylialmost 13 years ago
I find it funny that programmers are debating why we should hate OO. It's like we know we should hate it but we are still in progress of figuring out why.
blahbapalmost 13 years ago
The title suggests that the aurhor will provide reasons for why OO actually is bad, but he doesn't. Why is it so fashionable to bash OO anyway? It's just a tool, it can be used wisely, but often it is not, which gives no reason to blame OO.
评论 #4251406 未加载
joelthelionalmost 13 years ago
OO doesn't suck, it's just a tool among others in the toolbox. What sucks is making a religion of it.
评论 #4251637 未加载
评论 #4251697 未加载
zwiebackalmost 13 years ago
Anyone participating in these types of discussions should start with a disclaimer whether they are talking about static typing, where types are largely equated with classes (aka "class-based" programming), or message passing, where types are largely orthogonal to classes.<p>The latter concept is what Alan Kay had in mind when he "invented" OO although arguably C++ and Java have really popularized OO as class-based programming.
评论 #4252001 未加载
maleroalmost 13 years ago
OOP is just another tool in my toolbox. It makes a lot of sense for some problems, and none at all for all of the rest.
shimshamalmost 13 years ago
Which is what makes PHP so good, as you're not forced to use any particular style of programming. Or C.
评论 #4251343 未加载
评论 #4251755 未加载
评论 #4251312 未加载
ajucalmost 13 years ago
Ad 4 I don't see how you can do OO without state.
sodelatealmost 13 years ago
OO,really matters