Ironruby: Besser programmieren in der .NET-Architektur

Das .NET-Framework überzeugt deshalb, weil es den Entwicklern 90 Prozent der langweiligen Routinearbeiten vom Hals hält. Die .NET-CLR lässt dem Entwickler die Wahl der am besten für die jeweilige Aufgabe geeigneten Programmiersprache (zumindest theoretisch, sofern eine Alternative existiert und funktioniert). Aber die Arbeit mit VB.NET ist bei vielen Aufgaben recht unangenehm, und auch C# löst nicht gerade bei jedem Begeisterungsstürme aus, wenn auch C# 3.0 einen guten Eindruck macht.

Eines der Dinge, die einem im .NET-Universum schon einmal zur Verzweiflung bringen können, ist die Tatsache, dass alles jenseits von VB.NET oder C# als „gefährlich“ betrachtet wird, nur weil es sich nicht um ein ausgewachsenes Microsoft-Produkt handelt und sich häufig nicht so „anfühlt“ wie eine der Mainstream-Programmiersprachen. Viele dieser Ängste sind durchaus begründet. Ironpython brachte beim ersten Release noch keine Unterstützung für Visual Studio mit – und Python ist keine Sprache, für die sich viele Entwickler interessieren. F# ist eine interessante Programmiersprache zum Herumspielen, aber es gibt nur wenige Entwickler, die gern mit einer funktionalen Programmiersprache arbeiten, und noch weniger, die darin auch gut sind.

Bühne frei für Ironruby

Ruby ist schon seit längerem eine der interessanteren Programmiersprachen. Die Sprache verbindet die an Perl geschätzte Flexibilität mit einem soliden Objektmodell und ist außerdem eine dynamische beziehungsweise interpretierte Programmiersprache – ebenfalls ein attraktiver Aspekt. Trotzdem gibt es zahlreiche Gründe, die einen dann doch wieder davon abhalten, es einmal wirklich mit Ruby zu versuchen, vor allem, wenn man die Arbeit mit Visual Studio ebenso zu schätzen weiß wie das .NET-Framework selbst.

Das alles hat natürlich überhaupt nichts mit Ruby als Programmiersprache zu tun. Und Ruby on Rails ist nicht Ruby, sondern ein Framework für die Webentwicklung – nicht mehr und nicht weniger. Und ehrlich gesagt sind C# und VB.NET zwar hervorragende Sprachen, um Programmbibliotheken mit einer grafischen Benutzeroberfläche zu verknüpfen, aber für das Schreiben solcher Bibliotheken, also komplexer Logik, sind sie nicht besonders gut geeignet.