Why OO may not suck, or, Take a ride on the Falsus Omnibus

re: Why OO may not suck, or, Take a ride on the Falsus Omnibus

Keith Braithwaite — Wed, 11 Feb 2009 12:43:30 GMT

The thing that i find most strange about Armstrong's opinions regarding object-orientation is that Erlang is an excellent vehicle for OO programming and what I've seen of Erlang systems with a non-trivial number of processes they are exactly object-oriented in construction.

re: Why OO may not suck, or, Take a ride on the Falsus Omnibus

Panzergrenadier — Wed, 11 Feb 2009 14:20:09 GMT

Object oriented programming is an MBA style bullshit turned into programming "paradigm". To become really useful programmers, people should learn algorithms, instead they just spent time babbling about "design", "layers" and "patterns" on meetings.

re: Why OO may not suck, or, Take a ride on the Falsus Omnibus

David MCLaughlin — Wed, 11 Feb 2009 14:52:24 GMT

@ Panzergrenadier

The reason "design", "layers" and "patterns" are discussed so much is because the amount of time spent maintaining awful code is a serious issue in nearly every corporate environment.

If you approach performance optimisation as "hit the largest bottleneck first" then the amount of nanoseconds wasted in a sub-optimum algorithm always pales in significance compared to the amoune of weeks spent trying to work with a poorly designed system.

Why OO may not suck, or, Take a ride on the Falsus Omnibus

Aggregator @ Bitubique — Wed, 11 Feb 2009 15:12:50 GMT

submitted by gst to programming [link] [3 comments]

re: Why OO may not suck, or, Take a ride on the Falsus Omnibus

matt — Wed, 11 Feb 2009 15:59:34 GMT

@Panzergrenadier:

"To become really useful programmers, people should learn algorithms, instead they just spent time babbling about "design", "layers" and "patterns" on meetings."

Um...you realize that algorithms are just answers to patterns right? Same with data structures. "Patterns" just take that and start to apply them at a higher level.

When you realize you need to search something...or map something...or sort something....you've hit a pattern.

re: Why OO may not suck, or, Take a ride on the Falsus Omnibus

Steve Goguen — Wed, 11 Feb 2009 16:30:11 GMT

It seems like the biggest problem when talking about OO, is that you are ultimately talking about data types and functions and how to relate them conceptually in a useful way.

When you really distill what a basic object is, you end up really talking about a data type and a set of functions that operate on that data type. I know the traditional definition of OO requires that it be based on encapsulation, inheritance, and polymorphism, but I take issue with that. The only thing I believe is required for an OO system is some mechanism for implementing some type of polymorphic interface. If you really think about it, encapsulation and inheritance are really just compiler features to assist in creating a polymorphic interface.

The point is: When it comes down to it, you can implement all of these object-oriented features and concepts in a non-OO language like C. Sure, the syntax might not reflect what you're doing conceptually, but you do have the power to implement these features yourself. But why? Why would you want to implement these features yourself?

What Joe did with Erlang is reduce his language down to what he thought was the most essential features. Rather than concocting a complex type system that imposes rules like, "all polymorphism must be done through interfaces" and "no multiple inheritance allowed", he implemented a much more flexible system that focuses more on the polymorphism side of objects using pattern matching system. With pattern matching, I can define 5 different behaviors for the same function on the same data type, where as I'm limited to 1 function with a bunch of if statements with an OO interface.

Let's say I had a list that contains strings, integer, and a few different types of records and I wanted to format each type a specific way, depending on its data type. With a traditional OO language like Java or C++, implemented polymorphic functions is restricted to class types, and you can't extend primitive types because they are usually sealed. With Erlang, I simply define 4-5 different implementations of the function or each data type and then call that function for each item in the list. Hell, I can define a default function that matches objects that weren't specified. There are a lot of times I wish traditional OO language allowed me to do that.

Now, dynamic languages like Ruby and JavaScript allow you to add class specific methods at runtime (a process aptly named "monkey-patching"), but that's riddled with problems as it creates naming collisions, which becomes a REAL problem if you're the kind of person who believes in reusing components. (Ask any JavaScript or ROR programmer if about these types of name collections.)

I'm not saying that OO is entirely bad, nor am I saying that Erlang is God's gift and Joe Armstrong is his prophet. I've been doing OO for 15 years now, and I think that objects are a good abstraction for a lot of things. However, I think the way we think about objects and what they are need to be challenged. There are a lot of artificial restrictions, for many languages, that end up holding us back or forcing us to shoehorn a good design into an overly restrictive type system. On the other hand, there are also too many liberties that allow too many programmers to shoot themselves in the foot.

All in all, I agree with your thesis that not all OO systems suck, but I do believe that a majority of them do, which is why I think we should let the OO bashing begin. I personally can't think of a better and more effective way of evolving OO than vigorously challenge its core principles. It forces people to consider the weak points in OO and separate them from the strong points.

re: Why OO may not suck, or, Take a ride on the Falsus Omnibus

frederiksen — Wed, 11 Feb 2009 16:42:53 GMT

I agree with Joe's point about state. Sure, in so many situations state is crucial. In hardware, finite state machines are a must. But having every single object keep its own state? The amount of permutations of objects and states is damn near infinite and impossible to test.

Patterns seem to me to be another level of (unneeded) abstraction in problem solving. It confuses the issue and doesn't add anything. Maybe languages like Smalltalk do OO better, but my years with C++ and Java make me think OO is trying to fit a round peg into a square hole.

I think OO should just be another tool of a language. There are some situations where it is very elegant. But trying to do absolutely everything with objects requires some pretty serious hammering on the problem to make it fit in OO-space.

re: Why OO may not suck, or, Take a ride on the Falsus Omnibus

Jacob — Wed, 11 Feb 2009 16:48:42 GMT

Well, the most obvious argument for OOP (imo) is kind of ignored here. Let's say you're using C.

All strings are represented in a consistent manner. In this case it would be a character array ending with a null terminator.

All functions in string.h act on data represented in the manner in which all strings are described. These functions aren't useful when applied to data organized in a different manner.

Most of the functions in string.h begin with the three-letter prefix str, which seems to me like a shout to replace that prefix in a manner that's more compact, readable, and direct.

In addition, private data allows certain functionality to be done more efficiently. Unfortunately, abstraction can lead to patterns going unnoticed, but I don't believe this to be a major issue.

re: Why OO may not suck, or, Take a ride on the Falsus Omnibus

Luke Plant — Wed, 11 Feb 2009 17:11:05 GMT

You asked for a "compelling reason as to why it is wrong to couple transformations with the data structure that they are able to be applied to".

The need for multiple dispatch often provides such a reason. Just look at the implementation of a .Equals() method or .Compare() (or __eq__() etc.), then compare to how something like Haskell does it (using typeclasses, or sometimes using pattern matching). You immediately see that a .Equals() method is an unnatural and wrong thing to do, but you don't see that until you realise the alternative.

Generalising, solutions in OO languages often end up biased to the tool that you have (single dispatch), which seem OK at the time, but stepping back you realise that it isn't actually very nice.

re: Why OO may not suck, or, Take a ride on the Falsus Omnibus

Matt — Wed, 11 Feb 2009 22:47:23 GMT

Discussions on OO are often fruitless because everybody supplies their own definition of what it means. I'm curious what definition of OO the author has in mind. Something like:

http://www.paulgraham.com/reesoo.html

Otherwise, the term "Object Oriented" that we're discussing might not even mean anything at all:

http://apocalisp.wordpress.com/2008/12/04/no-such-thing/

Matt