Vorteile von Delphi gegenüber C#

[himitsu]

Zitat:

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

soeine klammer übersieht man aber auch mal schnell, vorallem da Viele dazu neigen auch mal mehrere ineine Zeile machen

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.

genau das finde ich, bescheiden gesagt, Schwachsinn, denn so übesieht man mal eine Variable und man hat absolut keinen Überblick darüber, welche Variablen es in einer Funktion überhaupt gibt.

Zitat:

Zitat von mleyen

Zitat:

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()'.

joar :angel2:

geht also in Delphi ja auch (auch wenn "noch" nicht direkt mit Objekten)

Zitat:

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

Zeit spart man absolut keine, denn Freigegeben müssen sie so oder so werden.
Und ich hab lieber selbst die Kontrolle über den Speicher, denn so weiß ich was wo für Speicher exisiert oder eben nicht.

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

toll, da verließt man sich mal oder verschreibt sich und schon passiert sonstwas, aber nicht das, was soll

und ich kann mir ein Zeichen mehr besser/leichter merken, als wenn ich mir jetzt auch noch zusätzlich die komplette Groß-/Kleinschreibung aller Zeichen merken muß.

Zitat:

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

du mußt aber dennoch eine Variable nutzen, egal ob/wo due sie definiert hast

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

Operatoren sind doch Zeichen?

OK, sowas wie += gibt es nicht, aber die Compileroptimierung mach intern auch mal sowas draus.



und ich finde = und == voll krank umgesetzt, bzw. mag die strickteren Regeln in Delphi irgendwie mehr,
denn so werden Fehler schneller und einfacher schon direkt durch den Compiler aufgedeckt und müssen nicht erst mühsam erdebuggt werden.

hab mal ewig nach einem if (a = 1) gesucht (== war gemeint)


[add]

Zitat:

Zitat von Luckie

Aber findest du das gut:

Code:

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

:mrgreen:

genau, also wer da jetzt wirklich schnell durchsieht und rausbekommt, was da überhaupt passiert, muß schon fast ein Genie oder ein Hellseher sein.

[SirThornberry]

Zitat:

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

Das ist etwas was mir überhaupt nicht gefällt. Ich will als Programmierer selbst bestimmen wann etwas frei gegeben wird und wann es gehalten werden soll und möchte da nicht von irgendwas bevormundet werden.
Ein weiterer Nachteil ist das wenn man fremden Code list. Ohne diesen Garbage Collector kann ich ganz klar im Code sehen "hier wird was freigegeben und wird somit später nicht mehr verwendet". Wenn das fehlt bleibt einem nur übrig den ganzen restlichen Code anzuschauen ob es noch irgendwo verwendet wird.

Auf Arbeit arbeite ich derzeit ausschließlich mit C und finde es für den ersten Augenblick angenehmer als Delphi da man mit ziemlich wenig Zeichen (Code) recht viel anstellen kann.
Wenn man sich dedoch in den Code von Anderen einarbeiten muss oder seinen eigenen nach einiger Zeit wieder anschaut sieht man das Delphi da einige Vorteile hat weil es einen zu übersichtlichem Code zwingt.

[jaenicke]

Das stimmt natürlich und sehe ich genauso, aber gibt es in Visual Studio nicht auch eine Funktion wie in Delphi mit Strg + Shift + Enter um alle Verwendungsorte zu finden? (Ich habe dort nie drauf geachtet.)

Was die Übersichtlichkeit angeht: C#-Code kann schon auch sehr übersichtlich sein. Meistens machen die Programmierer von wirklich sehr unübersichtlichem Code z.B. den Fehler sehr lange Funktionen zu schreiben oder ähnliches. Dann ist der Code aber auch in Delphi schwer lesbar. Solange man die Codeteile kurz hält, modularisiert und sprechende Bezeichner wählt hatte ich bisher weder in C# noch in Delphi Probleme mit der Lesbarkeit von fremdem Code.

[Cöster]

Zitat:

Zitat von mleyen

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.

Was ist so schlecht daran, Programmteile in Methoden auszulagern? Ich ging davon aus, das sei etwas Gutes.

Zitat:

Zitat von mleyen

Man kann auch nicht an jeder x-Beliebigen stelle einfach wahrlos Variablen deklarieren.
In Delphi hat man alle Variablen übersichtlich vor dem ersten begin.

Warum willst du denn vor dem ersten begin schon wissen, dass es in der Methode eine Laufvariable gibt, die in dritter Verschachtelungstiefe (oder doch woanders? das weißt du ja nicht) an nur einer Stelle benutzt wird? So lange du sowieso noch nicht weißt wann und wofür sie verwendet werden, ist das Wissen von deren Existenz doch auch nur unnötige Information für dich.
Außerdem gelten in Delphi Variablen immer für eine ganze Methode. In C# gelten sie nur für den begin-end-Block, in dem sie deklariert worden sind.

Zitat:

Zitat von mleyen

Records können Operatoren überladen und dazu wurde hier (ich glaub Himitsu war´s) mal vorgestellt wie man Records genau wie Objekte handhaben kann.

Hast du nen Link dazu?

Zitat:

Zitat von mleyen

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()'.

Und wieso weißt du bei der Methode "add()" eher, was sie macht, als bei dem Operator "+"?

Zitat:

Zitat von mleyen

Zitat:

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.

Sie sind ja nicht gleichnamig, da sie sich eindeutig durch Groß- und Kleinschreibung unterscheiden. Das zwingt auch dazu, sauber zu programmieren, also die Variable nicht an einer Stelle groß und woanders aus Faulheit klein zu schreiben.

Zitat:

Zitat von mleyen

Zitat:

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

Fändest du auch "Zwei plus vier gleich sechs" besser lesbar als "2 + 4 = 6"? Wenn du an die erste der beiden Schreibweisen gewöhnt wärest, würdest du das vermutlich als übersichtlicher bezeichnen. Wir werden hier aber vermutlich alle für die cryptische Schreibweise stimmen (oder nicht?), wieso dann also nicht auch bei Operatoren im Code? Die Gewöhnung an das imo Unlesbarere mal außen vorgelassen, kann ich nicht nachvollziehen, wie man das bevorzugen kann.

Zitat:

Zitat von Luckie

Dadurch, dass alles im Interfaceteil deklariert ist hat man einen sehr schönen überblick über die Klasse.

Nagut, das möchte ich dann meinetwegen als ein gutes Argument anerkennen :-D

Zitat:

Zitat von Luckie

Also das Zeilen sparen ist wohl eine ziemlich doofe Begündung.

Warum? Jede zusätzliche Zeile, die nicht zum Verständnis der Programmlogik nötig ist, macht den Code doch nur unübersichtlicher.

Zitat:

Zitat von Luckie

Aber findest du das gut:

Code:

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

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

Hehe, nein, das finde ich nicht gut. Ich versteh aber auch nicht wirklich, was es bedeuten soll. Was wäre denn die Delhpi-Übersetzung davon? Das Problem daran ist meiner Meinung nach aber nicht, die Verwendung von Zeichen, sondern die Anzahl der Vorgänge, die in einer Zeile zusammengefasst sind.

Zitat:

Zitat von Medium

Die Klammern sind recht spidderig, und ich übersehe gerne mal eine. Ein Wort sticht da einfach besser hervor.

Genau das halte ich für ein Problem von Delphi: Ausgeschriebene Wörter stechen zu stark hervor und je mehr diese hervorstechen, desto weniger sticht der Rest des Codes hervor.

Zitat:

Zitat von himitsu

Und ich hab lieber selbst die Kontrolle über den Speicher, denn so weiß ich was wo für Speicher exisiert oder eben nicht.

Diese Kontrolle kann man auch trotz Garbage Collector haben, denn Instanzen lassen sich trotzdem noch manuell freibeben, wenn es denn erwünscht ist.

Zitat:

Zitat von himitsu

Operatoren sind doch Zeichen?

Einige, wie +, -, *, / sind es. Andere, wie not, and, xor, or, div, mod sind in Delphi allerdings Wörter.

[Apollonius]

Zitat:

Zitat von Cöster

Zitat:

Zitat von Luckie

Aber findest du das gut:

Code:

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

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

Hehe, nein, das finde ich nicht gut. Ich versteh aber auch nicht wirklich, was es bedeuten soll. Was wäre denn die Delhpi-Übersetzung davon? Das Problem daran ist meiner Meinung nach aber nicht, die Verwendung von Zeichen, sondern die Anzahl der Vorgänge, die in einer Zeile zusammengefasst sind.

Ist das so besser? :mrgreen:

Code:

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

Ich könnte mich daran sogar gewöhnen.

Zitat:

Zitat von Cöster

Zitat:

Zitat von himitsu

Und ich hab lieber selbst die Kontrolle über den Speicher, denn so weiß ich was wo für Speicher exisiert oder eben nicht.

Diese Kontrolle kann man auch trotz Garbage Collector haben, denn Instanzen lassen sich trotzdem noch manuell freibeben, wenn es denn erwünscht ist.

Nein, das geht nicht. Du kannst vielleicht IDisposable.Dispose aufrufen, aber der Speicher wird davon nicht freigegeben.

Mir persönlich ist es ziemlich gleich, ob ich eine Sprache mit C-Stil ({}) oder Pascal-Stil (Schlüsselwörter ohne Ende) verwende. Garbage Collector oder nicht ist mir ehrlich gesagt auch nicht übermäßig wichtig - eine Managed Umgebung ohne GC geht einfach nicht, weil manuelles Freigeben von Objekten nie verifizierbar sein kann (sonst könnte man ungültige Objektzeiger nach dem Freigeben noch verwenden). Eine native Umgebung mit GC fände ich aber auch krank.

Enorm cool finde ich an C# übrigens den ternären Operator ?: und sowie den Operator ??, außerdem natürlich LINQ.

[himitsu]

Zitat:

Zitat von Cöster

Hast du nen Link dazu?

das Ganze ist/war zwar nur eine Versuchsstudie, ob und wie sowas möglich ist

und im Grunde ist es genau andersrum,
also dort werden Objekte in Records gekapselt und bekommen so virtuell die Operatoren auch mit ab
> DP-Suche
> Nach Begriffen suchen: "Operatoren"
> Nach Autor suchen: "himitsu"
= http://www.delphipraxis.net/internal...t.php?t=151373

Zitat:

Zitat von Cöster

Einige, wie +, -, *, / sind es. Andere, wie not, and, xor, or, div, mod sind in Delphi allerdings Wörter.

OK, aber dafür muß ich dann ständig überlegen was nun was war, wobei ich es so ja gleich erkenne, aber das ist wohl auch nur 'ne Gewöhnungs-/Gedächtnissache ... *langsam alt werd*

[hanspeter]

Es gibt noch kaum noch Vorteile von Delphi gegenüber C# und auch kein Alleinstellungsmerkmal.
Die Entwicklung hat halt zu lange stagniert.
Alles was sprachspezifisch aufgezählt wurde, ist mehr oder weniger Gewöhnungssache.
Das Argument, das es für Delphi eine große Komponentensammlung gibt (Torry) stimmt nur noch teilweise.
Seit D2009 ist ein Großteil dieser Componentensammlung nicht mehr einsetzbar, da bei D7 stehengeblieben.
Die Delphi-Superpage ist bereits seit Jahren tod.
Man darf nicht übersehen das C# und Net aus den Erfahrungen der Delphi-Entwicklung entstanden sind.
Der Mannpower ist bei Net und MS sicherlich um Größenordnungen höher als bei CG. Damit wird sich der Inovationszuwachs
auf der Net Seite konzentrieren.
Wir sind über ASP.Net zu C# gekommen.
Vor einem halben Jahr haben wir noch kleine Tools in Delphi gefertigt. Heute in C# genau so schnell.
Delphi selbst werden wir aufgrund riesiger Altlasten noch eine Weile einsetzen, das aber auf Basis von D7.
Inzwischen sind die letzten WIN98 Maschinen rausgeflogen, so daß wir durchgehend auf XP aufwärts setzen können.
Hier ein ganzes Framework ungenutzt liegen lassen, zugunsten der VCL ?
Vorteile für Net sehe ich weniger im Sprachbereich, sondern eher in der Umgebung.
Gemanagter Code (im Serverbereich), das Assemblykonzept..
Etwas bedenklich stimmt mich die Zukunft des Delphi-Compilers.
Es mehren sich die Anzeigen, dass dieser in der Wartbarkeit und Erweiterung an den Grenzen angelangt ist (Standard C).
Ein neuer Compiler wird bis zur Stabilität Jahre brauchen.

Gruß
Peter

[sniper_w]

Zitat:

Vorteile für Net sehe ich weniger im Sprachbereich, sondern eher in der Umgebung.

Dem kann ich erfahrungsgemäss nur zustimmen.
Denn all die Sprachunterschhide die aufgezäht sind, kann man als eine reine Geschmachsache betrachten. Mehr ist es auch vielleicht nicht.

[jaenicke]

Zitat:

Zitat von hanspeter

Etwas bedenklich stimmt mich die Zukunft des Delphi-Compilers.
Es mehren sich die Anzeigen, dass dieser in der Wartbarkeit und Erweiterung an den Grenzen angelangt ist (Standard C).
Ein neuer Compiler wird bis zur Stabilität Jahre brauchen.

Es wird schon seit einiger zeit ein neuer Compiler entwickelt...
Dieser ist in Frontend und Backend aufgeteilt, so dass das Frontend den Code liest und an das jeweilige Backend weitergibt. Dieses erzeugt dann 32-Bit oder 64-Bit Code oder auch Code für Mac OS oder Linux. Die Anfänge davon wurden ja bereits vorgestellt.

Und nativ für Mac OS oder Linux kompilieren wird mit C# nie möglich sein, da braucht man dann Mono usw., wenn man dort die Programme ausführen möchte. Nicht dass ich C# schlecht finde, ich nutze es ja selbst, aber Delphi wird schon noch mehr Vorteile bekommen in den nächsten Versionen. Und die IDE von Delphi (natürlich die neue nach Delphi 7) ist nach wie vor die beste IDE, die ich kenne.

[generic]

Zitat:

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.

Extra schreiben musst du es nicht. Methode implementieren und dann "strg-shift-c".

Ansonsten gefällt mir sehr gut, das delphi ein native compiler ist. keine runtimes auf welche man achten muss und vor allem, keine runtimes welche kaputt gehen können. bei meinen einen kunden sind >90% fehler auf runtimes zurück zu führen.

auch das setup wird natürlich viel leichter, wenn keinen runtimes installiert werden müssen.