Functional languages will rule

I had briefly spent some time a few months ago playing with OCaml. It has a very interesting typing mechanism that's good if it's doing type interferencing for you, but bad because there are no overloaded methods. "What is type inferencing?" you ask. In Java, you type 'String s = "foo";' The "String" part is unnecessary because you can infer the type of 'foo' from the assignment to a String. Functional languages have a strong ability to infer types based on surrounding code. It means typing a lot less code, because the compiler can tell you the type of a parameter. OCaml, however, takes this to an extreme. You can say "1 + 1", but you cannot say "1.2 + 1.2", you must say "1.2 +. 1.2" as the '+' and '+.' operators are different. This was sub-optimal, but not as sub-optimal as OCaml only supporting 8 bit characters and having a weak UTF-8 library. These two things said "don't bother" to me.

So, the next thing I played with a bit was Erlang. Erlang stands for "Ericsson Language" (some folks have flamed me saying this is not true... dunno... I can't find the source, so maybe Erlang just stands for Erlang and it's coincidence that it's a language created by Ericsson... turns out the flames were right and I was wrong. Erlang was named after A.K. Erlang. Actually, both are correct) and was developed by the folks who make phones and switches. Erlang has been in production for over 20 years and runs a significant percentage of the world's phone switches. It's a functional language with a great message passing mechanism. You can run hundreds of thousands of Erlang processes on a generic Intel box. They're very light weight and do not depend on shared memory space. It's stable (like a phone system.) It's got great hot code replacement capabilities. It reminds me a lot of Lisp (not in the syntactic sense, but in the "it's got a lot of really excellent, real-world, get it done, kinds of stuff in it.") It's also got a good set of web tools including Yaws and Erlyweb (a side note, Yarvis seems like a wicked smart dude.) It's got a bunch of minuses as well. First, it's not strongly typed. Yeah, I know, I know, duck typing rules and tests are all you need, but for large scale projects, I like the compiler to be my friend. Second, it doesn't have any real object facilities that I could find.

As a side note, I was going to try Haskell, the allegedly purest functional language, until I read this post (the URL is fixed), and decided not to spend a lot of time with Haskell.

Finally, I found Scala. Scala is a functional language with OO built in that compiles down to JVM bytecode. I was as happy as a swine is swill. What could be better for a recovering Java guy such as myself.

I've spent the last 10 days with Scala. I'll make another post about my current lust with the language, but suffice it to say, Scala rules.

So, why functional programming languages anyway?

Imperative programming languages force one to think like a computer. Yes, there is a bunch of syntactic sugar and a ton of helpful libraries, but at the end of the day, you're just writing "step 1, move this byte to this place. Step 2, add this constant to this byte. Step 3, compare the result, ..."

If you've ever used a spreadsheet, you've done functional programming. If you've ever written a YACC-based parser, you've done functional programming. Functional programming abstracts the sequence of the actions such that the programmer describes the "what" and the compiler figures out the "how."

Nominally, functional programs are free of side effects. Think of a spreadsheet. You don't see the intermediate values of the calculations in a spreadsheet. You define your formulas, you give input, and the spreadsheet calculates output. There are a couple of hacks that spreadsheet guys have put in to trigger external events or keep track of min/max over time, but those are the exception, rather than the rule.

Side effects in imperative programs lead to errors (I didn't know calling this method would change the state of the object, it didn't yesterday), lead to scattered state (in functional programs, state exists "On the stack" or in well defined places like an I/O stream or a Monad), and mean that messaging between components is more efficient in-memory because the recipient may modify shared state.

On the other hand, functional programs have high level messages for inter-component communications, state in functional programs is kept in well bounded places (rather than every object having a tiny bit of state), modeling the data (state) is a separate activity from modeling behavior (functions). This means better concurrency without issues "synchronized deadlocks" in Java, better distribution of jobs (the message passing is well bounded and thus tasks can be moved to different cores, different CPUs, different non-uniform access areas of shared memory, etc.)

How does this translate to you and me? Well, it's much easier to write the syntax for a new domain specific language using a functional language. This hit me like a ton of bricks when I looked at Haxe. Haxe is a language that compiles down to JavaScript, ActionScript (Flash), or an OCaml-native byte-code. I looked at the Haxe compiler, written in OCaml, and realized that it's brain-dead simple to express BNF notation in a functional language. This blew my mind. Then I discovered pattern matching and wished that I had had functional languages around when I was writing Mesa. Then I read about Scala's futures, promises, cells, etc.

As they say in Ginsu-land "But wait, there's more..." Functional language allow you to do stuff like define access control rules using algebraic notation. You can use a formula right in the language to define access control. Combine this with lazy evaluation, and you get access control rules that are easy to read and debug, but have intermediate values that are cached so that if they don't have to be recomputed, they are just passed. So, you just define your access control as an algebraic formula and the compiler and runtime take care of the rest. It's great from a performance standpoint, but it's even better from a security standpoint.

So, functional languages will rule. They are higher level abstractions. They allow the machine to be smart about distributing tasks across cores, non-uniform memory, and even separate machines. Functional abstractions have be demonstrated by Google to scale massively (10,000+ machines solving problems in parallel.) They remove the drudgery of telling the machine how to move bytes around and allow the developer to focus on the algorithms.

The only real problem with functional languages is that they require a major brain-change in the developer. It may take a generation to convert folks from imperative programming to functional, but I think it will happen... just as it took nearly a generation to convince programmers that it's better to let the computer manage memory.