Don't distract new programmers with OOP

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.

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.

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 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).

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 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 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?

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.

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.

It is nonsense.

On IRC the other day, I said this:

    19:19 < xentrac> I propose a new rule for discussions of object-oriented 
                     programming
    19:20 < xentrac> which is that anyone who brings up examples of Dog, Bike, Car, 
                     Person, or other real-world objects, unless they are talking 
                     about writing a clone of The Sims or something,

    19:20 < xentrac> is immediately shot.

If I were teaching, I wouldn't start new programmers with OOP, but I would bring them there quickly. Imagine an assignment where you have the students model a car, a stop sign, and a traffic light, and their interactions on a closed course. I'd have the students model the interactions using ruby hashes (e.g. car = {:color => 'blue', :state => 'stopped', :stop_time_required => 1}, traffic_light = {:color => 'red', :stop_time_required => 30}), and a series of functions for the first assignment, where the program prints what happens as it encounters a pre-defined course. This should result in some pretty crappy spaghetti code. For the next assignment, I'd have them clean up the structure of the program, separating the code into logical units based on what the code is operating on, a car, a red light, a stop sign. Lastly, I'd introduce OOP and have them update the code for OOP. It should take a lot less code to do the same thing, and it should be a lot cleaner. Polymorphism can be addressed by instructing the students that red light and stop sign are both traffic control devices, and having them implement to_s on each class to clean up their string handling code.

OOP can make lots of sense when it's presented as a time saving measure. However, especially in Java classes, it tends to start will a wall of code thirty lines long to print "Hello World", with the direction to ignore everything else. It would probably be better to start simple, with a 1 line program (e.g. puts 'Hello World'), and work up from there. That's not to say Ruby is the right language, it's probably a good starter language, but a strictly typed lower level language would probably be better once they get the hang of things. The beauty of ruby is that you can create useful code quickly, but you still need to be able to understand what's going on under the hood.

The two classes I learned the most from were a digital hardware class, and a assembly course. In the hardware course, the professor gave me a FPGA to work with after he saw I understood digital logic very well, and on that FPGA I implemented a basic instruction set, including jump, which could be entered using toggle switches, executed using a push button, with results output to a lcd. In the assembly course, the professor spent a great deal of effort manually compiling c to assembly, and explaining why. He was on the ANSI-C committee, and worked full time writing assembly for spacecraft at NASA, so offered a very unique prospective, and quite a bit of insight.

A number of years ago I wrote http://www.perlmonks.org/index.pl?node_id=318257. You may find that it solves the problem in a reasonable mount of detail.

Well, not language. Library. It's abstracted to the extreme, and confusing as heck to anyone just starting to learn how to think about how to program.

Start people out in something simple. Ruby can teach bad habits, so don't tell them about monkey patching, but it's so simple it's a great way to hook people, and has simple console / file IO that'll let newbies actually do something with their skills, instead of being glad their project doesn't overflow its array bounds or get stuck in hideous C input handling deathtraps (which flags do you have to reset in the input stream if they start inputting Japanese? I forget...)

Best of all, despite being OO, you don't need a class to start doing things. Something Java gets wrong for beginners.

  #!/usr/bin/env ruby
  puts "hello world"

But note that, in everyday life, relationships exist mostly between objects that would have been instances of unrelated classes in OOP. For example, my SCREEN IS ON TOP of the TABLE; I (a human being) AM SITTING on a CHAIR; a CAR IS ON the ROAD; I am TYPING on THE KEYBOARD; the COFFEE MACHINE BOILS WATER.

We think in terms of bivalent (sometimes trivalent, as, for example in, "I gave you flowers") verbs where the verb is the action (relation) that operates on two objects to produce some result/action. Contrast that with OOP where you first have to find one object and tell it to perform some action on another object. The way of thinking is shifted from actions/verbs operating on nouns to nouns operating on nouns, which is highly unnatural for me. It is as if everything is being said in passive voice, e.g., "the keyboard is being typed on by me".

You have to think about your own problems in the context of your customer's needs. You are you, your customer is your customer. Each to its own.

"But, but, len is a function! And you can't monkeypatch the base classes even though you can monkeypatch everything else!"

Yes, please, by all means burden your neophyte with that tirade. They'll really appreciate it while they're trying to figure out what an "if" statement really does or why calling a function with the wrong capitalization doesn't work.

The Objects loss this proberty because they have inheritance. The other problem is that every in OO the data is mixed with the functions.

Rich Hicky on how it can be done right: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

I can't remember where he wrote about it, but apparently, 1) students can use other people's objects just fine, if they are simple (and so from that perspective, OO is fulfilling its general promise), but 2) new students have a nightmarish time trying to both solve new problems AND decompose problems into objects at the same time.

Which is to say, there is absolutely a reason not to introduce this to beginners. It makes them fail and quit.

Incidentally, the same argument could be made for the concepts of abstraction involved with composing new functions - new students can call existing functions just fine, but the skills involved with abstracting a problem, and replacing a pile of copy/paste with a parameterized solution, is apparently a more taxing set of skills than you might think.

Everything in it's right place.