Wrapping a function in a burkha

Terrific quote from Jessica Kerr via Dan North:

In an OO language you can't just pass a function around unless it's dressed in a burkha and accompanied by nouns @jessitron at #scandev

If you feel like you’re missing an inside joke, here’s an explanation.

In object oriented languages, languages that don’t simply support object oriented programming but try to enforce their vision of it, you can’t pass around a simple function. You have to pass around an object that contains the function.

Functions are analogous to verbs and objects are analogous to nouns. In contrast to spoken English where the trend is to turn nouns into verbs, OOP wraps verbs up as nouns.

“Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function.” — John Carmack

Related posts:

You wanted a banana but you got a gorilla holding the banana
Software to slice bread

8 thoughts on “Wrapping a function in a burkha

  1. In Perl6 the function itself is an object.

    sub foo($a){...};
    &foo.WHAT.say;
    # (Sub)
    &foo.perl.say;
    # sub foo($a) { ... }
    &foo.assuming(:a(5)).WHAT.say;
    # (Sub)

    Even keywords are functions, which are a type of object.

    our &bar = &say.assuming(5);
    bar;
    # 5

    Did I mention that functions are really just a type of object with the Callable role.

    say &foo.does(Callable);
    # True

    Then again even low level types can be seen as limited objects.

    my int $a;
    $a.WHAT.say;
    # (Int)

    If you need it to actually be an object, just upper case the first letter.

    my Int $b = 0 but True;
    say $b;
    # 0
    say ?$b;
    # True
    $a = $b;
    say ?$a;
    # False

  2. It makes sense to implement functions that way under the hood, but I don’t want to have to think about it. And of course most Perl users don’t have to think about it.

    Creating function objects was one of my biggest annoyances with C++. Now things have gotten much better since the language added anonymous functions.

  3. I’m offended by this tweet. It carries the tacit implication that dressing women in burkhas and requiring them to be escorted is unnecessary and/or undesirable, which is dismissive of my cultural heritage.

  4. Eric: Or maybe it affirms your cultural heritage and implies that functional programming is immodest. :)

  5. Eric: It’s unnecessary in the sense that nobody has to. Dressing in a burqa is unnecessary in the same way that dressing in pants is unnecessary, or caffeine is unnecessary, or sport is unnecessary. Sometimes it’s undesirable; I can imagine that a construction worker may find a burqa getting in the way of their job. Sometimes it’s a distinct advantage. Sometimes it’s completely neutral.

    I may be reading too much into the tweet, but the wording “you can’t [...] unless” doesn’t imply that it’s always undesirable.

    One of the strengths of multi-paradigm programming languages (and all the best ones are) is that you have options. There are good reasons to pass around an abstract factory or a listener object, but there are also good reasons to pass in a bare function to do the same thing. Which one is best depends on the job you have to do.

    As software engineers, part of the reason they pay us the big bucks is to find the best solution to a problem. Limiting the tools in your toolbox is bad. So is unnecessarily proliferating them.

  6. English turns verbs into nouns all the time through gerunds (e.g., John’s writing) and deverbal nominalizations (e.g., the destruction of Rome).

    In C++, a class implementing an operator without any data is a pure function. You were just objecting to the syntax, which is a kind of nominalization. The other way to nominalize in C/C++ is with a pointer to a defined function (like the demonstrative pronoun “that” in English). You can then think of lambdas as being like wh relative pronons in English.

  7. Dan should know better than this. In fact, I think he does and is just being provocative: I am duly provoked.

    In OO languages that actually take objects seriously there is no semantic nor cognitive overhead to creating, passing around, and using an object that represents a function. In Smalltalk and its relatives, for example, a block object has a literal representation which is as clean as a lambda expression in almost any functional language and can be passed around and applied in exactly the same ways. The programmer never has to interact with a block as an object qua object unless they want to.

Comments are closed.