Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:
Heute, am 1. August 2009, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:
C# oder VB: Welche Sprache soll ich lernen?
So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Außerdem nimmt diesen Monat auch Christian Wenz an unserem Streitgespräch teil.
Peters und Christians Kommentare finden sich zeitgleich in den entsprechenden Blogs, folgend nun mein Kommentar zu diesem Thema:
Die Frage, ob C# oder Visual Basic die bessere Sprache ist, kann pauschal wohl kaum beantwortet werden. Wie so oft hängt die Antwort vom konkreten Kontext ab, in dem die Frage gestellt wird.
Zudem ist man zunächst geneigt, C# und Visual Basic als zwei syntaktische Varianten einer gemeinsamen Sprache zu sehen – und wenn man MSIL als diese Sprache nimmt, ist diese Sichtweise aus rein technischer Sicht auch gar nicht so abwegig.
Es gibt nur wenige Sprachfeatures, auf Grund deren man C# über Visual Basic oder umgekehrt Visual Basic über C# favorisieren könnte: Eines davon könnte die integrierte Unterstützung von XML in Visual Basic sein.
Ob ein derart einzelnes Feature jedoch genügt, um eine Sprache als Grundlage für ein gesamtes Projekt auszuwählen, sei noch einmal dahin gestellt.
Auch die historische Entwicklung, die beispielsweise in Not Another C# Versus VB Article auf CodeProject beschrieben wird, ist nur bedingt geeignet, eine Entscheidung zu fällen: Denn Historie ist für all jene irrelevant, die sich erstmalig mit Programmierung beschäftigen.
Werde ich nach meiner persönlichen Empfehlung gefragt, so rate ich fast durchwegs immer zu C# – jedoch bin ich auf Grund von Projekten wie guide to C# auch nicht unbelastet. zudem fehlt mir die Erfahrung in Visual Basic.
Was also empfehlen, wenn man zumindest ein wenig Objektivität wahren möchte?
Als die Entwicklung für Windows noch nicht auf .NET, sondern auf der Win32-API basierte, gab es für die Frage, ob Visual C++ oder Visual Basic Classic eingesetzt werden sollte, eine relativ einfach anwendbare Richtlinie: Professionelle Entwickler sollten Visual C++ einsetzen, alle anderen Visual Basic Classic:
- Visual C++ hatte für professionelle Entwickler einige entscheidende Vorteile: So war nicht nur der Zugriff auf die gesamte Win32-API möglich, auch die Integration in COM war erstklassig. Diese Vorteile erkaufte man sich mit einer ausgesprochen komplexen Entwicklung.
- Visual Basic Classic hingegen war einfach zu erlernen und einfach anzuwenden. Zwar gab es Grenzen, diese spielten jedoch abseits der professionellen Entwicklung nur selten eine entscheidende Rolle.
Nun haben so wohl Visual C++ wie auch Visual Basic Classic ihren Einfluss verloren und C# und Visual Basic sind die neuen Sterne am Programmiersprachenhimmel. Die spannende Frage lautet nun: Gilt die damalige Rollenverteilung nach wie vor?
Ich meine: Ja, sie gilt nach wie vor. C# ist besser geeignet für professionelle Entwickler, Visual Basic hingegen ist nach wie vor besser geeignet für alle anderen Entwickler. Wie komme ich zu dieser Einschätzung – wo doch so oft zu hören und zu lesen ist, dass es sich faktisch nur um zwei verschiedene syntaktische Varianten einer Sprache handelt? Dass die Entscheidung somit letztlich keine Rolle spielt? Dass es sich eigentlich nur um einen Glaubenskrieg handelt?
Der entscheidende Punkt ist, dass C# von vornherein darauf ausgelegt wurde, eine akademische Sprache zu sein. Eine Sprache, in der alle enthaltenen Sprachkonzepte und -ideen sauber umgesetzt sind. Man könnte auch sagen, C# ist die Sprache des Elfenbeinturms.
Visual Basic hingegen ist auf ein komfortables Entwicklungerlebnis ausgerichtet: Man muss nicht zwingend alle Konzepte von .NET verstehen, um erfolgreich in Visual Basic programmieren zu können – für C# ist ein gutes Verständnis von .NET essenziell.
Dieser Komfort manifestiert sich in Visual Basic in vielen Kleinigkeiten, unter anderem in den folgenden Konzepten:
- Visual Basic unterstützt nach wie vor das On Error Goto-Konstrukt, das an Stelle des wesentlich besser strukturierten try / catch eingesetzt werden kann.
- Visual Basic unterstützt optionale Parameter. Dieses Feature ist zwar nun für eine verbesserte COM-Interoperabilität auch in C# 4.0 enthalten, wird dort allerdings nicht als unproblematisch angesehen, wie beispielsweise in Für und wider C# 4.0 beschrieben.
- Visual Basic unterstützt zahlreiche der Funktionen aus Visual Basic Classic nach wie vor, indem diese in der Assembly Microsoft.VisualBasic.dll nachgebildet worden sind. Im Vergleich zu den moderneren .NET-Varianten lassen diese Funktionen allerdings einiges zu wünschen übrig – insbesondere im Hinblick auf Performance.
Nun kann man all diesen Punkten ankreiden, dass es sich nur um Kleinigkeiten handelt, die zudem aus Gründen der Abwärtskompatibilität enthalten sind. Jedoch hat Microsoft im Rahmen von Visual Studio 2005 ein komplett neues Feature eingeführt, das jedoch interessanterweise nur für Visual Basic zur Verfügung steht: Den Namensraum My.
Auch Uwe Baumann hat bereits im April 2005 mit My, ist das geil! eine Lanze für den Namensraum My gebrochen – nicht jedoch ohne die entsprechende Kritik, nachzulesen als Zitat in Die Freiheit der abweichenden Mynung:
My ist nicht geil. Nicht einmal ansatzweise. Denn My untergräbt die klare Struktur von .NET, die viele Entwickler so lieben, wie es bei PHP auch geschieht. Unter dem Motto “Alles soll einfacher werden” wird ein zusätzlicher Namensraum eingeführt, der Abkürzungen bietet. Diese aber mit eingeschränkter Funktionalität, und nicht mehr nach den klassischen Namensräumen sortiert, es wird also neben der Einführung einer zweiten Schreibweise auch noch die Beschäftigung mit den klassischen Namensräumen vermindert.
Letztlich führt das meiner Meinung nach zum gleichen Ziel wie in PHP, nämlich, dass Einsteiger sich auf My stürzen werden, dann aber irgendwann an die Grenzen stoßen oder fremden Code bearbeiten müssen, und sich dann doch mit den klassischen Strukturen auseinander setzen müssen.
Letztlich wird so wieder ein Parallelweg eingeführt, der eigentlich überflüssig ist, und am Ende die Produktivität eher senkt als steigert, da redundante Abläufe erlernt werden müssen.
In seiner Antwort referenziert Uwe auf genau jene Unterscheidung, die ich in diesem Eintrag auch getroffen habe: C# ist eine Sprache aus dem Elfenbeinturm, akademisch sauber und elegant. Visual Basic hingegen ist die Sprache für den Praktiker, der sein Ziel erreichen will – wobei ihm der Weg relativ gleich ist, und der unter Umständen auch gar kein Interesse an Weiterentwicklung hat.
Aufbauend auf meiner Argumentation und gestützt durch Uwes Antwort möchte ich daher folgendes Fazit ziehen: Wer sich professionell mit .NET beschäftigen will, wissen will, wie .NET intern funktioniert, und bereit ist, Zeit und Aufwand zu investieren, der ist mit C# besser beraten.
Wer jedoch nur gelegentlich eine kleine Anwendung zusammenbasteln will, wem das Erreichen des Ziels wichtiger ist als der dafür eingeschlagene Weg, der ist mit Visual Basic besser beraten.