Vorteile von Delphi gegenüber C#

[Cöster]

Hi!

Ich habe vor kurzem angefangen C# zu lernen. Bis dahin war Delphi die einzige Programmiersprache, die ich einigermaßen konnte. Viele Sachen sind sehr ähnlich bei C#, aber die Sachen, die anders sind, gefallen mir meistens besser in C#. Deswegen frage ich mich, jetzt, was Delphi eigentlich für Vorteile hat gegenüber C# (ausgenommen der Tatsache, dass es so ein wunderbares Forum wie dieses nur für Delphi gibt). Sicherlich ist Delphi vielleicht aufgrund der stärkeren Ähnlichkeit zur englischen Sprache einfacher zu lernen, wenn man vorher noch überhaupt keine Programmiererfahrung hat. Aber ansonsten find ich bei C# nur Vorteile:

• { 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.
• 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.
• Operatoren lassen sich überladen. Mit überladenen Operatoren kann man Code besser lesbar machen imo
• Es gibt einen Garbage Collector, man spart sich also Zeilen zum Freigeben von Objekten
• 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
• Die foreach-Schleife macht das Durchlaufen von z. B. Arrays ohne Laufvariable möglich
• 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

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

[Hansa]

Mit Verlaub gesagt : Deine Aufzählung listet für mich so ziemlich alles auf, was an C eventuell schlechter ist, als in Delphi. Du bist allerdings hier in der Delphi-Praxis und nicht in der C-Praxis. Auf der anderen Seite dorfte es auch nicht schwer sein, hier Leute zu finden, die schon einige User zu C# gebracht haben und sich hier nicht mehr blicken lassen. 8) In Richtung Teppich benutzen die Ratgeber aber offensichtlich doch lieber Delphi-Prism, statt C#. Warum (Recht haben sie schon, aber leider sind Delphi-User weg) ?

mich stört z.B. das hier :

Zitat von Cöster:

! statt not..

Ein Ausrufezeichen ! bedeutet im allgemeinen Sprachgebrauch eine besondere Betonung. Insofern würde != "besonders gleich" heißen. Unlogik in C und das ist erst der Anfang.

{} ist vielleicht gut, wenn man weiß, was das heißt, aber selbsterklärend ist das lange nicht. All das sieht man überall bei den C-Sprachen. PHP geht in ähnliche Richtung. Unlogisch und für eigene Programme gefährlich. 8)

[Cöster]

Dies soll hier keine Werbekampagne für eine andere Sprache sein, auch wenn es vll unweigerlich den Effekt haben mag.

Was du zum Thema selbsterklärend sagst ist richtig, deswegen ist Delphi wohl auch als Einsteigerprogrammiersprache besser geeignet, wie ich auch im ersten Post schon meinte:

Zitat:

Sicherlich ist Delphi vielleicht aufgrund der stärkeren Ähnlichkeit zur englischen Sprache einfacher zu lernen, wenn man vorher noch überhaupt keine Programmiererfahrung hat.

Die Tatsache, dass !, { und } im Gegensatz zu "not", "begin" und "end" nicht selbsterklärend sind, ist meiner Meinung nach nur ein Problem innerhalb der ersten paar Stunden oder Tagen, die man sich an eine neue Sprache gewöhnt. Danach wird sich dadurch sicherlich kein Programmierer mehr verwirren lassen.

[mleyen]

Also vorab:
Ich hab mit Java angefangen, dann eine Weile c++ programmiert, dann C# und bin dann erst auf Delphi gestoßen.

Zitat von Cöster:

• { 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 persönlich finde begin und end; viel übersichtlicher als diese kleinen Klammern.
Zusätzlich regen diese 'Mehrzeichen' dazu an, seinen Code weiter aufzusplitten, heißt in neue Methoden auszulagern.
(Weiterhin bekomm ich immer Fingerkrämpfe mit der Tastenkombination davon. [AltGr+7/0])

Zitat von Cöster:

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

Das ist der nächste Punkt, den ich an Delphi so klasse finde. Man muss nicht immer die Methoden suchen und hat alles übersichtlich im interface-Teil. (Ziemlich praktisch um sich schnell in fremden Code einzuarbeiten, ohne auch nur eine Deklaration gesehen zu haben)
Man kann auch nicht an jeder x-Beliebigen stelle einfach wahrlos Variablen deklarieren.
In Delphi hat man alle Variablen übersichtlich vor dem ersten begin.

Zitat von Cöster:

• Operatoren lassen sich überladen. Mit überladenen Operatoren kann man Code besser lesbar machen imo

Records können Operatoren überladen und dazu wurde hier (ich glaub Himitsu war´s) mal vorgestellt wie man Records genau wie Objekte handhaben kann.
Ich persönlich brauche soetwas bei großen Objekten eigentlich nie. Gerade, da ich meißt später nichtmal mehr wusste, was die Op.-Überladung überhaupt macht. Da schreib ich mir lieber eine kleine Methode ala 'add()'.

Zitat von Cöster:

• Es gibt einen Garbage Collector, man spart sich also Zeilen zum Freigeben von Objekten

Das mag natürlich stimmen. Verringerung der Programmierzeit im austausch gegen Overhead und Performanceverluste. (Wobei ich das nur gelesen habe)

Zitat von Cöster:

• 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

Das ist denke ich mal Geschmackssache. Ich kann gleichnamigen Variablen / Methoden etc nichts abgewinnen, da ich es für unsauberen Code halte. Wer so große Objekte/Units hat, dass er sich selbst nicht mehr zurecht findet, der sollte nicht auf die Bezeichnung von Variablen /- Methodenbezeichner gehn, sondern versuchen etwas gut auszulagern / zu abstrahieren.

Zitat von Cöster:

• Die foreach-Schleife macht das Durchlaufen von z. B. Arrays ohne Laufvariable möglich

Jup, das ist ein nettes feature. Ich wurde eines besseren belehrt. Das gibts doch in Delphi. *yippie*

Zitat von Cöster:

• 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

Und da ist sie wieder: Die Geschmackssache.
Die einen finden cryptischen Code übersichtlich, die anderen nutzen lieber genau definierbare Bezeichner...
Imho verleitet Delphi da wieder zum 'sauberem Programmierstiel'.

Edit´s:
- Korrektur nächtlicher Rechtschreibfehler
- foreach-Schleife in Delphi?

[Luckie]

Zitat von Cöster:

{ 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.

Reine Geschmacksache. Man gewöhnt sich an beides.

Zitat:

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.

Das finde ich gerade gut. Dadurch, dass alles im Interfaceteil deklariert ist hat man einen sehr schönen überblick über die Klasse. Bei C# brauche ich entweder ein IDE-Feature oder ich muss durch den ganzen Quellcode scrollen. Auf der anderen Seite würde ich mir in Delphi auch mancmal wünschen Variablen direkt im Quelltext deklarieren zu können, um ihre Sichtbarkeit so weit wie möglich einschräbnken zu können.

Zitat:

Operatoren lassen sich überladen. Mit überladenen Operatoren kann man Code besser lesbar machen imo

Habe ich keine Erfahrung mit.

Zitat:

Es gibt einen Garbage Collector, man spart sich also Zeilen zum Freigeben von Objekten

Also das Zeilen sparen ist wohl eine ziemlich doofe Begündung. Eine garbage Collection hat Vorteile, aber auch Nachteile. Ein Vorteil iunteranderem ist, dass man sich keine Speicherlecks einhandelt. Auf der anderen Seite kann sie aber auch dazu verleiten schlampig zu programmieren. Bin ich selber für den Speicher verantworlich, habe ich eine größere Kontrolle, muss aber auch sorgfälltiger arbeiten.

Zitat:

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 wieder reine Geschmackssache.

Zitat:

Die foreach-Schleife macht das Durchlaufen von z. B. Arrays ohne Laufvariable möglich

Gibt es mittlerweile auch in Delphi.

Zitat:

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

Auch wieder reine Geschmackssache. Aber findest du das gut:

Code:

for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

Ok, das ist jetzt C, aber mit C# wahrscheinlich auch möglich.

Zitat:

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

Pascal wurde ursprünglich als Lehrsprache entwurfen und das sieht man dem heutigen Delphi auch noch an. Und ich finde gerade durch diese nicht kryptischen Zeichen, sondern die Verwendung von ganzen Wörtern (begin, end, Inc, ...) finde ich sie leicht zu lernen. Man schreibt, was man spricht. Das fängt schon bei nicht mathematisch korrekten verwendung des Gleichzeichens unter C+ an:
In C# entspricht ein Gleichzeichen einer Zuweisung. Das ist mathematisch falsch. Denn:

Code:

i = i + 1

ist mathematisch falsch. Die linke Seite ist eben nicht gleich der rechten Seite. Da ist die Pascal Lösung mit dem ":=" besser. Mathematisch korrekt wäre ein Pfeil, der lässt sich aber schlecht darstellen. Das mit dem Austrufezeiuchen hat ja Hansa schon erwähnt.

[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

[jaenicke]

Dazu wurde zwar auch schon etwas gesagt, aber noch etwas:

Zitat von Cöster:

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.

Man kann in Delphi ja z.B. einfach schreiben var TAB, dann Variablenname TAB Variablentyp, zack, steht das über dem begin der aktuellen Methode. Geht natürlich erst ab Delphi 2006 / Turbo Delphi oder so.

Dass man in C# zwischendurch Variablen deklarieren kann, hat Vor- und Nachteile. Nachteile vor allem bei der Lesbarkeit. Und wenn man sich daran hält, dass einzelne Methoden / Routinen nicht zu lang sein sollten, ist ohnehin nicht viel Quelltext zwischen Deklaration und Verwendung...

Zitat von Cöster:

Operatoren lassen sich überladen. Mit überladenen Operatoren kann man Code besser lesbar machen imo
Die foreach-Schleife macht das Durchlaufen von z. B. Arrays ohne Laufvariable möglich

Geht beides wie auch schon gesagt wurde auch in Delphi. Und das schon ab Delphi 2006 / Turbo Delphi. In der Version und den folgenden wurden (wie auch in der IDE) viele Erweiterungen in der Sprache eingebaut.

Grundsätzlich hat C# als Sprache durchaus einige Vorteile, insbesondere mit Linq und anderen Features des .NET Framework. Dafür finde ich das Visual Studio als Oberfläche deutlich schlechter als die Delphi IDE von D2006 und höher (ok, besser als die alte von D7 oder die von #Develop ist das Visual Studio schon sehr).
Was die Sprache angeht, so hat das auch schon genannte Delphi Prism da auch sehr viele interessante Features. Das ist auf jeden Fall einen Blick wert.

[Medium]

Achso! Was mir nun auch schon an so manchen stellen etwas "Gehampel" erspart hat ist die Möglichkeit soetwas zu tun:

Code:

int z;
if ((z=new Bitmap(FileName).Width) > 0)
{
// mach was, was vom z abhängt
}

Etwas holpriges Beispiel, aber das ist gerade in Schleifen brauchbar, da man direkt in der Bedingung den gesuchten Wert festhalten kann, und nicht nachher entweder nochmals danach suchen, oder ihn sich vorher spearat sichern muss. Sicherlich kann man das mit 1 Zeile mehr auch lösen, aber ich finde das ausgeprochen elegant. Vermuthstropfen ist, dass man die eigentliche Deklaration "int z;" nicht wie bei for-Schleifen in der Bedingung setzen kann. Daher ist es auch eher in Schleifen zuhaus. Das ist aber wieder persönlicher Geschmack. Manch einen mag sowas evtl. auch stören, auch eine völlig gleichwertige Meinung.

[Matze]

Bei den for-Schleifen finde ich es in C# bzw. C und C++ etc. pp. ebenfalls viel angenehmer, die Variable im Schleifenkopf zu deklarieren. Die Bedeutung ist klar und in Delphi sollten diese Laufvariablen auch nicht außerhalb der Schleife eh genutzt werden (sonst wird's richtig unübersichtlich).

Code:

for (int i = 1; i < 10; i++)
{
    // ...
}

Aber ansonsten finde ich die Deklarationen in Delphi viel ordentlicher. Man findet sich schnell in fremdem Code zurecht und auch nach Monaten noch im eigenen. Was ich in C++ schon Variablen gesucht habe ...

Aber das gilt, wie erwähnt, genauso für C++ und Konsorten. Also ein Vorteil von C# ist das daher nicht direkt. Die Syntax ist bei vielen Sprachen sehr ähnlich zu C#. Was die Syntax betrifft gewöhnt man sich an alles.
Im englischen Tastaturlayout erreicht man die geschweiften Klammern übrigens einfacher.

Aber von der Syntax ist es, wie man hier gut sieht, reine Geschmackssache. Ich komme mit beidem gut zurecht.

[jfheins]

Also zu den geweiften Klammern:
Man kann sie auch über (strg)+(alt)+7 eingeben - dann braucht man die eine Hand nicht so zu verrenken

Ansonsten mag ich eigentlich C# lieber