Trying Out Functional Programming - Episode 5

I suppose I should probably stop referring to this series as Trying Out Functional Programming since Erlang is not a pure functional programming language, but rather a declarative concurrent programming language.

The semantics aside, Erlang lets you model a domain as a set of interacting processes. This is a fairly natural - at least for me - way to model most problems. For example, you take the popular board game Settlers of Catan. It is composed of a board with terrain hexes, intersections, and paths. I modeled each hex, intersection, and path as a separate process whose current state drives the determination of rules in a distributed rather than centralized manner.

For example, building a settlement on an intersection is allowed only if no neighbouring intersection has been built on. Instead of checking the neighbouring intersections on each request the neighbouring intersections notify it when they get built upon. As a result the intersection changes it's internal state (the function it is executing) to blocked. As a result it no longer responds to build requests, making it completely impossible to build on it.

Another nicety of the process-oriented or Actor-model approach that Erlang facilitates is the lack of interference from buggy code elsewhere in the system. The intersection in question cannot be coerced into accepting the construction of a settlement. This is due to the fact that the buggy code would have to send a message to change the intersection's state. Thankfully the intersection process is coded to disregard such requests.

This is a very early work in progress and is mostly a mental exercise at the moment, but the possibilities opened up by Erlang's approach are exciting...

Trying Out Functional Programming - Episode 4

My bad experience with Haskell drove me to conclude (prematurely) that there was little I could ever hope to achieve using the functional programming style. It turns out that I was wrong. Erlang actually makes practical programming possible in a functional style.

Erlang is backed by years of success for Ericsson and demonstrates the value of focussing on productivity for developing real systems rather than conforming to a philosophical ideal as Haskell does. This gives Haskell many merits, but they are mostly irrelevant to me. On to learning Erlang…

Erlang is in active use primarily in telecoms where I/O is a obviously a major concern. Haskell eschews side-effects, which makes I/O FUBAR. Haskell's reasons for this are perfectly sound, but they also make Haskell entirely inappropriate for my purposes.

The tutorials and video presentations about Erlang are very practically focussed, showing how it can be used to switch telephone calls and create servers that respond to inbound requests. Haskell tutorials (in my experience) focus on language semantics (like its type system) and focus on examples of modeling mathematical expressions. Its my fault for not researching the languages properly. It would have been immediately apparent that Haskell was an inappropriate language for implementing RESTful servers.

Stay tuned for Episode 5…

Trying out Functional Programming: Episode 3

I received my copies of The Haskell School of Expression and Programming in Haskell a few weeks ago. My lax efforts in posting to this blog were definitely aggravated by the soul-seeking that has ensued from looking into Functional Programming (FP). This might sound absurd, but - as software developer who primarily uses Java - the FP approach to design is so fundamentally different from what I have employed for the last 7 years that it caused me to question a lot of things.

Chief among my gripes about FP is that I do not intutively see how to map a problem into a functional program. This is likely a failing of my education more than anything else. On the other hand, it could also be the fact that FP is a terrible match for my current obsession with web design. There are several production quality Haskell web application libraries, but they all seem to possess a common odd trait: they focus on writing page code in Haskell or extended Haskell-based grammars.

I mentioned in a previous post that server-side generation of UI markup is problematic at best and this just seems extreme. It is bad enough that most web frameworks require an exceedingly good understanding of programming, but page design in FP to me just seems to be overkill. I do not need my page layout to be provable or testable and I seriously doubt that many applications have this requirement.

The real strength of FP on the server-side for me would be in handling computationally-intensive aspects of requests. In effect it would be better as a delegate from another web framework. An FP language might also be a good match for developing a RESTful JSON server, but I have not been able to think up a good way to implement such a server.

Since I am much more interested in the presentational rather than the computational aspects of application development I think my foray into FP ends here. Thanks for reading :)

Trying out Functional Programming: Episode 2

First the pains… On Ubuntu for PowerPC, the GHC 6.6 APT package does not have GHCi and seems otherwise broken. This is due to a bug in Debian Make apparently, so the maintainer of the GHC package (Ian Lynagh) has no way of fixing it at this time. Instead. I opted to download the source and ./configure, make, sudo make install GHC myself and it worked. For reference I literally changed nothing, I just typed:

sudo apt-get install ghc6
./configure
make
  waited roughly two hours as my Mac mini G4 1.42GHz built GHC
  6.6.1 with GHC 6.6 and then self-compiled in-place to get GHCi
sudo make install

I am now into the mind-bending world of Haskell's polymorphic type system. At this point in the YAHT (Yet Another Haskell Tutorial) I realized that I needed a more substantial background in how to think like a functional programmer. To this end I purchased The Haskell School of Expression. Also realizing that I benefit from a good understanding of the concepts and capabilities of Functional Programming I also ordered Programming in Haskell; a very recent yet highly recommended addition to the Haskell literature (31 January 2007).

It looks like I am going to follow this through and actually learn a totally new programming paradigm. I hope that in so doing I will be able to design and develop more reliable software. Stay tuned for Episode 3…

Trying out Functional Programming: Episode 1

I have started looking into Functional Programming as a potential saviour of software quality in general and scalability to multi-core, multi-processor machines in specific. Much of what I have read so far suggests that Imperative and Object-oriented Programming do not work well when formal methods of quality assurance need to be applied. Beyond that there have been 30 years of nearly fruitless efforts to auto-parallelize code written in those styles.

Functional Programming seems to offer the promise of trivial support for testability and concurrency. Both of these are enabled - so far as I understand it so far - by the absolute enforcement of side-effect free code. In other words a function is guaranteed absolutely - in a mathematically provable sense - to return the same value for the same arguments. This makes 100% test coverage possible in theory, and rock-solid range of expected input testing easy.

An imperative or OO program confounds even range of input testing since unrelated function calls can influence the output of the unit being tested. In the ideal OO program, good programming practice would suggest that this would not be the case, but in practice developers take short cuts to meet deadlines and the create cross-module stateful interactions for convenience reasons. In the ideal OO case you could test a module assuming that the output of a function can only be altered by other function calls to the module. That's the best case: a guarantee of needing to do stateful testing at the module level. At best that is substantially more complicated that testing individually idempotent functions. Functional Programming makes the functions the units and thus greatly simplifies the testing effort.

Automatic Concurrency is made possible because the standalone nature of functions makes it possible to trivially distribute them. A smart compiler is able to leave a program semantically unchanged while automatically determining and distributing the independent function calls across processors or cores. I am in way over my head as far as the theory goes here, but the idea of writing a program in a form that describes what I want and letting the compiler do the work to achieve it is very compelling.

For learning purposes I am focussing on Haskell, since it has a great tutorial , a decently large user base, and is a pure functional language. As I keep digging in on Haskell I will post my thoughts. Stay tuned…