developer.* Blogs - Functional Programming vs. OO - Comments

The right tool...

WaterBreath — Thu, 24 Aug 2006 19:25:11 -0700

My primary point was, as I noted, that it's not enough just to verify "yup my language can do that". The question is, will you use it? Is it more efficient than the method you already knew? If it isn't, you're not likely to use it. And not likely to consider that it might be easier than what you're already comfortable with, if you try a different language. Sometimes doing the same job in a different way in the same language is worse, but doing it that way in a different language is just plain better.

"...Right tool for the job..."

Everyone knows some languages are good at some things and others are good at others. But we'll never know what exactly those things are unless we shop around. It's not enough to be "sure that functional programming has its uses and its merits". I'd encourage you to take up the goal I did recently: find out what those uses and merits are!

Joel's argument (and Paul Graham, and Steve Yegge, and... ) is that not only will you find new tools you never had before, but you'll find that you can think about solutions in ways you never did before. And that will help you even if you stick with the old stand-by language. (If it's expressive enough. Doesn't matter how much you know about generics and dynamic typing, it won't make your PL/SQL more concise or elegant. Bleh.)

Dynamism . . .

Rob MacGrogan — Thu, 24 Aug 2006 14:21:12 -0700

. . . is I think the word WaterBreath is looking for above.

I'm not sure I understand David Koontz's point that:

In your example to program in a functional style you'd have to go around scattering map methods in each class or have your own base class from which everything else inherits.

That's not true at all. You could implement something like this any number of ways in Java, such as in a static method, or in a class that other methods instantiate and call methods on, or as some sort of remote service.

Developers tend to get into my-language-is-better-than-yours pissing contests (again, I see Calvin peeing on various corporate logos -- see this comment I made in another post), and I don't want play that game if at all possible (and I'm not accusing either WB or DK of doing so either). I'm sure that functional programming has its uses and its merits. My only point was that the particular problem Joel presented was certainly solveable in Java. I remain convinced that it is.

I had occasion recently to re-visit a post of mine from last year in which I dug into the different mindsets developers get into when they think linearly (solving problems through iteration in code) and when they think in sets (which is how SQL operates). This discussion actually reminds me quite a bit the points I raised (and the larger point I think Joel was trying to make) that the development language you use affects how you think about solving problems, and that sometimes it can box you in.

A more poingant example of first class functions

David Koontz — Thu, 24 Aug 2006 12:56:31 -0700

While it is certainly true that you can implement map as a method in the class, that is missing the point. In a language with "free-floating functions" (which the rest of us simply call functions since everything in Java is a *method*), you can implement map once for ANY combination of list + function. In your example to program in a functional style you'd have to go around scattering map methods in each class or have your own base class from which everything else inherits. Not particularly DRY. Also, because of the type system you're either going to have to do some generics tricks or implement a ton of different map's to cover all the different combinations of methods and lists to iterate over.

Perhaps an example is in order, this comes from Ruby which perhaps will be more to your syntactical tastes:

list = [1,2,3,4,5,6] #array of numbers
list.each {|i| puts i if i%2 == 0} #print out even nums
list.each {|i| puts i if i>4} #56

and then since you've got the really most basic stuff like each going you can take this idea of passing in anonymous functions (called lambdas) and do all sorts of fun things

list.reject {|i| i > 4} #[1,2,3]
list.partition {|i| i%2 == 0} #returns 2 lists [2,4,6], [1,3,5]
list.inject {|sum, i| sum += i} #21

These methods and several others are available for any collection in any class in any file anywhere. This is all without losing the namespaces that classes give you. The point is, you can do C++ in C with function pointers, the fact that's it's possible doens't mean C is a good language for object oriented programming. The same applies here to Java and functional programming, the language just doesn't support the needed functionality to make it useful. As the previous commenter stated, C# 3.0 (while I detest MS and have never used C# professionally) is adding things like anonymous functions (lambdas) so you will be able to pull off *some* of these tricks there.

Dynamicity (is that a word?)

WaterBreath — Thu, 10 Aug 2006 12:30:10 -0700

>What the OO solution to this problem gives you, though, is some nice name-spacing...

C++ has namespace structures that are totally untethered from classes. Anything you can declare in the global namespace, or in a class, or in a function, can be declared within a named namespace that you yourself create in code.

>...the potential for type safety in your map method...

The argument of proponents of functional and dynamically-typed languages is precisely that things like type safety, when applied universally, are limiting. Generics and interface mechanisms were created specifically to get around these limitations. They were added to Java and C++ to support behavior that are very natural in functional and dynamically typed languages. That naturalness is key to the debate.

>...a potentially much more readable batch of code

This is quite subjective. And it's one example of how learning dynamic languages can change how you think about programming. I would argue that implementing in an OO language (esp. Java) these things that are inherently natural in functional and dynamic languages, is cumbersome, verbose, and rigid. Functional and dynamic languages drive toward a goal of expressing this behavior with utmost concision and elegance.

>there's no reason this can't be done in an OO language as easily as in a functional language

The concision and elegance mentioned above naturally contribute to ease as well. I understand the OO-minded view that functional and dynamically-typed languages encourage messy or disorganized code structure. But I would contend that this is because people who have settled into OO and resided there for too long begin to see OO-style structure as a requirement for organization, when that's simply not true. Think about it a little, and I think you'll see that this type of view is a bit closed-minded and a real barrier to advancement in any scientific or engineering pursuit.

There have been multiple responses to Joel's post that in effect answer his question in the affirmative. But I think Joel made a mistake when he asked that question. In particular, I think he should have asked it differently, because I don't think he meant to ask whether the general behavior was possible. Rather, I think his point was to ask how natural and elegant its expression is in language X.

My answer to that question, in the context of Java, C++, and C#, is: not very. (Though the planned feature additiosn I've seen for C# 3.0 look very promising. I think C# and its continued evolution is one of Microsoft's crowning achievements of recent years.)

Functional Programming vs. OO

Rob MacGrogan — Wed, 09 Aug 2006 16:58:34 -0700

What the OO solution to this problem gives you, though, is some nice name-spacing, the potential for type safety in your map method and a potentially much more readable batch of code. What's the major issue with this?