Vorteile von Delphi gegenüber C#

[Medium]

Ich hab einen recht ähnlichen Übergang wie der TE quasi gerade hinter mir, wobei mir Delphi als Sprache im Job noch erhalten bleibt. Aber ich greife privat, wenn mir mal wieder eine Idee kommt oder ich mal fix ein mini Tool bräuchte, mittlerweile spontan zu #Develop statt wie noch vor ~4 Monaten zum Delphi-Icon.

Das Warum ist da schon schwieriger. Ich mag Delphi nach wie vor auch sehr gern, allerdings ist die Alleinstellung als RAD Umgebung nicht mehr gegeben. Zwar haben mich viele IDEs wie z.B. Eclipse ziemlich abgetörnt, aber mit #Develop bin ich nun doch recht im Einklang. Dieser Grund für Delphi fiel dann also schon mal weg.
Dann ist die Sache, dass ich bei D7 stehen geblieben bin, und auf Grund diverser Mängelberichte der neueren Versionen nicht bereit war Geld für ein Update in die Hand zu nehmen. Zudem bin ich im Beruf an D7 aber mehr noch Win32 gebunden. Da ich nun aber doch gerne mal in die .NET Welt schnuppern wollte, kam C# nicht ungelegen. Delphi for .NET ist irgendwie weniger eine Alternative: Den Komfort der VCL bietet mir .NET von Hause aus (und noch ein bischen mehr), weswegen der "Zwischenschritt" mir nicht mehr Gewinnbringend erscheint. Dann lieber in der "Haussprache" des Frameworks.
Dass dann auch noch Nettigkeiten wie Operatorüberladung, Generics und Delegates dazu kommen erleichtert mir auch vieles. Ebenso Structs mit Konstruktoren/Methoden. Alles Dinge bei denen Delphi nach und nach auch gleichzieht, aber eben "nach"zieht - und so manches wirkt in der Delphi Syntax auch irgendwie seltsam fremd und aufgesetzt. Das ist aber sicher nicht als faktischer Grund zum Wechsel anzusehen =)

Mal auf deine Punkte eingegangen:

• { und } statt begin und end. Dadurch, dass es nur ein Zeichen ist, nimmt es weniger Platz weg und eine Zeile in der nur "}" steht wirkt schon fast wie eine Leerzeile im Gegensatz zu einer Zeile in der ein ganzes Wort wie "end" steht. Dadurch ist keine weitere Leerzeile zur Strukturierung des Codes nötig und die Struktur springt sehr gut ins Auge.
  Ich mag begin/end ehrlich gesagt lieber. Zwei Gründe: Die Klammern sind recht spidderig, und ich übersehe gerne mal eine. Ein Wort sticht da einfach besser hervor. Zudem kann ich mich einfach nicht entscheiden, ob ich die öffnende Klammer in die Zeile des Methoden/Statement-Kopfes, oder separat darunter in eine eigene setzen soll . Das Zweite ist die grausame Art und Weise der deutschen Tastatur diese Zeichen zu produzieren. Ich vertipp mich da ständig, und bevorzugt lande ich auf den eckigen Klammern. Ich glaub um das zu lösen muss ich mich langsam an meine G15-Makros gewöhnen.
  
• Variablen/Methoden müssen nicht extra in einem gesonderten Abschnitt deklariert werden. Dadurch spart man sich Zeilen und man hat die Deklaration gleich dort stehen, wo die Variable im Code verwendet wird.
  Sehe ich ähnlich wie Luckie. Zum einen ist es nett bei Änderugnen von Methodenköpfen nicht immer die Deklaration nachhalten zu müssen, auf der anderen Seite ist das Zusammenklappen von Code auch mehr nur eine Krücke um mal einen Überblick zu erhalten. Variablendeklarationen im Block sind an sich sehr nett, und helfen beim Strukturieren. Nachteilig ist z.B. die Möglichkeit einfach mal ein paar public Member einer Klasse inmitten von Implementierungen von Methoden stecken zu können. Es gibt Leute die das tun! Und man fragt sich teils: WO zum Geier nimmt der DAS Feld nun auf ein mal her?
  
• Operatoren lassen sich überladen. Mit überladenen Operatoren kann man Code besser lesbar machen imo
  Man kann damit aber auch ganz schönen Mist verzapfen. Hilfreich wie nix ist es bei mathematischen Konstrukten wie Matrizen, man kann dieses Werkzeug aber auch ziemlich missbrauchen. In manchen Zusammenhängen mag ein "+" vielleicht möglich sein, aber keinesfalls logisch oder richtig erscheinen. Da ich nun aber viel mathematischen Krams mache, bin ich natürlich ein Fan davon. Nur gilt hier wie so oft: Zu viel des Guten...
  
• Es gibt einen Garbage Collector, man spart sich also Zeilen zum Freigeben von Objekten
  An den GC musste ich mich echt gewaltig gewöhnen! Er erleichtert vieles, aber ich hab's auch schon geschafft out-of-memory Exceptions zu erzeugen die an und für sich nicht hätten sein müssen. Mit expliziten Freigaben wäre mir das an der Stelle nicht passiert. D.h.: Ab und an lohnt es sich dennoch mal selbst Hand anzulegen. Generell aber eine feine Sache.
  
• Case-Sensitivität: Indem man Parameter und Variablen mit einem Kleinbuchstaben beginnen lässt und Typen und Methodenbezeichner mit einem Großbuchstaben, sind Präfixe wie "T" für Typen oder "F" für Felder nicht mehr nötig
  Auch als Delphi-Umsteiger sehr gewöhnungsbedürftig. Ich hab mich zwar schon immer auch in Delphi sehr bemüht eine Schreibweise für eine Variable stringent durchzuhalten, was mir die Arbeit mit C# jetzt erleichtert, aber ich muss mich noch daran gewöhnen dass man Methodenparameter (vor allem in Konstruktoren) bedenkenlos als klein-Variante der echten Feldnamen hernehmen kann, statt mit diesem "a" davor rumalbern zu müssen - oder noch schlimmeres.
  
• Die foreach-Schleife macht das Durchlaufen von z. B. Arrays ohne Laufvariable möglich
  Sehe ich als etwas an, was ich nicht gebraucht hätte. Die eine Zeile "String currentString = MyList[i];" würde mich nicht im Geringsten stören, mehr noch: Ich kann so immer bezüglich der Reihenfolge sicher sein und muss mich nicht darauf verlassen dass mir der Iterator die Werte nun so oder anders zu mir wirft. Ab und an benutze ich es, öfter aber die klassische for-Schleife. Nette Option, kein Grund für oder gegen eine Sprache.
  
• Zeichen statt Wörtern sind einfacher zu lesen, z. B. += statt Inc(), ! statt not, & statt and etc. Ganze Wörter hierfür zu benutzen wie in Delphi, ist ja fast so schlimm als würde man in Mathe "plus" schreiben statt das Zeichen + zu benutzen. Durch die Verwendung von Zeichen für Operatoren und Wörtern für Operanden heben sich diese besser voneinander ab
  Seh ich GANZ anders. Mit "+=" und Konsorten kann ich mich gut anfreunden da es oft teils recht lange Variablennamenwiederholungen spart die der Übersicht nun auch nicht so sehr weiter helfen, aber gerade das "!" als "not" empfinde ich als viel zu unauffällig. Wie oft ich nun schon dran verzweifelt bin warum dies oder jenes irgendwie nie richtig zu klappen scheint, und dann war einfach nur die Bedingung falsch herum gestellt... "&&" und "||" sind im Rahmen, ich schreibe und lese aber lieber "and" und "or".

Zitat:

Ich vermute aber, dass es genauso gut andersrum Vorteile von Delphi gegenüber C# gibt. Welche sind diese?

Von meinen o.g. (persönlichen) kleineren Kritikpunkten an der C Syntax abgesehen, sehe ich so für sich genommen erstmal keinen größeren Vorteil für Delphi an und für sich. Der kommt dann aber in Form von zusätzlichen Komponenten die es mittlerweile für Delphi gibt, auf die wir z.B. auf der Arbeit sehr stark aufbauen. Vergleichbares gibt es für C# (noch) nicht, und man müsste es halt auch wieder einkaufen. Oh wobei: Ich muss zugeben noch immer bedingungsloser Fan des Formulareditors von D7 zu sein! Schnell, recht stabil selbst übelsten Hacks in Komponenten gegenüber (ei was hab ich da schon gezaubert ^^) und von der Aufteilung her einfach genial. Wenn es ginge, würd ich den sofort mit nach #Develop mitnehmen.
Tja, und dann gibt's da noch diese geniale Internet-Community. Sowas fehlt mir bei C# absolut, weswegen ich dann doch auch noch ab und an mal mit "sprachfremden" Threads hier aufwarten muss