Chad Perrin: SOB

31 December 2007

thinking in FP or OOP syntax

Filed under: Geek — apotheon @ 03:00

Bear with me. I’m sure most of my readers know most, if not all, of the following explanation.

We (where “we” means “programmers”, “mathematicians”, and even “people who have been in third grade”) should all be familiar with infix syntax. That’s where you divide 10 by 2 with this syntax:

10 / 2

That’s common to many C-like programming languages such as Perl, Java, and C itself, when using arithmetic operators. It’s not so common to languages like Lisp, of course — and even in C-like languages, it tends to be limited to special (if common) cases, like arithmetic. C and Perl tend to use functional syntax for everything else — even when doing object-oriented things in Perl. In Lisp, it would look like this:

(divide 10 2)

That’s not how most languages employ functional syntax, of course. Most of them do something a bit more like the way functions tend to look in pure mathematics:

divide(10,2)

One might also call this prefix syntax. Of course, in C and Perl, division (an arithmetic operation) uses infix notation (what C and Perl use for arithmetic operations). Much of the rest of the language uses the above sort of syntax, however — and one could easily define a divide function like the above:

#/usr/bin/env perl

sub divide {
  ($dividend, $divisor) = @_;
  $dividend / $divisor;
}

divide(10,2);

There’s also postfix functional syntax, of course. Division with such a syntax might look something like this:

10 2 /

. . . but that’s not really relevant. It wasn’t until I started playing with Lisp-like languages (again) that I really grokked the value of a prefix/functional syntax for arithmetic. I began refamiliarizing myself with Logo, via UCBLogo — a Logo that supports macros at least somewhat like those of Lisp, and uses an M-expression functional syntax (that is, a syntax that doesn’t require the “fingernail clippings” of Common Lisp). In Logo, division looks like this:

quotient 10 2

One of the great things about prefix (and postfix) notation for arithmetic is that it makes all the problems of precedence common to grade school arithmetic and many programming languages irrelevant. Arithmetic operations are organized hierarchically rather than linearly, which means that multiple operation dependencies for a single operation can be handled without specific grouping characters and messy precedence rules.

There’s another syntactic form that interests me right now: object oriented syntax. It varies somewhat in its appearance depending on the implementation language, of course. In Ruby, it looks like this:

10./(2)

I got to thinking about all this when I saw someone post something on the ruby-talk mailing list that used a method invoked thusly:

divide(10,2)

What struck me about this is that, for the first time since re-encountering Logo and learning to love prefix arithmetic notation, that looked wrong to me. I actually found myself wanting to rewrite the method so that it worked like this:

10.divide(2)

The object oriented arithmetic notation has insinuated itself into my preferences somehow. It hasn’t truly supplanted prefix notation. For one thing, this object oriented syntax is an odd mix of prefix and postfix notational syntaxes. It provides many of the same benefits of either of them — but it is tailored more specifically to an object oriented programming style (obviously).

Rather than having an operator that operates on the arguments on either side of it, or an operator that operates on the following (or preceding) operators, it is instead an operator used by the object before it to operate on the argument following it. If you don’t understand how that’s beneficial, it probably means you haven’t really grokked object oriented programming fully.

I understood all that for years, but it’s only now that it has come to feel as familiar and natural to me as prefix notation for arithmetic operations. I guess one could say I’m thinking in OOP syntax just as easily as in functional programming syntax.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License