Der Grund warum ich auf .NET verzichten möchte ist wie genannt, dass ich Multi-Platform Lösungen bringen will und ohne das .NET Framework auskommen will. Aber .NET ist schon eine tolle Sache, aber ich mag „vorgebasteltes“ Zeug nicht so ^^ Wenn möglich, alles selber schreiben. ^^
So war ich auch mal drauf. Das Nennt sich "Not invented here"-Syndrom und hat einige Nachteile:
1.) Du investierst viel Zeit damit, Infrastruktur-Code zu schreiben, den jemand anderes schonmal geschrieben hat.
2.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
3.) Du verbringst viel Zeit damit, Dich in problemfremde Domänen (Logging, Datenbankzugriff um nur zwei zu nennen) einzuarbeiten um Deinen Infrastruktur-Code überhaupt schreiben zu können.
4.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
5.) Ausnahmslos jeder Entwickler macht Fehler und produziert Bugs. Am Anfang mehr und trivialere, später weniger, aber dafür schwerer zu findende. Je mehr Code Du schreibst, desto mehr Bugs sind da drin. Du verbringst also einen Großteil Deiner Zeit damit, Bugs im Code für Logging und im Datenbankzugriff (nur um mal zwei zu nennen) zu suchen und zu fixe.
6.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
7.) Der Infrastruktur-Code, der Dein Projekt seinem Ziel nicht näher bringt, ist da. Also muss er gewartet werden.
8.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
Letzendlich wirst Du, wenn das wirklich so versuchst, Dein Projekt nie zuende bringen weil Du immer erst nötigen Kleinkram schreiben musst bevor Du Dich um die eigentliche Aufgabe kümmern kannst.
Das kannst Du mir jetzt einfach glauben, oder Du wirst diese Erfahrung selber machen. Letzteres wird teuer (Zeit ist Geld, verlorene Zeit rausgeworfenes Geld).
Andere Leute haben viel Zeit in diese Probleme investiert. Die meisten Lösungen gibt es als Open-Source Komponenten die Du einfach reinziehen kannst. Insbesondere im Java- und im .NET Bereich gibt es hier eigentlich *alles* schon fertig. Sogar mit
Unit-Tests. Du kannst Dich also auch davon überzeugen das das Zeug zuverlässig funktioniert.
Schau Dir mal (selbst kommerzielle) Delphi-Komponenten an. Wie viele von denen kommen zusammen mit
Unit-Tests?
Zudem: Technologisch ist C# lediglich eine Weiterentwicklung von Delphi. Das, was in Delphi
run-time Packages sind, ist das .NET Framework. Die Assembler-Optimierungen, die vorhin mal angesprochen wurden und die Du so cool fandest, finden bei .NET durch das Framework statt. Du kannst niemals bei einer statischen Kompilierung auf das konkrete Zielsystem optimieren, sondern Du kannst nur allgemein pro CPU-Typ optimieren. Mit zig ifdefs. Bei .NET / Mono übernimmt das der Compiler der aus Deinem
IL-Code Plattformspezifischen Code bastelt. Und der wird regelmäßig von Leuten optimiert, die davon Ahnung haben und die das Hauptberuflich machen. Glaubst Du, Du kannst neben dem eigentlichen Programmieren in Deiner Problemdomäne auch noch CPU-spezifische Optimierungen auf Assembler-Ebene so gut lernen, dass Du es wirklich beherrschst? Und falls ja: Warum machst Du das dann nicht zu Deinem Hauptjob? Solche Leute werden *sehr* gut bezahlt. Okay, das mag jetzt etwas kätzerisch klingen, aber Grundsätzlich läuft es darauf hinaus:
Nutze das, was Dir geschenkt wird, und kümmere Dich nicht um Probleme am Strassenrand für die es schon Lösungen gibt. Sie führen Dich nur von Deinem Weg ab.
Das was ich da geschrieben habe trifft Grundsätzlich zu. Es gibt Ausnahmen. Und die sind vermutlich für Dich sogar im Moment relevant: Solchen Infrastruktur-Code zu schreiben, dabei Fehler zu machen, diese Fehler zu verstehen und zu korrigieren, ist ein wichtiger Teil des Lernprozesses eines Entwicklers. Diese Fehler darfst Du aber in Deiner Ausbildung machen - bezahlt von Deinem Arbeitgeber. Du solltest das Risiko und die Kosten solcher Fehler nicht in Bereichen eingehen, in die Du persönlich kommerziell investierst.
Cross-Platform als Argument gegen .NET aufzuführen wirkt im übrigen eher uninformiert. Wenn Du Cross-Platform bauen magst, ist Mono definitiv das richtige Werkzeug. Wenn Du Mobile Anwendungen schreiben willst, schau Dir Xamarin an. Sehr viele sehr erfolgreicher Anwendungen für iOS, Android und Windows Phone sind damit geschrieben. Viele Mac-Anwendungen sind mit Xamarin geschrieben (und das funktionier hervorragend). Und - nativ ist das auch noch. Xamarin bzw. auch die
OS-X Toolchain für Mono kann
IL mit den verwendeten Framework-Klassen in ein natives Kompilat herunterkompilieren. Du brauchst keine Runtime auf dem System. Das ist genauso wie bei Delphi, wo die Runtime-Umgebung und die Komponenten (
RTL,
VCL) auch direkt einkompiliert werden.
Und um nochmal auf die Verwandschaft von Delphi und C# zurück zu kommen:
Delphi ist inzwischen leider technologisch ein massiver Rückschritt von Delphi. Wenn man die Konzepte hinter LINQ (z.B. Expression Trees) einmal richtig kapiert hat, wird die Sprache als Werkzeug sehr elegant einsetzen können und selbst komplexe Aufgaben sehr einfach und verständlich lösen können. Delphi mangelt es da massiv an modernen Sprachkonstrukten. Du würdest also dort auch noch viel Zeit damit verbringen, um dich um unzulänglichen in der Sprache herumzuprogrammieren, während Du das in C# direkt nutzen könntest. Noch so ein Zeitfresser.
Die Qualitätsprobleme der Delphi-
IDE wurde ja hier schon erwähnt (Error Insight, falsche Unterstrichelungen in der
IDE, sehr beschränkte Refaktoring-Optionen). Im VS wirst Du solche Probleme nicht finden (dazu investiert Microsoft zu viel in die QS-Abteilung als das Embarcadero es jemals wirtschaftlich sinnvoll könnte - das merkt man aber leider am anderen Ende). Und für's VS findest Du zusätzlich noch geniale Helferlein (ich sage nur ReSharper), die einem das Leben nochmal massiv einfacher machen und die Produktivität stark steigern.
Letzlich ist es also auch eine Frage der Effizienz - und die ist mit C# im VS einfach deutlich höher als mit Delphi. Insbesondere dann, wenn Du C# schon kannst. Sonst kommen natürlich immer noch die Umlern-Aufwände dazu, die einen Anfangs ausbremsen, (was immer auch gerne als Argument "gegen X" genannt wird) aber auch die sind nur einmalig da und hinterher schneller wieder aufgeholt als man nachrechnen könnte.