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.
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.
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.
Functional and OO
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.
> -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.
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.
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.
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