Functional Programming

This entry is part 14 of 19 in the series Programming Languages

Because of the success of my article on java closure, I have decided to write another article on functional programming.

In the last year functional programming is waving back to us, for a lot of reason. Let’s summarize the facts:

Functional programming is based on the core concept of pure function. The main advantages of functional programming is the lack of side-effects, at least at the syntax-level of the language.

This blog article explains very well the difference between imperative and functional “way of life”; we report a bunch of it:

Sophisticated type systems […] aid in program inference, which is the extent to which the computer (or the programmer with the aid of the computer) can infer the correct program from type information (think tab completion, only moreso). Program inference is currently an active area of research.

Type system is a very important key here. “tab completion” and type-based refactoring are more difficult or even impossible on dynamic languages. For this reason Java/C++/C# where winner and SmallTalk was a loser. And who is writing is a strong dynamic language lover, but languages with complex type semantics win easy on devel tool and compiler optimization. So a complex type system is a good thing. Erlang has a pattern-matching system, with a prolog-like symbol structure.

As a side-note a lot of OO folks are discovering the functional approach as a tool to aid in modular design. They call it “dependency injection”, “inversion of control”, “interpreter pattern” and the like.
Functional programming is a restriction that the programmer puts on his programs. Having a language with a compiler that will warn you if you’re breaking referential transparency is helpful, but not essential. I do functional programming in Java, for example, which most people consider an “imperative OO” language.


The lack of side effects is important because it free us to the need of heavy transaction semantic. If we have a huge set of process without shared resources, we can build simpler engine to run them in parallel. Locks are evil: the best way is to avoid evil, i.e. avoid the need of things like java synchronized keyword and so on.

Even in Java, in my ten years experience, Entity and Stateful EJB are avoided like fire by Senior Software Architect. The reason is simple: application server will have a lot of stuff to do to fulfill the contract of a Stateful EJB, and your app server will easily run out of resources or stop responding when the load grows.

On this side Erlang is more interesting than Lisp on my humble opinion, because it had an integrated process scheduler,and an intrinsic concurrent way of thinking. Erlang process send asynchronous messages, and the semantic is very easy: you send a message, they never return, they never fail, end of the story. If the process still is alive, it will receive it, process it and so on. If the process is dead, nothing will happen. Every process has a mailbox where messages arrive. Because all the data are static (do not mutate). Sending a message simply imply to “share” the message between the sender and the receiver.

Erlang process scheduler monitors every process mailbox, and if process A and B flood process C with messages, the Erlang scheduler can give more CPU time to process C to rebalance the situation.

Scala amis to Erlang-ize Java, and we will look to it in the next weeks. Keep reading us!

A Scala to .NET compiler has been released in a quite complete form:

Miguel Garcia, part of the Scala group at EPFL, has been striving to make the Scala productivity available to .Net developers too. In a project funded by Microsoft, he has now reached a major milestone in delivering that capability. In this interview Miguel tells you how you can now use Scala on .Net and gives an insight into the way this challenging project has been achieved and the future direction.

So, will be Scala a Cross-VM language, crossing the bridge no one think before?

Useful References

Erjang is a virtual machine for Erlang, which runs on Java. It seems faster then the ErlangVM

LambdaJ is a small Java library which aims to bring closure to Java.

Scala is a Java peak of functional programming: the Akka project is somewhat an  Erlang-equivalent written in Scala.


How many times have you read or written the same two or three lines of code that frequently seem to go together, and even though they operate on different objects, feel like the same thing? And how often these repetitions involve some sort of collections iteration or more generically manipulation? These repetitions in the code is something that developers eventually learn to filter out and ignore when reading code, once they figure out where the interesting parts are placed. But even if the developers get used to it, it slows them down. Code like that is clearly written for computers to execute, not for developers to read.

lambdaj is designed to easily manipulate collections. Its features are intended to filter, convert, index and aggregate the items of a collection without explicitly iterate on it.

Integrate lambdaj in your software architect toolkit (italian link)

Closure in Java: fast and nice!

This entry is part 6 of 19 in the series Programming Languages

Working for two very important Banks, I have the need to play with Closure in Java. I have a lot of trouble looking at a good description of the subject, until I read a post on StackOverflow.

I have decided to re-cook this subject, adding a my specialized Example also.

Let’s start!

Continue reading “Closure in Java: fast and nice!”