Summary
Functional programming languages are enjoying a renaissance. Even if not intending to use a functional language for daily work, learning such a language can improve one's programming style.
Advertisement
In his lunchtime keynote address at the 2008 ServerSide Java Symposium, Ted Neward spoke about a programming language renaissance. Neward pointed out that there is renewed relevance for many languages today, in part because some languages are especially good at expressing ideas that have become more important in recent years. With the two major runtimes—.NET and the JVM—supporting an increasing variety of languages, many developers can benefit from programming ideas that dominant languages of the past decade did not express.
One such idea is the notion of considering functions as first-class objects, or higher-order functions. An idea that originated in the 1960s, functional programming is now supported by mature, widely-used languages. Indeed, one such language—JavaScript—may just be among the most prevalent, considering the myriad of Web pages executing some form of JavaScript. Microsoft's latest incarnation of C# supports functional programming features, and the company's new F# language aims to fuse functional and object-oriented styles. On the JVM, Scala allows functional and object-oriented programming features to interweave in elegant and practical ways. And popular dynamic languages support functional programming elements as well, such as lambdas and closures.
A fundamental change is under way in how we develop software. Declarative, Functional, Model-driven, Aspect-oriented and Logic Programming are all examples where new ways of representing and solving problems can pay huge dividends in programmer productivity and system maintainability. Suddenly, it no longer seems that functional programming is a means to try out obscure new forms of lambda calculus. Now it seems that there are fast, powerful, easy to understand techniques to be learnt that will make my systems more robust and smaller...
Functional programming had always seemed like a distant offshoot of some Bourbakist school of mathematical programming unconcerned with practical issues of software development... Functional programming was suffering from bad PR. But times change...
Matthews answers the question in his blog post's title with a resounding "yes," and goes on to provide a brief introduction to functional programming concepts using C# 3.0.
My recent foray into functional programming came not from the desire to think of programs as mathematical functions—among the more brilliant ideas of the past century—but from the mundane need to write some JavaScript for the client-side of a Web application.
Functional and OO
Douglas Crockford, inventor of JSON, has pointed out that JavaScript lacks any meaningful way to structure larger programs—any, that is, that would appear familiar to Java developers, for example. JavaScript does not have classes, and relies instead on object prototypes for its OO features. Such prototypes, in turn, depend on the capability of having functions as first-class elements in the language. Crockford notes in his lectures that it is difficult to master JavaScript without grasping the language's functional design philosophy.
Yahoo's YUI library—the tool I was working with at the time—provides an excellent tutorial on structuring larger programs as a set of interrelated functions. While the techniques espoused in the YUI API do take some getting used to, they can result in highly reliable and clear code structure. One reason for that is the lack of reliance on global state, a feature that greatly influenced my coding style, not only in JavaScript.
The latest version of JavaScript, EcmaScript 4, introduces classes into the language, but also keeps the older, prototype-based elements. In doing that, EcmaScript 4, and its ActionScript 3 implementation, aims to fuse OO and functional programming in a single language. C# 3.0 and Scala also offer such combinations. While it is possible to write purely OO programs in those languages, doing so would miss those languages' most powerful capabilities. Fusing OO and functional programming, instead, requires a new way of thinking about programs that could be a pillar of the sort of language renaissance Neward spoke about at the TSS Symposium.
Functional Influences
Having used functional programming in practical, production projects—with JavaScript, ActionScript, and also with Ruby—and slowly working my way through the book Programming in Scala, my programming style changed in subtle but perhaps important ways. And those changes carry over to languages that do not support functional features.
For example, while working on a Java codebase recently, I noticed that I prefer to use as little state as possible. To some extent, that goes against my initial notion that objects combine state with methods that operate on that state. I now prefer to think of Java methods as operations on some inputs that produce a well-defined output. A benefit of the latter style is that it naturally results in test-friendly APIs, since methods become more or less free-standing and side effect-free.
Another functional-influenced change I noticed in my coding style is that I tend to use more immutable objects: Instead of modifying object state, I prefer when a method returns a modified copy of the original object. Of course, doing so every time and with complex object graphs would be rather tedious in Java—as Bill Venners, co-author of Programming in Scala, once noted, Java encourages the more traditional, stateful OO style. Still, the JVM has become a very capable platform for working with immutable objects, and I tend to use such objects whenever I can, even in Java code.
I also no longer worry about my Java methods acquiring too many parameters. I used to think that four or five, or more, method parameters in Java were starting to become bad style. But now I think that using many method parameters is bad only if the method has many side-effects, i.e., if the method transforms some state that those parameters refer to. With side effect-free methods, however, the number of method parameters are not burdensome and, in fact, can clarify coding intention.
Of course, each language requires that we program in its idioms. However, writing code regularly in several languages does influence one's coding style, and such influences spill over from one language to another on occasion.
How have functional languages influenced your coding style?
"For example, while working on a Java codebase recently, I noticed that I prefer to use as little state as possible."
- this is actually what Joshua Bloch recommends in his Effective Java and it's also (what I think) good for concurrent programming.
"Another functional-influenced change I noticed in my coding style is that I tend to use more immutable objects:..."
-again, this is contained in EJ too and it's in line with the first quoted paragraph.
"I also no longer worry about my Java methods acquiring too many parameters. I used to think that four or five, or more, method parameters in Java were starting to become bad style. But now I think that using many method parameters is bad only if the method has many side-effects..."
-the side-effect concern is only one part (although important one), second part is that it's not easy to remember how the parameters go each after another when you've got six int's there, e.g. what the first one means and so on. this can influence the usability of an API. also mentioned in EJ by Joshua Bloch.
otherwise i plan to take a look into scala too. it's not "just another java" running on JVM. thanks for article.
My limited experience with functional programming has led me to view interfaces as a collection of function specifications (usually just one) and less as the specification of a type.
Functional-style approaches are vastly superior to the other available approaches for resource management in Java. Even when other facilities like RAII are available, I think it better, just less so.
> -the side-effect concern is only one part (although > important one), second part is that it's not easy to > remember how the parameters go each after another when > you've got six int's there, e.g. what the first one means > and so on. this can influence the usability of an API. > also mentioned in EJ by Joshua Bloch.
IMO immutable objects offer a nice option over large numbers of parameters especially if a large superset of parameters are used for number of different method calls in varying combinations.
As I learn Scala, I'm trying to challenge how I think about the functionality I'm expressing through the language. For instance, I'm taking a traffic simulation project I did in C for a class a while back and rethinking how it's designed and written. It's strictly an exercise with a known application domain, but I think the exercise of learning how to express something in a different way has to be of value.
I think that we'll see something happen in the current wave of functional programming that we saw happen earlier in OO programming:
At a certain point, every language designer wanted his language to be OO and OO features were grafted on with various effects. Meanwhile, people who were programming in Smalltalk and CLOS, etc, looked on and realized that these people were missing some key insights.. they tools that they were using were keeping them for going as far as the paradigm would allow them to go.
The same thing is going to happen with functional, and this time it will be the people who working in lazy languages like Haskell who will do that looking on.
Javascript is fairly well suited to do functional programming, but actually, you can also do functional programming using C++ or Java with a little bit of effort.
In C++ you can use functors (function objects) which are a part of Standard C++. (my earliest recollection of functors came from Jim Coplien's Advanced C++ book, which predated Standard C++)
In Java, you can use the Method class. Unfortunately, the Java Method class has been marked as final, so you can't subclass from it (C++ has no such limits). But nothing prevents you from creating your own wrapper/adapter class to make your own functional object hierarchy.
Once you have functor capability (in any language), you can then use it to implement Smalltalk-style delegation without requiring an actual delegate object. This technique can be used to implement in-object FSM's, or as a technique to change/transform an object's pseudo-type.
A more important technique however, is to add state variables to the functor itself. Rather than passing in too many variables in the method call (which is an abomination, by the way), you need to separate out the variables that are essentially configuration related from those that actually need to be passed in the method call. Those that are configuration related, you attach to the functor (assuming it has been suitably modified) as state variables. (note: this approach can be further refined to add more gradations between pure configuration to pure data just passing through as you need)
So all in all, functional programming has indeed impacted my coding style in so called "normal" languages because I actually extend and use functional programming itself in them. (just as you can implement object orientation in any language with a struct and a function pointer, you can implement a functor in any language with objects)
And yes, I do also end up using more immutables. But also I tend to create a lot more coding constructs from configuration and metadata, which leads to smaller, more easily checked and maintainable code.
My most fundamental change however, is that I see object orientation itself as just one of several possible ways to relate code and data.
> I think that we'll see something happen in the current > wave of functional programming that we saw happen earlier > in OO programming: > > At a certain point, every language designer wanted his > language to be OO and OO features were grafted on with > various effects. Meanwhile, people who were programming > in Smalltalk and CLOS, etc, looked on and realized that > these people were missing some key insights.. they tools > that they were using were keeping them for going as far as > the paradigm would allow them to go. > > The same thing is going to happen with functional, and > this time it will be the people who working in lazy > languages like Haskell who will do that looking on.
I think you're right. That being said, I think the more widespread use of some of these ideas is helpful. After all, we call can't be ahead of the curve.
The one thing I like about functional techniques is their ability to reduce code by consolidating and abstracting ideas. I use bits and pieces of it where I can in my day job.
Not terribly exciting by the standards of some on this board I'm sure, but I do what I can.
A lot of these techniques are a lot more natural in dynamic languages like haskell, javascript, python, etc. where a function can be passed just as easily as an integer, but I think a lot can be gained from functional techniques and ideas being more widely understood.
And I think with programming languages, as with physical conditioning, you don't really know how much is enough until you know how much is too much. I think we are finally nearing, for lack of a better current example, Java's breaking point in a lot of ways concerning the addition of language features and constructs. But I think we know that only because the last couple of big additions have felt really clunky and met with a whole lot of resistance and griping (a lot of it justified) from the java community.
> IMO immutable objects offer a nice option over large > numbers of parameters especially if a large superset of > parameters are used for number of different method calls > in varying combinations.
I agree. Also, depending upon the domain, I try to use Enums. Then if you screw up the parameter ordering in one of your calls to the function, the compiler tells you immediately.
Don't forget about procedimental. Some times what you need to do is precicely step #1, #2, #3...
The expressive blessing and limitation of functional is that it always seeks a value. But many times one just needs to get something done to the world (a side effect in functional).
The last program I wrote, a couple of days ago, started as procedural-functional, and then migrated to OO-functional to make context management easier. It was in Python, a language that only needs to figure out how to implement type inference to be close to perfect.
Frank - assuming you're not just being an asshole, the problem with that page (which i of course found, being capable of typing "yui" and "documentation" into the google search box) is that it's not clear which link (if any - I tried several) leads to a discussion of "structuring larger programs as a set of interrelated functions". There are API docs, examples, FAQs, and detailed descriptions of various packages, but I couldn't locate a tutorial with the kind of general focus implied in the article.
Jiri - that link is Scala specific; it doesn't appear to have anything to do with Yui.
Flat View: This topic has 27 replies
on 2 pages
[
12
|
»
]
Previous Topic
