Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re^3: I dislike object-oriented programming in general

by stvn (Monsignor)
on Oct 18, 2007 at 19:25 UTC ( #645829=note: print w/replies, xml ) Need Help??

in reply to Re^2: I dislike object-oriented programming in general
in thread I dislike object-oriented programming in general

I deliberately tried to steer away from any particular programming language, but if you received the expression that I'm talking about those three, my apologies.

Well, it just seemed to me (and I may have read in between the lines too heavily and I apologize in advance if that is so), that much of what you were talking about were problems with particular OO implementations and the more idiomatic usage of said OO implementations. For instance, in CLOS programming it is not uncommon to have many plain vanilla functions (and macros) along with the classes and generic functions. The same can be said of much Javascript and C++ programming as well. It is only languages like Java which do not allow vanilla functions/subroutines to exist that the "pure OO" approach tends to win out (mostly because there is no other choice).

The point was not to compare programming languages, but to explain why the means of abstraction and combination in pure object-oriented thinking do not appeal to me in general.

Well, I think it is very hard to discuss abstract OO thought without at some point coming back down to the language level. Every OO system has it's own set of rules and therefore has its own set of limitations, and some systems contradict or are in direct conflict with one another. A "pure OO" system which is not tied to any language would need to be defined before it can be discussed. As for discussing the merits of the parts of OO like abstraction, polymorphism, encapsulation, modularization, etc etc etc, that discussion too will eventually need to come back down to a particular implementation for all the same reasons.

My point is basically that there is not such things as "pure object oriented thinking" which is 100% language agnostic.

My "functions are modules" argument doesn't mean first class functions or doesn't even presuppose functional programming.

I am a little confused by what you mean when you say "functions as modules", this makes me think of the Standard ML module system and functors in particular. A function being a function which takes a module as an argument and returns a new module. Is this what you are refering too? If not then I am totally confused by your use of the word "module". Please expand.

If I am worried about pervasive OO thinking in Perl 6, it's because frequently I don't want to think in terms of objects.

This is exactly my point, you wont have to think it objects if you dont want too. This is a stated design goal of Perl 6.

The concept of roles resembles Objective-C protocols, though with being able to define not only which functions the implementing class needs to provide but also some common functions that all classes implementing the role "inherit".

No, that is totally wrong actually. Obj-C protocols are pretty much the same as Java interfaces, and therefore are about as use{ful,less}. Roles (optionally) provide an implementation as well as just abstract interfaces. This makes them more akin to mix-ins or multiple inheritance. However, unlike mixins or MI, roles are actually composed into the class (in perl we do this with symbol table operations to copy from the role package into the class the role is being composed into) which means there is no inheritance relationship between the role and the class. There is also a strict set of rules by which roles are composed into classes, which makes for highly predictable behavior, whereas MI and mixins are much more difficult to predict behavior-wise.

However, this would again be a much more useful technique to think about if there was no mandatory link to objects and classes!

Well actually, they don't have to be linked to objects and classes at all. Roles are very similar the OCaml/SML module systems in that they can be used to compose a non-OO module just as easily as they can be used to compose classes. In fact, I have one specific usage of roles which uses pure roles as "function groups" which can be composed together (following the rules of role compositition) and are then used as "function groups" and never actually composed into classes/objects.

I'll install Moose::Role some rainy day, I promise.

You won't like it because it comes with the entire Moose object system. And that is deep down OO to the core, complete with metaclasses and all that fun OO-over-abstraction you seem to really dislike. In fact it is a meta-circular object system so it is actually OO that is implemented in OO. Which I am sure just makes you cringe :)

So, in conclusion, I think you have many good points, but your anti-OO stance seems to me to be somewhat reactionary to the pro-OO zealots. All good programmers know that silver bullets don't exist and in the end you just need good tools to get the job done. Those tools may be OO-based, they may be full of FP madness, or they may be a crusty CPAN module from the mid-90s like FindBin that sucks horribly but (for the most part) works when you need it to so you just use it and move on with your life. The moment you exclude any of those tools on some philisophical, moral or religious basis, you are really just adding more work for yourself.

  • Comment on Re^3: I dislike object-oriented programming in general

Replies are listed 'Best First'.
Re^4: I dislike object-oriented programming in general
by vrk (Chaplain) on Oct 23, 2007 at 17:31 UTC

    I am a little confused by what you mean when you say "functions as modules", this makes me think of the Standard ML module system and functors in particular. A function being a function which takes a module as an argument and returns a new module. Is this what you are refering too? If not then I am totally confused by your use of the word "module". Please expand.

    This is one part where I think it is essential to take a step back and forget everything you know about any programming languages you have learned.

    The problem here is that both module and function are highly overloaded concepts. Sometimes modules are building blocks as in other engineering disciplines, sometimes they are an abstraction mechanism, sometimes they are a particular way in your programming language to encapsulate functionality, ... Similarly functions could be procedures, methods, subroutines, lambda expressions, or mathematical functions (which could be mappings or relations), or what have you. Let's forget all about that, too.

    Actually, let's give a new name for the concept.

    Let gob have the following meaning: Any particular functionally sensible piece of program text that has a well-defined interface through which it can be used and with which it can be connected to other gobs.

    Given this meaning, a computer program is a gob: it accepts some input and produces some output. (If you want, the input and output can be partially or completely the global state of the machine.) A computer program can be connected to other gobs through its input and output.

    A class in object-oriented programming is a gob: the well-defined interface is the public methods, and these are used when connecting the class to other classes (gobs).

    A module in, say, Perl, is a gob: whether it is object-oriented, functional, or a collection of procedures, it has some interface through which it can be used. The interface can again be used to connect it to other gobs.

    A function/routine/subroutine/procedure is a gob: the interface to a function is the parameters it accepts (the input) and the return values (the output). (If you want, it may also partially affect the (global) state of the machine, i.e. work through side-effects.) The interface can, again, be used to connect this gob to other gobs.

    This is what I mean. At a very high level, all current programming paradigms let you create gobs and pass gobs as parameters to other gobs. How gobs are implemented in your particular programming language is not relevant; the concept is! Gob is the quintessential Lego block of programming, if you want.

    Suppose you have that small statistical analysis framework. One gob abstracts the control: it takes in data in some form, processes the data chunk by chunk by giving it to another gob (supplied by user), which returns a value, and the value is given to a third gob (supplied by user) along with the ID number of the data chunk. The user provides such a pair of gobs that they work well together (the latter understands the output format of the former), and the framework is completely agnostic to what kind of data these two gobs pass around; it just connects the gobs together and provides them with small pieces of data.

    How you might implement this could be with three classes: one for control, another for data analysis, and a third for data collection or plotting.

    Or you could implement the control as a function that takes two closures as parameters.

    Or you could implement the control as a function that takes two objects as parameters.


    In a word, this is what I mean with gob.

    (As an aside, gob is an actual word.)

    print "Just Another Perl Adept\n";

      Yes, all this theory is very nice, clean and organized, but it doesn't help me at all when I need to get a job done.

      This is one part where I think it is essential to take a step back and forget everything you know about any programming languages you have learned.

      Again, I disagree. First of all, you are talking about concepts very heavily tied to programming languages (in fact, all your expansions on the "gob" definition come back to programming languages). But really what you call a "gob" is nothing new or fantastical, but simply the product of "moduler decomposition". Modular decomposition is not specific to computer science of course, or even engineering. Many artistic disciplines use the technique, like music and painting.

      And lastly, you have not really given a useful alternative to OO. You say you don't like it, but you have not shown a superior tool. Sure, we all hate zealots, but that is no reason to abandon OO and the 30+ years of research and usage in which it has grown and developed as a paradigm. But hey, if you want to go back to the 70s/early 80s and program in CLU or Pascal, be my guest.


        it doesn't help me at all when I need to get a job done.

        It helps me think. The root node title says I dislike, and the author was vrk, not stvn (you can compare that with your favourite programming language, if you like). I only argued why object-oriented programming fails to warm my heart, and to my knowledge there was no direct promise of enlightenment after reading my ramblings.

        I don't claim to have discovered anything new here. I used the word gob since you were confused with my use of module; but apparently modular decomposition is okay, so I'll use that.

        I find it very helpful to keep in mind that despite the programming language, you are always dealing with the same basic things, which boil down to separation of concerns and modular decomposition. If I were stuck with only one or two particular techniques in modular decomposition, and the programming language I used lacked those, I would be stuck. Clearly you are more clever than I am and this doesn't concern you, but for us less advanced in the audience, I'll explain.

        For example, recently I've had to program in PHP. PHP 4 and 5 have classes and objects (less refined in the former than in the latter), and they support a rudimentary callback mechanism by giving function names as parameters (through "variable variables"; in Perl: reference to a scalar). They also have eval, but I try to keep away from that beast. So, my options in modular decomposition are limited: I can make some procedures or I can make some objects, and that's about it.

        If I only knew, say, (pure) functional programming through Scheme, I would be in trouble: no support for the particular mechanisms of modular decomposition that I know. Oh! But what I do when I pass closures around is roughly the same as passing objects! Problem solved: I'll explicitly define classes and then instantiate objects.

        Programming in Scheme would be equally confusing if you only knew object-oriented programming. Oh, what am I saying, of course not: it's the same modular decomposition process again, only with different concepts. In multiparadigmatic languages I even have a choice, when decomposing the problem into gobs modules parts, which particular mechanism to use based on the structure of the problem.

        I'm not saying that by knowing what modular decomposition is you would miraculously know any programming paradigm there is. (You'll no doubt read it that way.) The point of all this waste of time is to say that I don't like the particular mechanism of modular decomposition offered by (pure) object-oriented programming, regardless of how the particular implementation of object-oriented programming works (and by implementation, I don't mean how the programming language is implemented, but it seems to be useless to make distinctions).

        And lastly, you have not really given a useful alternative to OO.

        Right, I suppose I should have written four or five of these meditations to enforce equality between paradigms.

        But since you asked nicely, I recommend pure functional programming with monads to encapsulate the particular cases where you need explicit state and sequential execution. Haskell is one where this happens. You can read more propaganda from their wiki.

        print "Just Another Perl Adept\n";

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://645829]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (7)
As of 2018-01-20 21:44 GMT
Find Nodes?
    Voting Booth?
    How did you see in the new year?

    Results (227 votes). Check out past polls.