Vorteile von Delphi gegenüber C#

[hanspeter]

Eigentlich ist die Diskussion um die Programmiersprache müßig. Da kann doch jeder nehmen, was ihm heilig ist.
Wer undbedingt unter Net bei Pascal bleiben will, kann mit Prism arbeiten. Nennt sich auch Delphi.
Die eigentliche Frage ist die Plattform. Bleibe ich bei Win32. Bringt mir das Vorteile oder Nachteile.
Ich glaube das die Trennung von Programm und GUI die Zukunft hat.
WPF und Dynamik mit Silverlight bleiben bei Win32 außen vor.
Spätestens wenn die ersten WPF Applikationen im Umlauf sind, und funktionieren, wird man mit der altbackenen Win32 Oberfläche
Akzeptanzprobleme haben.
Was Plattformunabhängigkeit angeht, habe ich meine Zweifel. Das ging bei Kylix kräftig gegen den Baum.
Da erscheint mir Mono der aussichtsreichere Ansatz.
Server gestützte Architecturen sind auch nicht gerade eine Stärke von Win32.


Gruß
Peter

[Chemiker]

Hallo,

{} kann man in C, C++ aber leicht mit #define in Begin und End umwandeln wenn es sein muss.

Über C# kann ich noch nicht viel sagen, weil ich grade dabei bin mir diese Sprache beizubringen.

Was man aber definitiv sagen kann, dass man bei C, C++ mehr schreiben muss, der Quellcode ist zwar weniger, aber dafür muss man mehr Kommentare schreiben um den Quellcode auch nach 20 Jahren zu verstehen, dass ist bei Delphi (Pascal) meiner Meinung nicht so.

Bis bald Chemiker

[Wolfgang Mix]

Als überzeugter Pasclianer gebe ich Dir Recht!
Komme auch immer noch mit Fortran, Basic in allen Varianten und dBase zurecht.
C geht bei einigem Trainng aber auch. Was ich gut an C oder C# finde ist, das man seine Funktionen in anderen Programmiersprachen einbinden kann. Man muß also das Rad nicht immer wieder neu erfinden.

Gruß

Wolfgang

[HeikoAdams]

Zitat von Chemiker:

aber dafür muss man mehr Kommentare schreiben um den Quellcode auch nach 20 Jahren zu verstehen

Kom ... was?? Nein im Ernst: Kommentare benötige ich eigentlich nur sehr selten und dann auch nur bei komplexen Methode. Ansonsten ist der Source aufgrund der Sprache ja schon sehr einfach zu verstehen.

[alzaimar]

Zitat von HeikoAdams:

Nein im Ernst: Kommentare benötige ich eigentlich nur sehr selten und dann auch nur bei komplexen Methode. Ansonsten ist der Source aufgrund der Sprache ja schon sehr einfach zu verstehen.

Oh je. Und was is mit den Parametern? Beschreibung, Bedeutung, Kontext? Was ist, wenn man deinen Quellcode nicht hat? Was macht die Routine? In welchem Kontext ist sie gültig?

Fragen, die ein 'Kom...was' beantworten könnte. Die Zeiten, in denen nur Schattenparker Kommentare benötigt, sind vorbei. Kommentarloser Code ist nicht cool, sondern macht einsam

[himitsu]

Zitat von alzaimar:

Und was is mit den Parametern?

aussagekräfiger Name? + Type + eventuell Präfix wie VAR/CONST/OUT

[HeikoAdams]

Zitat von alzaimar:

Oh je. Und was is mit den Parametern? Beschreibung, Bedeutung, Kontext? Was ist, wenn man deinen Quellcode nicht hat? Was macht die Routine? In welchem Kontext ist sie gültig?

Fragen, die ein 'Kom...was' beantworten könnte. Die Zeiten, in denen nur Schattenparker Kommentare benötigt, sind vorbei. Kommentarloser Code ist nicht cool, sondern macht einsam

Sorry, hab vergessen die Ironie-Tags zu setzen. Aber himitsu hat auch recht: Wenn man sich die Mühe macht, Methoden, Parameter und Variablen sprechend zu benennen, bräuchte man für Delphi Quellcode nur sehr selten Kommentare.

[mkinzler]

Das reicht unter Umständen nicht. Ich finde es sinnvoller kürzere Variablenbezeichner zu nehmen und diese dafür gut zu kommentieren

[jaenicke]

Naja, das ist so ähnlich wie die Menübefehle "Kopieren 1", "Kopieren 2" und "Kopieren 3" (Variablennamen) zu nennen und im Handbuch (Kommentar) diese zu erklären... (jetzt mal überspitzt gesagt)

Ich bezeichne die Variablen und Methoden usw. auch lieber so, dass man nur Kommentare für die Zusammenhänge braucht. Aber keine für jede kleine Variable oder die ganzen Parameter.

[Phoenix]

Zitat von mkinzler:

Das reicht unter Umständen nicht. Ich finde es sinnvoller kürzere Variablenbezeichner zu nehmen und diese dafür gut zu kommentieren

Also in jedem Buch über Softwarequalität steht, dass Kommentare zugunsten von guten Benamsungen wegfallen sollten.
Hintergrund ist ganz einfach der: Wenn sich der Code ändert, wird der Kommentar in aller Regel aus Faulheit nicht angepasst und wird somit mit der Zeit falsch. Und ein falscher Kommentar, an dem sich ein neuer Entwickler orientiert und daraufhin selber Fehler verursacht ist schlimmer als gar kein Kommentar, der den Entwickler dann dazu veranlasst, im (immer gültigen) Source nachzuschauen was wirklich Sache ist.