I started a new Google Code project for my very young GP library written in Erlang: http://code.google.com/p/gerl/. You can define a problem by defining the following hooks:
-module(simple_gp).
-compile(export_all).
functions() ->
[{add, 2, fun(V, [X, Y]) -> gerl:evaluate(?MODULE, V, X) + gerl:evaluate(?MODULE, V, Y) end},
…]
terminals() ->
lists:seq(1, 100).
fitness(Organism) ->
[run gerl:evaluate(?MODULE, [{var_name, Value},...], Organism) for various values and sum up the result]
A lot of work needs to be done to simplify this process but for now you can run the following command to see the best of breed after an arbitrary number of generations:
$erl
> c(simple_gp).
{ok,simple_gp}
> c(gerl).
{ok,gerl}
> lists:nth(1, gerl:many_rounds(simple_gp, gerl:population(simple_gp, 100), 10)).
{sub,[{x,[]},40]}
The command reads: give me the fittest organism after 10 rounds of inbreeding a population of 100 random organisms. The module simple_gp is passed in so that gerl knows which fitness function, functions, and terminals to use. Gerl is still very rough around the edges. I did it mostly as an experiment to learn more about Erlang. The organism that evolved is nowhere near the solution. Granted, it only ran for 10 rounds, but there remains a lot of work to be done. I really need to implement mutation!
I’ve been reading a lot of blog posts about Erlang lately and a lot of people have expressed their belief that because Erlang isn’t object oriented that the language is lacking something. This is very similar to the argument that one’s native language is far more expressive than other languages. I’ve heard this argument from people who speak English, Korean and Spanish and, oddly enough only the people that spoke the same native language agreed. We adopt such beliefs because we are ignorant of how to express certain things in other languages not because it can’t be done. The whole idea of functional languages after all, is that functions should not have side effects. How then does one wrap state and functions together (that is what an object, is, right)? Well, in Erlang, processes can be used to emulate objects. Spawning a new process and sending it messages that it can use to update its per-process dictionary is one way of achieving an object oriented-like implementation in an Erlang program. The approaches that one uses when solving problems in an imperative language and solving problems with a functional language can be drastically different. Slava Akhmechet does a good job explaining this in his article Functional Programming for the Rest of Us:
Functional languages are extremely expressive. In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together. Once such pattern is an Adapter pattern (how is it different from Facade again? Sounds like somebody needed to fill more pages to satisfy their contract). It is eliminated once a language supports a technique called currying.
I highly recommend this article to anyone who’s wondering what FP is all about. Going back to the analogous natural language argument, as a native English speaker when I first started learning Korean I wondered why they required so many levels of politeness. After some reflection I realized that we have a lot of the same levels of politeness in English but they are implicit in the words that we choose and our tone. Very often in Korean the subject can be omitted and verbs can be conjugated generically, which can lead to very terse conversations (like Ruby), but often, even for native speakers this can lead to confusion as so many things are implied. The words for “me” and “you” are spelled as though they would be pronounced exactly the same: 내가, 네가. Thank goodness that they aren’t pronounced as they are spelled!
I personally like languages where things are explicit but not overly explicit. Java frameworks that require hundreds of lines of XML configuration would drive me insane. That said, magical metaprogramming is not always good and can sometimes be hard to debug. Python right now is the porridge that tastes just right. Erlang is my current obsession but I’m not a zealot (yet).