Functional Programming

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!

Update: 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.

Comment by Functional Programming In Depth, part II:Python and Scala retrospection | Gioorgi.com on 2011-08-29 09:08:39

[...] a Scripting Language Open SourceCappuccino: Objective-JClosure in C#Being Functional F#CScharpizzatiFunctional ProgrammingFunctional Programming In Depth, part II:Python and Scala retrospectionThis is the second article on [...]