Another thing that has held me back is my fascination for Haskell. I have read enough of Jason Hickeys Introduktion to the Objective Caml Programming Language to see lots of charming similarities between the two languages, and I’m really starting to like OCaml/F#, I’m looking forward to finally writing soemthing useful in it, but Haskell’s purity and late-binding are still captivating, somehow, making me peek over to the world of Haskell from time to time.

That slumbering interest once gain came back to live when I stumbled upon XMonad and then, via their press-page, upon Simon Peyton-Jones’ (author of GHC, a bright, funny guy) OSCON 2007 Presentation A Taste of haskell (Part 1 and 2).
The week after watching the presentation, I was looking for understandable explanations of monads again. What I’m always looking out for is a tutorial that treats them not in their entire category-theory-context, and neither in terms of plain haskell. I haven’t found anything like that so far but several Haskell-based approaches that are written for beginners of Haskell (in contrast to the many written for people with haskell experience) were quite helpful.

The first was Meet Bob the monadic lover. It starts out lighthearted and funny but the examples get increasingly convoluted and artificial the closer the text comes to the topic of monads.

Next was A Schemer’s Introduction to Monads which tries to explain them using CPS. I merely glanced over it since I’m not a Schemer and I had some tutorials that looked more promising:

In Everything Your Professor failed to Tell You About Functional Programming Shannon Behrens writes

At this point, the reader may be begging for some code. One of the hardest things about learning Haskell is you can’t understand Haskell without understanding monads, and you can’t understand most of the monad examples without understanding Haskell.

(yes!) and gives a glimpse of the monad concept by implementing a monad in Python and Javascript.

Behrens text not being quite enough to fit the concept into my head, MenTaLguY’s Monads in Ruby Tutorial went a little further by implementing a basic monad using Ruby (which I’m far more familiar with than Python or JS, whose syntax also doesn’t get in the way of expressing the essential parts of the monad pattern).
Unfortunately Monads in Ruby was written in 2005 and never quite finished.

Monads as Containers picks up where Monads in Ruby leaves, with in examples in Haskell again. I haven’t read far enough to actually comment on it though.

A few classics on the topic might come in handy once I’ve worked through Monads as Containers: Noel Winstanley’s What the hell are monads? and Jeff Newbern’s All about monads.
I’m not hardcore enough (yet) to tackle http://en.wikibooks.org/wiki/Haskell/Category_theory or Eugenia Cheng’s Tutorial Videos on Monads (blackboard lecture at breakneck speed), both more from a mathematical point of view.

Phew, I was about to write about F# originally.
Although my progress through the tutorial is a little slow, it is very well written and so far I didn’t encounter any hard parts. Besides that the only noticable thing was a discussion on the F# Mailing list about (automatic) parallelization of F# Code. Bottom line: automatic generation of parallel code is not possible at the moment due to the unpure nature of OCaml/F#. There exist certain tools however, to help with the manual specification of parallel computations, like the Task Parallel Library.

On my journey into the weird world of functional programming on the .NET CLR, I continue to stumble upon interesting stuff. Papers, articles, interviews, each worthy of hours of dedication. Alas, my day still has only 24 hours (I need to work around that somehow), so at the time being I can’t do much more than glance over everything.

The questions I was trying to answer during the last few days were (and to a great degree still are):

• What is the cost of using threads on the CLR and how does F# handle them?
• Is F# fast enough to handle computationally-intensive tasks?
• Is F# suited for distributed programming?

The cost of using threads on the CLR

The answer to that question is pretty clear, fortunately. This thread on the Joel on Software Discussion Board pretty much deals with the question from my last post: .NET/F# vs. Erlang. The initial question in the thread was along the lines of “I want to do computation with a great bunch (n x 1000) of agents, represented by processes, communicating via messages. Should I use F# or Erlang?”.

The first answer was already very helpful to me:

My understanding is that the .net threads are very heavy weight (128K) when compared to erlang processes (300-400 bytes).

So, no native CLR threads for larger numbers of processes. After a bit of thinking though, this turns out not to be a problem. What I am planning can easily (perhaps even best) achieved by a few, long-running threads. Yet, the need for many agents and lots of communication might turn up later and I don’t want to lock myself into something that’ll leaves me in the lurch later.

Further down the thread, someone posted links to a Microsoft Project called Concurrency and Coordination Runtime, used in the Robotics Studio and fit for precisely this problem.
I have only had a peek into the CCR and if I understand the indroduction of Satnam Singh‘s Paper An Asynchronous Messaging Library for C# correctly, it’s a library that runs on the unmodified CLR and provides green threads (or something similar) via CPS with good performance.

Im definetly gonna look deeper into this and I hope there’s a way to test it out. Hey cool, it’s free for non-commercial uses!

Performance of F# and distributed programming

Its nice performance seems to always be among the major points proponents of OCaml bring up and it was one the major reasons for me to consider F#/OCaml. Hard numbers on F# performance for this weren’t that easy to find though. The official F# page only claims it to have “a performance profile like that of C#”. This article however turned out quite informative:

Like OCaml, F# is excellent at writing tools for symbolic programming. Examples of this type of programming include static analysis, compilers, and other sophisticated analyses over structured data terms. Remember using Maple or Matlab? How about Mathematica? That’s what writing F# is like. If F# is to be used to analyze various complex problems, then harnessing it to a virtual supercomputer seemed like a logical thing. Slated to learn two new technologies, I was hoping I hadn’t bit off more than I could chew.

(emphasis mine)

This is exactly my situation. The article describes an experiment in distributing a computationally intensive algorithm over multiple machines using Alchemi, a .NET Grid Computing Framework which was deployed first using pure C#, then F# wrapped in C# and finally pure F#. The results?

Without any optimization the F# implementation took 453 ms. C# finished up in 62 ms. Turning optimization on caused the C# results to drop to 46 ms. And, most shocking of all, the F# was dead even at 46 ms! Apparently, the F# compiler does an excellent job optimizing the code. Continuing on, I ran the entire C# and F# grid applications against one another. Without any optimization the C# code took 3.9 seconds to calculate 100 digits of pi while F# only took 2.8 seconds. Optimizing this application showed that F# would finish in 1.5 seconds while C# would not complete any faster than 2.6 seconds.

Nice!

Next steps

I’m definetly gonne work my way through one of the excellent OCaml tutorials online.
The ones that seem recommended most often are

• Using, Understanding, and Unraveling the OCaml Language by Didier Rémy
• Introduction to the Objective Caml Programming Language by Jason Hickey
• Developing Applications With Objective Caml, an entire book, available online with whopping 750 pages

More Stuff

Like always, browsing the web got me sidetracked here and there instead of keeping me focused on F#.
I want to share the most interesting discoveries with you.

• Threading in C# by Joseph Albahari is a pretty profound free online book about, well, threading in C#
• Brian Beckman: Monads, Monoids, and Mort is a Channel 9 interview in which Brian tells a bit of history about his career, chats about functional programming, nicely explains Monoids and Monads on the way and introduces a pretty shocking statement about the relation between VisualBasic and C# at Microsoft Research.
• F# News is a blog that deals solely with, who’d have guessed it, F#
• F# for Visualization is a book from Flying Frog. The page links to an impressive Demo illustrating F#’s performance.
• Meet Bob the Monadic Lover seems to be a very entertaining introduction to monads. I haven’t read it yet though, I’m still fighting my way through…
• Category Theory for Beginners, great slides from an introductory course into category theory which focus on the motivations behind and practical uses of category theory for computer scientists.

Holy crap, that was a long post.

OCaml has threads, exceptions, call-with-continuation, calling conventions to and from C, a rich standard library with collections, networking, I/O, graphics, a complete interface to the Unix programming API, and a powerful module system that blows Java’s packages away. It has interfaces and bindings for Oracle, MySQL, postgres, berkeley DBs, CORBA, COM, xml-rpc, SOAP, XML, perl-compatible regular expressions… the list goes on. You name it, it’s there.

OCaml has the potential to make me happy as a programmer, finally.

Mjamm :)

At first I was a bit amazed at how much support there is for real-world development in OCaml – as far as I can tell, it’s got everything you’d find in any other mainstream language, with a relatively smaller user community.

But now I think it’s not amazing at all; it’s a natural consequence of the fact that it’s simply a superior language. It stands to reason that if you have a language that really does live up to the promise of making people (say) 10 times as productive as the other languages out there, then it will only take 1/10th the people (or time) to reproduce the functionality that’s been created for other languages. And it’s been around for a decade – much longer if you consider that it was derived from ML, which started in the late 1980s.

Ich denke ich werde da mal nen Blick riskieren. Auch wenn Steve anmerkt, dass OCaml für Webserver ungeeignet sei (leider ohne zu erklären warum). Für Server gibt es jede Menge mächtige Sprachen, vielleicht ist Erlang da das richtige (wenn nicht, da ist immernoch Ruby), aber eine mächtige Sprache für den Desktop… das klingt zu verlockend, gerade mit der .NET Anbindung von F#.

Ich werde mir mal die hier zu Gemüte führen.