Thursday, April 9, 2009

Fork it

Most of my friends will be able to tell you that I have an absolute fetish for functional programming languages.

But, I have traipsed from pillar to post trying to find a viable solution to the c based languages that continue to dominate the landscape.

Whilst every port I have visited has shown great promise, there is always something that queers the pitch, so to speak.

Haskell. Lazy is cool but yields unpredictable performance.

OCAML. Fantastic ML derivative, but the concurrency story is weak.

Erlang. Fantastic concurrency, and R13A makes the whole package more compelling, but the outright performance is ho hum.

Clojure. OMG a Lisp that makes sense!!!! The JVM may not be the perfect platform but Clojure makes more sense than CL or scheme, but, but, but the JVM!!!!!

Scala. Functional programming merged with OO, prima facie pretty compelling, but I am concerned about the unholy alliance of OO and FP, and of course, the JVM!!!!!

Likewise I have discounted Python and Ruby because of their weak concurrency model (GIL), although, that being said, the reality is that both of these languages thrive in the w3 world and the whole process / thread per request -- via apache et al -- is inherently parallel.

The question I would like to pose is......

Am I chasing something that is already available through fork / execve?

Let's chat about it.

2 comments:

FinderGuy said...

Aye mate,

Perhaps I am misunderstanding you but it sounds like an example of this is Google Chrome, where each page is a process. I haven't used it but it does seem to have some followers.

\pat

The honey monster said...

Pat,

That's almost it.

Chrome isolates each tab by adopting a process per tab approach. One failed tab doesn't bring down the browser, as opposed to say FireFox.

But in the context of programming languages, we have been attempting to achieve some level of parallelism with threads. Despite the gigantic Elephant in the room (Multicore) a lot of programming languages either have primitive support for threads or a total lack of SMP capability.

For example in OCAML I can spawn n threads but they are all going to run on once core, not a great story when I have 8 available cores.

Does this disqualify OCAML as a candidate language or can we simply use fork to achieve parallelism and isolation?

I have a sneaking suspicion that doing so also helps you achieve a share nothing model, a la Erlang, which is certainly not the case when using threads.

Whatever the solution I think it is imperative that the basic unit of parallelism, be it process or thread, is not something that the developer needs to deal with, the language itself should provide a mechanism to distribute work to available cores.

For example, map functions, or in Obj-C
[NSArray makeObjectsPerformSelector:] are candidates for distribution, but only in a purely functional context, if the objects, nee data structures, share state, then perhaps order of execution becomes important and therefore they are not distributable.