Hacker News Reader

"We should ask what we need to do to design well-factored programs that are cohesive without being coupled and then design language features that directly address those organization requirements"

Language designers have been chasing that chimera for decades now. An unfortunate (in my mind at least) side effect has been legions of new programmers that are ready to fight to the death over concepts (separation of presentation and logic being an example) that are implied to be the One True Right Way when in my experience most programming rules should not only be broken on occasion but frequently ignored wholesale.

"rather than thinking that there is this obvious 'metaphor' that naturally leads to well-organized programs."

Herein lies my greatest criticism of OO and it's proponents. There is nothing inherently "obvious" about the metaphor in general and in my opinion adding a layer metaphor on top of an already complex process simply adds further complexity without bringing anything to the table.

I found your comment much more provocative than the article itself :)

Object-Orientation exists in several different places, each of which is more or less important.

As a code organization tool, it really shines in large projects. So if you're learning to code, probably don't need it. Code organization gets much more rigorous in larger projects. Many times noobs with small programs start applying large-project concepts to their ten-line algorithm. This is a failure of teaching -- but probably intermediate-level teaching.

As a metaphor, it provides a way of looking at "where" to put your code. Noobs don't have a lot of code, so it doesn't matter. I agree that for small problems this extra layer can be distracting.

But the most important part of OO has nothing to do with programming: it's OOA. This skill lets you look at your problem, and it's the most powerful thing I've experienced for solving large problems. Functional Programming puts all the symbols and problem-space in your head at one time -- you become the linker. OOA lets you play with ways to solve a problem without writing any code and without taxing your noodle at all. You deal with small, atomic blocks and their relationships with each other. This skill is an absolute necessity, even if the student never touches an object the rest of their career. It's also one that's the most lacking in regular programmers.

    Functional Programming puts all the symbols 
    and problem-space in your head at one time

I feel like the natural response is "then you're doing it wrong", but I think that's too dismissive. My comments do not apply universally across so-called functional languages, but I think it holds as a point of note. That is, when thinking about a system functionally one tends to conceptualize the data in the system and how it gets from looking like one thing to looking like another. How it gets from point A to point B are matters of detail. So while I understand what you mean, I'm not sure that it's emblematic of how functional thinking is actually done. Functional thinking is less about functions than data.

Yes. I think we're saying the same thing.

By "link" I specifically meant data, not functions. Because everything is potentially visible, FP requires you to keep track of data structures in your head -- sometimes complex data structures with non-trivial relationships to other data structures.

Of course, there are methods to keep it simple -- starting small and growing as needed comes to mind first -- but if you're writing FP in a legacy environment with lots of nasty complex data structures you have a big headache. This would not be true in the same data environment with a well-constructed OO tier. [insert discussion here about what makes a well-constructed OO tier]

Or maybe I missed it. If I did, please straighten me out.

    but if you're writing FP in a legacy environment 
    with lots of nasty complex data structures you have 
    a big headache. This would not be true in the same 
    data environment with a well-constructed OO tier.

With fp languages the tendency is to think in data and abstract via functions. If your functional tier is well-constructed then all is good right? [insert discussion here about what makes a well-constructed functional tier] ;-)

Your comparing "nasty" fp with "well-structured" OO, but let's ignore that for the moment.

My experience is the opposite. I run into a lot of nasty legacy OO code (think java not smalltalk) and it's very hard for me to refactor it piecemeal. I've been doing a clojure project at work for the past 6 months and it's surprisingly easy to refactor side effect free code.

In modern Languages you have namespaces and namespaces let solve the problem your discribing.

Pretty much all recent functional languages deal with oo programming by using multimethods and namespaces. This takes care of the problem you're talking about in a beyer way than most oo languages.

I don't know that OO's main goal is to be readable, but rather to manage complexity (which should help readability, but I don't think that's the focus). There's an inherent level of complexity in OO that isn't necessary when you're solving basic, learner type problems, but it can help keep complexity down when you're solving problems that have solutions that can't be kept in your head at any one time.

To put it differently, think of an algorithm that's constant time, but has a very large constant and an algorithm that's O(n). The constant time algorithm will be worse for small sets, but better for large sets (once n > that constant). That's the problem with teaching OO to people new to programming. You're adding an additional thing to an already difficult topic, and that thing you're adding doesn't really benefit you at that level of problem, but get to a bigger problem, and it starts to make sense.

I agree, but it's good to step back and think why that's true.

The real value in OO programming is being able to reduce complexity by reusing code in a new ways. Either by creating several instances of the same object that all manage a complex internal state, or by inheriting from another object and extending functionality. I need to add a window, I already have lot's of windows, but this one is different because X works in OO. I need to build my first window starting from scratch and suddenly OO does not give you any leverage.

Which is why OO seems pointless for most being programmers, they can't deal with sufficiently complex problems to gain anything from OO programming. However, you don't need to understand object's to use them. It takes a while to understand why you can keep adding <<'s after cout, but most beginners quickly prefer it over sprintf.

Which is why OO seems pointless for most being programmers, they can't deal with sufficiently complex problems to gain anything from OO programming.

Beware, this is not biconditional. I'm sure you won't have to go very far to find programmers who deal with complex problems but who do not feel that they gain anything from solving them using OO.

And there is also the argument that OO as implemented in popular languages introduces its own complexity, such that it ends up being used to solve the problems it introduced in the first place.

Complexity comes in many flavors. One of those flavors is mutable state. Reducing that makes OOP better. You can have your meta meta, and still be sane in your reuse of existing code. Keep the object abstraction, just limit it's scope overall.

Many of the language and library developments of the last several years of Python have been in making the language better at expressing concepts and control flow in terms of functions which pass around simple data types, which tends to make code less object-y.

For example: context managers and decorators make it easier to change code behavior in a region of code or a function body; generators make it easier to iterate through collections of things in a declarative way, storing state without explicitly adding it to an object; named tuple objects help in creating simple data types without resorting to heavily customized objects.

Personally, I find in Python that objects are a good and fairly intuitive way to describe data structures or anything needing many similar copies with complex stored state but where each copy is performing some particular action: e.g. representing the users logged into a chat server.

If only they added anonymous code blocks.

If the purpose of OO is design and organization rather than a fundamental way to think about programs, then really we shouldn't say things like "Everything's an object."

If you are an ardent fan of OO, you might enjoy spending some time with modern functional programming in clojure. OO has become the common means by which we achieve encapsulation and polymorphism, but these features can be accomplished by other means which have a different (and to some, better) feel.

When we say "Everything is an object", the core sentiment is that "Variables behave similarly". It's jarring to use object.toString() sometimes and "" + 1 others. To (approximately) fix this in an "code belongs to objects" universe, you must make everything an object (and have lots of inherited interfaces). In a functional universe you can achieve a more satisfying fix by having multiple implementations of the same method. (str object) and (str 1) behave similarly without imposing interface requirements on the different types. To have large scale projects, this requires that the str function be implemented in different places and dispatch correctly, which is a sophisticated language feature that isn't available in all functional languages.

I have long been a fan of python and The Good Parts of JavaScript. They have their problems, but they have served me well thus far. But OO is actually fundamentally flawed, and you only need to look as far as the Java library situation to see how exponentially complex strongly typed and independently developed OO can get. Duck typed OO has tried to answer the call, but this still results in duplicate, inconsistent interfaces monkey patched at runtime to achieve a measure of sanity.

Clojure is really changing my opinion - you get great performance (compared to the majority of languages), optional static typing, and significantly less crufty code. Whether it will age well is of course unknown, but so far it beats the pants off of any other language I have used (including scheme and Common Lisp).

I believe you are wrong about optional static typing; type hints in clojure are purely an optimization and for clarifying dispatch:

   user=> (defn foo [^Integer i] (prn (type i)))
   #'user/foo
   user=> (foo 1)
   java.lang.Integer
   nil
   user=> (foo [1])
   clojure.lang.PersistentVector

right you don't get type-checking only type-hinting for performance.

In Common Lisp we have optional type declarations, and a common strategy for implementations (for SBCL, say) is to treat such declarations as assertions by default, leading to more safety, and for performance-sensitive parts of the code you can "(locally (declare (optimize speed (safety 0))))", which makes the type declarations act as performance optimizations for that part of the code.

In your last two paragraphs of your edit you seem to have sort of slipped in an assumption that our designs should be constrained to at least some extent by what we can teach new programmers in their first few weeks? OO can still be a helpful metaphor, while at the same time perhaps not being the very very first thing we should teach. For instance, perhaps we should not teach the solutions of OO until the student has gone far enough to encounter the problems it solves, to at least some minimal extent. (I include the question mark on purpose, I doubt this is exactly what you meant.)

As a bit of a sidebar, I'd also observe that the metaphor we ostensibly want to teach our newbies, about how objects are nouns and methods are verbs and it can model the physical world and lets go talk about class hierarchies involving animals and vehicles, has fallen out of favor in the more advanced OO circles anyhow, since it is, not to put too fine a point on it, a useless way to design real programs. This would also seem to suggest that perhaps OO isn't necessarily the best thing to go out of the gate with.

What prompted this wandering, incoherent mumble was wondering if "what we can teach new programmers" is somehow related to "what is readable by unskilled programmers new to our programs." If OO gets in the way of new programmers, I was wondering if it would get in the way of the mythical maintenance programmers trying to figure out what our programs do and how to modify them.

I don't really have a full conclusion, but if we grant that it is a useless metaphor, and just a tool for organizing programs, I wonder if it ought to be relegated to a corner of most languages rather than being put front and center.

I was wondering if it would get in the way of the mythical maintenance programmers trying to figure out what our programs do and how to modify them.

This seems to me to be the point at which your idea goes strange. Why assume that maintenance programmers are interchangeable monkey-cogs with minimal understanding of software development and design? Perhaps we'd have better software if we treated maintenance and ongoing development as tasks requiring just as much, if not more, talent and knowledge and skill and practice as green field development.

(I understand that soi disant architects might disagree, but I ignore architects who don't code.)

"Thinking further about this, I am not against the idea of design considerations that should be kept from the beginning programmer. But OO isn't really a design consideration, it's a metaphor."

I would think of OO as just another tool that we've created over the years to help make programs. It's a big tool, with a lot of history to it, and that people used to think was the ultimate all-in-one tool that you needed to use for everything (nowadays less people think that).

But it any case, when you teach someone something new, you can't give them too many tools at once.

So while I agree with a lot of the sentiments you expressed, I don't think that what you do or don't teach new programmers has that much bearing on what you should or shouldn't use. After all, in your first lesson you probably won't be using loops either.

OOP is not a metaphor.

OOP is about (subtype) polymorphism, or more precisely about functions with polymorphic behavior in regards to the (implicit) parameter. Everything else is there to support and make it easier to apply this concept.

Of course you don't need OOP for every problem, because you don't need polymorphism for every problem. And applied improperly, every type of polymorphism (whether it's ad-hoc with early or late binding, or parametric) is broken, not to mention hard to explain.

And as an exercise, I want you to count the number of applications where you haven't used any type of polymorphism. The only ones I can count myself are the small exercises of the types I used to do in high-school.

See what I did there?

OOP is about (subtype) polymorphism

What are we to make of this quote: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."--Alan Kay

Do we interpret that as suggesting that polymorphism is the thing and that Alan is using different words to describe it? That polymorphism is an implementation technique for achieving the goals Alan is describing? or perhaps that in the thirty years since Smalltalk has been commercialized, we have moved on from its initial vision?

"messaging" / "extreme late-binding of all things" - this is about polymorphism.

"local retention and protection" - encapsulation is THE goal of every engineer (i.e. black boxes that take some input and reliably give you some output, without you worrying about the details) and is in no way an exclusive property of OOP, although thinking about data-structures as objects that respond to messages gives you powerful tools to do that.

EDIT - and thinking about beginners that can't understand OOP, encapsulation is also hard to explain, but that doesn't make it any less of a useful goal.

"Messaging" also means loose coupled. It enables things like Structural interfaces (you implement what you implement) like in Go, instead of declarative interfaces (you implement what you say you implement) like in Java/C++/C#.

"Messaging" and its loose coupling also means the ability of doing Method Lookup Alteration and Interception [1], such as those provided by Smalltalk’s doesNotUnderstand, Ruby’s missing_method and Python’s __gettattr__ method. This is crucial because it allows you to compose objects, as they are strippable down to the Common Lisp Object System system: an object is a function that takes a message specification (method name and args) and decides what to do with it.

Yeah. Messaging is really important and powerful. It also explains why Alan Kay also said: I coined the term object-oriented, and C++ wasn't what I had in mind.

[1]http://www.google.com/url?sa=t&source=web&cd=2&v...

"Messaging" is polymorphism in action and a way to describe it to people without headaches by concentrating on benefits and use-cases, instead of implementation details.

And to be a little pedantic -- virtual method calls in Java/C#/C++ are also messages.

What Alan Kay meant was that a static type system doesn't blend with the OOP he enabled in Smalltalk. Do you know why?

Because in OOP polymorphism, method-dispatching is late-bound. And being late-bound it makes absolute sense for the developer to be able to override the method-dispatching that's being done (by means of method_missing and other mechanisms). But that's directly at odds with the purpose of a static type system.

And btw, structural typing is not dynamic typing. It has the same problem as the one described above.

Alan Kay also said: "I made up the term "object-oriented", and I can tell you I did not have C++ in mind."

Going by Kay's original definition, Java, C# and C++ do not qualify as object-orientated languages. I think we may have to accept that the original term has become somewhat diluted over time.

However I don't think OOP is all about polymorphism, because you can have polymorphism without objects (e.g. Clojure's protocols or Haskell's type classes).

I already mentioned other types of polymorphism.

But OOP isn't really a type of polymorphism, any more than a Ford Focus is a type of internal combustion engine. You claim that:

> OOP is about (subtype) polymorphism... Everything else is there to support and make it easier to apply this concept.

But if that were true, why does your typically OOP language handle polymorphism so poorly? If your only goal is subtype polymorphism, why not just have multimethods and type inheritance and be done with it? Why bother with encapsulation? Why only have single-dispatch?

I haven't said that OOP is a type of polymorphism, I only said that OOP has a type of polymorphism, that is its most important property and easy to overlook when talking about OOP.

I'm also not saying that you could throw away the rest - thinking in objects has value, having the ability to inherit implementation has value (in certain cases) and so on; so definitely the whole is bigger than the sum of the parts.

The comment I responded to said OOP is a metaphor ... but now you're saying it's like a Ford Focus with a certain type of combustion engine. That's exactly my point - it's easy to overlook what makes it tick.

And you asks questions to which you (probably) know the answer.

Multimethods are sweat, but a bitch to optimize and only useful in certain use-cases - that's why Clojure is backing away from them. Single-dispatch is what you need in 80% of the cases and it can be optimized aggressively ... notice the JVM where most method-calls end up not doing a vtable-lookup (not that you can have a vtable with multimethods).

C++ / Java handle OOP so poorly because these are languages with a static type system that can't blend in with OOP (where method dispatching is done at runtime). But that's what people asked for.

Clearly I misunderstood what you were saying. It sounds as if we agree on most things :)

> Multimethods are sweat, but a bitch to optimize and only useful in certain use-cases

I'm curious, why do you think multiple-dispatch is more difficult to optimize than single-dispatch?

the original term has become somewhat diluted over time

It's not the original term. OOP started with Simula 67 and then split into 2 branches: the Alan Kay brach and the Barbara Liskov branch.

Alan Kay coined OOP for his branch, but the name caught on. So now OOP can refer to any descendent of Simula 67. Even ones he didn't have in mind (C++ is on the Liskov branch).

The thing is: the branches aren't really compatible philosophically. That's a big reason for the amount of confusion that exists.

In Alan Kay land objects are sub-computers that receive messages from other sub-computers. In Barbara Liskov world objects are abstract data with operators and a hidden representation.

Alan Kay coined the term, so his definition was the first, and therefore the original.

But aside from your unusual interpretation of the word "original", I agree with everything you said.

A lot of the important concepts we'd consider "object-oriented" are implicit and will likely be picked up intuitively.

If you're writing python functions that return ADTs like dictionaries, sets, and lists, you're already using OO programming. Your function is a constructor, and you get back a collection of data with a set of methods that can operate on that data.

I wouldn't say that "non-OO is better" for a beginner, just that there isn't much advantage to a peculiar focus on object-orientation, especially as a program design philosophy.

OOP describes the real-world in the same way that the metaphor Raganwald is a diamond in the rough describes your ability to act as a piece of jewelry.