|
|
|
Sponsored Link •
|
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.
In a recent blog post, Functional Programming - Is It Worth Your Time?, Andrew Matthews writes that:
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.
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.
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?
Have an opinion? Readers have already posted 27 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.
 | Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market.
Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit