The compiler complains that the else in the second line does not belong to any if.

Assert isn’t a function, duh!

From MyAssert.h, included in some completely inobvious place:

Moral of the story:
Preprocessor macros make for some really entertaining afternoons.
Oh, and avoid C++ wherever possible.

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.

Bisher schlage ich mich damit ganz gut:

2007: ein bißchen Python
2006: C#, Ruby, Javascript
2005: genug C++ um da in Zukunft einen Bogen herum zu machen, genug Haskell um ein permanentes distanziertes Interesse zu erhalten das vielleicht irgendwann durchschlägt in ernsthafte Auseinandersetzung.
2003/2004: Java
1999-2002: PHP, SQL

In der Hoffnung, dieses Jahr noch die Gelegenheit dafür zu haben, bin ich gerade dabei mich zu orientieren womit ich mich als nächstes befassen soll. Bis vor 2-3 Wochen stand Lisp –und das seit langem schon– ganz oben auf der Liste. Vor etwa einem Monat aber hat mich der Haskell Web Store Post auf LtU wieder dazu gebracht, mein Haskell Script herauszuholen und die Schönheit funktionaler Programmierung und Haskells Typsystems zu bewundern.

Ich weiss nicht wie ich darauf kam, aber gestern fing alles damit an dass, ich “Erlang vs. Haskell” bei Google eingegeben habe. Inzwischen knubbeln sich auf Platz 1 meiner Liste 2 Sprachen, Lisp ist auf Platz 2 gerutscht und Haskell wieder auf die 3. Konkret bin ich gerade fasziniert von Erlang sowie OCaml.

Erlang wird wegen seiner extremen Robustheit und der überragenden Fähigkeit zum Multiprocessing schon lange als das nächste große Ding gehandelt. Yariv’s Blog versprüht einen Enthusiasmus der mit dem kribbeligen Gefühl zu vergleichen ist als mir die Lichter von Ruby aufgingen. Leider habe ich gerade keinen Bedarf einer hochskalierbaren Webanwendung.

OCaml hingegen ermöglicht mir, in Form von F#, funktional in der .NET Umgebung zu programmieren. Und das liesse sich mit ein wenig Phantasie vielleicht sogar zu einem Diplomarbeitsthema machen…

• Die ganzen coolen Funktionen und Konstrukte verstecken sich hinter einem Wust redundanter Syntax, die nur duch viele automatische Funktionen in VisualStudio 8 erträglicher wird.
• VisualStudio kommt zwar mit einem Debugger, ein Speicherprofiler muss aber extern installiert werden, ein Laufzeit-Profiler kostet extra.
• Wenn ich den erwische der die Idee hatte, XML als Markup für die DocComments zu benutzen…
• Viele der netten Features sind in ihrer tatsächlichen Verwendung nur noch halb so nett. Das Programmieren in streng getypten Sprachen ist eine Qual wenn man einmal mit Ruby gearbeitet hat.
• Die Doku im MSDN ist zwar umfangreich, aber verwirrend und schlecht organisiert. Die Methoden, Properties und Member der Klassen stehen alle auf jeweils einer einzelnen Seite mit unzähligen Links, die irgendwohin führen. Soviel Redundanz führt auch dazu, dass Suchergebnisse selten akkurat sind und die gewünschte Information erst nach ein paar weiteren Klicks gefunden wird.

C# ist im Ansatz eine gute Idee, mein ungutes Gefühl wird aber vor allem duch die Implementierung durch Microsoft verursacht. Man merkt schnell dass man hier mit proprietärer Technik arbeitet wenn viele wichtige Tools entweder nicht verfügbar sind oder Geld kosten (oder kennt jemand einen brauchbaren freien Profiler?).

Die Frage: Mit welcher Sprache wollen wir das Projekt implementieren? Zur Auswahl stehen C# und Java. C++ schied glücklicherweise schon in der Vorrunde aus.

Unsere Ausgangssituation sieht so aus, dass alle “so ein bißchen” Java Erfahrung aus dem Sopra haben, zwei Leute über etwas weniger Erfahrung mit C# verfügen. Kriterien die die Entscheidungsfindung erleichern sollten waren

• Verfügbarkeit und Qualität von Bibliotheken
• Performance
• 3D-Grafik Wiedergabe

und zu guter Letzt

• Vertrautheit mit der Sprache

Über die ersten drei Punkte bestand im wesentlichen Einigkeit, am letzten schieden sich jedoch die Geister, zwei Argumente stehen sich jetzt gegenüber:

Gegen C# spricht, dass so gut wie keiner von uns damit Erfahrung hat und dadurch neben den eigentlichen Anwendungsproblemen noch das Einarbeiten in eine völlig neue Sprachumgebung als Aufgabe hinzukommt. Der damit verbundene Aufwand ist nicht zu unterschätzen.

Zur Verteidigung der Verwendung von C# wird angeführt, dass man die PG dazu nutzen wolle, sich neben Java noch eine weitere, auf dem Arbeitsmarkt augenscheinlich momentan beliebte Sprache anzueignen.

Dieses Argument steht allerdings auf keiner guten Grundlage.

Vor allem ist der Wunsch eine neue Sprache zu lernen eine reine Privatangelegenheit und hat eigentlich keinen Bezug zu den Zielen des Projektes. Vorausgesetzt dass Java und C# unter allen erwähnten Kriterien äquivalent oder zumindest ähnlich sind, wird durch die Verwendung von C# nichts gewonnen, im Gegenteil, die Entwicklung wird durch den beschriebenen Lernaufwand noch behindert.

Darüberhinaus gibt es noch eine falsche, zumindest aber zweifelhafte Annahme die dem Argument zugrundeliegt. Leider konnte ich den Hintergrund dieses Gedankens in der Sitzung auf die Schnelle nicht überzeugend formulieren und habe ihn erstmal für mich behalten. Jetzt habe ich mich ein bißchen hingesetzt, nachgedacht und festgehalten was ich genau meine.

Die Idee, mit dem Lernen von C# jetzt seine Berufschancen zu erhöhen ist Unsinn

Aus –im wesentlichen– zwei Gründen:

Wem wirklich etwas daran liegt Sprachen zu lernen, der wartet nicht darauf dass die Uni auf ihn zukommt. Eigeninitiative und die Fähigkeit sich für eine Sache so zu interessieren dass man seine Freizeit darin investiert sind wesentlich mehr wert als C#. Paul Graham erläutert das Phänomen in Python Paradox:

It’s a lot of work to learn a new programming language. And people don’t learn Python because it will get them a job; they learn it because they genuinely like to program and aren’t satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I’ll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they’ll be able to hire better programmers, because they’ll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don’t learn merely to get a job.

Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they’re exactly the companies programmers would most like to work for. Google, for example. When they advertise Java programming jobs, they also want Python experience.

Nun bin ich nicht so naiv zu glauben, alle deutschen Personalchefs würden Paul Graham lesen (sehr schade eigentlich), aber wenn man auf sein Engagement und seine Bandbreite an Programmiersprachen hinweist, dürfte es kein Problem sein, jemanden davon zu überzeugen, dass man sich innerhalb kürzester Zeit in jede beliebige neue Sprache einarbeiten kann.

Umgekehrt aber einem der Personalchefs, die Graham kennen, von der eigenen Flexibilität und Begeisterung für Softwareentwicklung zu erzählen, wenn alle Spracherfahrung die man vorzuweisen hat ein bißchen Java und C# im Rahmen halbfreiwilliger Uni-Veranstaltungen sind, dürfte schwierig werden.