jan.varwig

Since I wrote about F# in August, my progress has been rather slow.
There was a lot of work to do for Uni, almost all involving final touches to Pavel, the data-analysis tool me and a few other students have developed as a student research project. We’ll publish Pavel next week on SourceForge, I’ll write a few lines about it then.

Another thing that has held me back is my fascination for Haskell. Read the rest of this entry »

It’s pretty simple once you’ve seen the Solution:

You can then use those attributes with your objects properties:

Globalizing the Category follows the same Pattern, extending CategoryAttribute.

There are some traps to avoid though:

• Fetching the String in the Constructor does not seem to work.
• If you use the Globalized…Attribute with an Identifier not in your Resources, the Program might throw OutOfMemoryExceptions at startup.

Meine erste Einstellung gegenüber C# war ablehnend. Wozu ein neue Sprache die kaum wesentliche Vorteile gegenüber Java bietet? Nach näherer Beschäftigung mit .NET 2.0 sah die Sache besser aus. Properties? Nice! Anonyme Funktionen? Praktisch!, Closures und Iteratoren? Yay! Langsam schien die Entscheidung doch nicht die verkehrteste zu sein.
Bei der konkreten Arbeit offenbaren sich jedoch allmählich die Unterschiede zwischen Theorie und Praxis:

• 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?).

Dritte Woche PG, so langsam geht es los. Müssen die ersten Entscheidungen getroffen werden, gibt es auseinandergehende Meinungen.

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.

Das klingt beeindruckend und ist die offizielle Bezeichnung der Projektgruppe die mich dieses und nächstes Semester beschäftigen wird.

Bei dem Projekt geht es darum, Methoden und Implementierungen zu entwickeln, die es Ingenieuren aus dem Maschinenbau erleichtern, Lösungsmengen heuristischer Algorithmen interaktiv zu untersuchen. Der Witz dabei ist, dass der Lösungsraum wesentlich mehr als 3 Dimensionen haben kann. Aufgabe der Projektgruppe ist es, sich zu überlegen, wie man einen solchen hochdimensionalen Lösungsraum vernünftig navigieren und betrachten kann und eine Implementierung dafür zu entwickeln.

Letzte Woche hatten wir unsere erste Zusammenkunft, eine zweitägige Seminarfahrt in der wir 11 uns gegenseitig über unsere jeweiligen Spezialgebiete informiert haben. Darüberhinaus war die gemeinsame Fahrt natürlich auch “teambildende Maßnahme”, allerdings hätte es einer solchen kaum bedurft: Ich denke dass wir da eine sehr gute Truppe zusammenbekommen haben.

Ich bin gespannt was die nächsten 2 Semester bringen werden.