Vorteile von Delphi gegenüber C#

[Alfredo]

Zitat:

Eine moderne UI ist halt etwas komplizierter als ein alte Dos-Oberfläche

Irrtum. Daraus entsteht eben sofort eine moderne GUI.

Gruß
Alfred

[HeikoAdams]

reduced to the max oder wie? :gruebel:

[R2009]

Hi,

mir gehts fast wie dir. Ich habe kürzlich einen C# Kurs gemacht.

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.

Ist überhaupt kein Nachteil von Delphi. Ich finde die Klammersyntax (begin end) einfach besser als die Klammern in C# (C oder C++ das gleiche)., aber nur wenn sie nicht mit C gekreuzt wird:

Delphi-Quellcode:

If n= 0 then begin
end;

Sowas find ich auch in Delphi (Pascal) bescheiden.

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 ist für mich ein Nachteil. Warum nicht gleich zurück zu Basic da muss ich garnichts mehr deklarieren.

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

Das macht einen doch kirre und verleitet dazu z.B. "nummer" und "Nummer" zu verwenden. Wo bleibt denn da die Übersichtlichkeit.

Zitat:

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

Ganz einfach:
Ich persönlich bin mit Pascal und Delphi aufgewachsen! Für mich ist und bleibt Delphi und somit Pascal die Nummer eins.

Viele Grüsse


PS:
generic hat geschrieben:

Zitat:

Delphi zeichnet übrigens durch kurze Entwicklungszeiten aus.
Irgendwie ist alles drin was ein Entwickler wirklich braucht, ohne Schnick und Schnack.

Da kann ich nur eins sagen: Volltreffer

[HeikoAdams]

Zitat:

Zitat von R2009

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 ist für mich ein Nachteil. Warum nicht gleich zurück zu Basic da muss ich garnichts mehr deklarieren.

Abgesehen davon das sich mir der Sinn des nicht deklarieren müssen von Methoden und Variablen nicht wirklich erschließt.

Zitat:

Zitat von R2009

Ich persönlich bin mit Pascal und Delphi aufgewachsen! Für mich ist und bleibt Delphi und somit Pascal die Nummer eins.

Geht mir genau so. Delphi rulez :thumb:
Und seit Embarcadero Delphi und Co übernommen hat, geht es auch endlich wieder vorwärts mit Delphi. In den letzten Borland-Jahren ist die Weiterentwicklung von Delphi ja eher stagniert die Qualität der Entwicklungsergebnisse konnte man getrost als Murks bezeichnen. Aber das wird jetzt zu sehr Offtopic.

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

Also wenn ich das richtig verstehe, dann kann man bei C# in einer Methode zwei Variablen mit dem gleichen Namen, nur in unterschiedlicher Schreibweise, anlegen? Na dann mal viel Spaß beim Debuggen von komplexen Methoden :wall: Da hat dann doch ganz schnell die falsche Variable am Wickel und wundert sich dann, wenn das Ergebnis nicht passt. Wie ich schon sagte: Wer keine Arbeit hat, der macht sich welche.

[Alfredo]

Zitat:

reduced to the max oder wie? Grübelnd...

Man soll es ja nicht übertreiben :-D , aber das ist alles

Zitat:

#include "dcdialog.ch"

PROCEDURE MAIN()

LOCAL GETLIST := {}, Getoptions
SET DATE GERMAN
SET CHARSET TO ANSI

@ 5,30 DCPUSHBUTTON ;
CAPTION {||'Start'} ;
SIZE 10, 1.5 ;
Action{||msgbox("Hallo Markus")}

DCGETOPTIONS ;
SAYLEFT ;
WINDOWHEIGHT 250 ;
WINDOWWIDTH 500

DCREAD GUI ;
TITLE 'eXPress++-Beispiel' ;
MODAL ;
OPTIONS GetOptions

RETURN

Procedure APPSYS()
RETURN

Wenn man sich die Mühe macht, kommt man sicher mit 5 Zeilen aus.

Gruß
Alfred

[exilant]

Zitat:

Zitat von Alfredo

Würde

@ 17,20 DCPUSHBUTTON

wirklich eine Programmiersprache verkomplizieren?

Diese Befehlsyntax hat z.B. für Xbase++ eine Einmanfirma entwickelt.


Gruß
Alfred

Auwei. Sowas ging schon zu Clipper 5.x Zeiten. Stichwort UDC (User Defined Commands). Ist nichts anderes als ein Präprozessor "Hack". Schau dir mal den Output des Präprozessors an (so das mit XBase++ geht).
Es gab da mal eine entsprechende Win3x Erweiterung Clip4Win und Fivewin. Die haben auf einem ähnlichen Klavier gespielt. Mit einer C Bibliotkek die Win Api (einen sehr kleinen Teil) gekapselt und dann mittels eines Haufens UDCs in Clipper/Xbase Syntax verfügbar gemacht. Zumindest ersteres ist ja unter Xbase++ nicht nötig da es ja native Win32 ist und mit entsprechenden Laufzeitbibliotken ausgeliefert wird.
Ansonsten war es aber eine Sackgasse. Wundert mich, das die XBase++ Leute jetzt solche Konzepte wieder ausgraben. Vermutlich gibt es doch noch mehr alte Clipper Apps als ich dachte. Allerdings lohnt sich der Portierungsaufwand auf eine tote Plattform wie Xbase/VO imo nicht.

[HeikoAdams]

Und ich dachte immer, der Sybase PowerBuilder wäre grausam 8)

[Meflin]

Was bitteschön ist an dem Pascal-Variablendeklarationszwang ein Vorteil? Man wird doch allenernstes dazu gezwungen, popelige Schleifenvariablen u.ä. Methoden-global zu deklarieren. I call Bullshit!

Code:

for(int i = 0; i < X; i++)

gültig genau innerhalb der Schleife, wo ich es haben will. Lesbarer Code hin oder her. Sichtbarkeitsüberschneidungen sind _auch_ eine Fehlerquelle :roll:

[mkinzler]

War ja ursprünglich für DOS gedacht und wurde dann erweitert

[HeikoAdams]

Zitat:

Zitat von Meflin

Was bitteschön ist an dem Pascal-Variablendeklarationszwang ein Vorteil?

Naja, wenn man z.B. in einer Methode mehrere Schleifen hat, braucht man die Zählvariable nur einmal zu deklarieren. Recycling leicht gemacht :-D Abgesehen davon finde ich es übersichtlicher und den Code leichter lesbar, wenn ich alle in einer Methode/Unit verwendeten Variablen auf "einem Haufen" habe und nicht erst die Methode komplett lesen muss, um zu wissen, welche Variablen existieren und ggf. recycled werden können.

[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:

Zitat von Chemiker

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

Kom ... was?? :gruebel: 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:

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 :mrgreen:

[himitsu]

Zitat:

Zitat von alzaimar

Und was is mit den Parametern?

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

[HeikoAdams]

Zitat:

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 :mrgreen:

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:

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.

[Chemiker]

Hallo,

ich glaube wir kommen etwas vom Thema ab.

Bis bald Chemiker

[mkinzler]

Ich plädiere ja auch nicht für x, y, z, sondern mag nur zu lange nicht
StrInVornameDesVatersDerBrautDerErstenEhe o.ä. finde ich zu lang und würde diesen Zusammenhang "kommentieren"

[Luckie]

Zitat:

Zitat von Wolfgang Mix

Was ich gut an C oder C# finde ist, das man seine Funktionen in anderen Programmiersprachen einbinden kann.

Wie meinen? DLLs die von anderen Programmiersprachen genutzt werden können, kann man auch mit Delphi schreiben. Oder was meinst du jetzt?

[Wolfgang Mix]

Genau anders herum. Hier Dein eigener Kommentar:

Zitat:

Pack sie in eine DLL und exportier die Funktion. Oder schreib sie nach Delphi um.

Gruß

Wolfgang

[R2009]

Hi Leute,

macht doch diesen Thread zu!
Das Ganze kommt mir vor wie eine Mischung aus Glaubenskrieg und fundiertem Halbwissen.

Hauptsache es wir auf Delphi rumgehackt. Für mich ist diese Diskussion entschieden.
Ich bleibe bei Delphi, bzw Pascal.

Grund:
Es gibt einfach keinen Grund die Programmiersprache zu wechseln. Wenn ich ehrlich sein soll dann bleibe ich sogar
bei D7. Das meiner Meinung nach beste Produkt das Borland (wie die jetzt heissen ist mir wurscht) auf den Markt
gebracht hat.

Viele Grüsse

[user0815]

Zitat:

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

Dieses Forum ist echt der Hammer. Meistens finde ich entsprechendes durch die richtige Suche über www.google.de a la: Suchebegriff site:delphipraxis.net.


C# hat aber auch ein extrem schnell wachsendes deutsches Forum: http://www.mycsharp.de/wbb2/forum.php
Viele Artikel unter: http://www.codeproject.com/
Guide to C#: http://www.guidetocsharp.de/

Denke ich werde selber irgendwann zu C# wechseln.

[Pfoto]

Moin zusammen,

Ich habe zwar jetzt mein erstes Programm fertig (zu sehen auf picoly.de),
aber ich lerne nun C#, weil ich mit Silverlight arbeiten wollte.
Das WPF-System ist ja wirklich extrem mächtig gegenüber den normalen Forms,
gerade beim verschachteln von Komponenten, z.B. TreeView mit beliebigen
Komponenten als Nodes.

Ich finde diese generischen Listen, Arrays und Dictorarys so klasse;
das spart schon eine Menge Tipparbeit.
Aber mit Delphi 2009 wurde ja gut aufgeholt.

Ebenfalls von Vorteil in C# wie ich finde:
- klassenzugehörige Enums
- einfache einbinden von Ressourcen
- über WPF echte Trennung von Programm-Aussehen und Programm-Logik
- LINQ (SQL ähnliche Abfragen auf nahezu jede Datenquelle)


Wie lange werden die nativen Programme unterstützt und gefragt sein,
die Zukunft geht doch eindeutig in Richtung Cloud-Computing und
Browser-Apps, findet ihr nicht?
Auch wenn ich selbst lieber fest installierte Programme ohne
Abhänigkeiten vom Netz mag.

Gruß
Jürgen

[HeikoAdams]

Zitat:

Zitat von Pfoto

Wie lange werden die nativen Programme unterstützt und gefragt sein,
die Zukunft geht doch eindeutig in Richtung Cloud-Computing und
Browser-Apps, findet ihr nicht?

Also mich würde es stören, eine Cloud-Computing Backup Software oder Textverarbeitung zu nutzen. 8)
Aber ganz allgemein denke ich, das native Anwendungen immer da gefragt sein werden, wo z.B. aus Kostengründen ältere Hardware verwendet wird. Bestes Beispiel dürften da wohl die Test-Geräte in Werkstätten sein, wo sehr oft noch ältere Prozessoren (80386, 80486) verbaut sind.

[Luckie]

Zitat:

Zitat von Wolfgang Mix

Genau anders herum. Hier Dein eigener Kommentar:

Zitat:

Pack sie in eine DLL und exportier die Funktion. Oder schreib sie nach Delphi um.

Wie genau andersrum? Du hast es als Vorteil dargestellt, dass man Funktionen in C oder C# auch in anderen Programmiersprachen nutzen kann. Da man das aber genauso gut mit Delphi machen kann, wo ist da der Vorteil?

[Phoenix]

Zitat:

Zitat von R2009

macht doch diesen Thread zu!
Das Ganze kommt mir vor wie eine Mischung aus Glaubenskrieg und fundiertem Halbwissen.

Das ist es aber nicht. Zum Schliessen besteht keine Veranlassung.

Die Frage ist doch: Braucht man zwingend die Vorteile einer Managed Plattform wie .NET oder Java (als da in erster Linie Plattformunabhängigkeit und eine breite Masse an enthaltener Funktionalität wären), oder ist der bisher existierende native (Delphi-) Code so umfassend und da daher so Wertvoll, dass man ihn lieber weiterverwendet und dadurch produktiver ist während man auf die Managed-Vorteile verzichten kann.

Ich selber habe nicht so viel Legace-Code, dass sich ein unmanaged Arbeiten noch weiter lohnen würde. Ich ziehe es lieber vor, dass meine Anwendungen die ich neu Schreibe auch auf Linux und dem Mac laufen. Wer das nicht braucht, der ist mit dem bisherigen Delphi sehr gut bedient. Ich würde mich damit nur zu sehr einschränken, also greife ich der Sprache wegen lieber zu Delphi Prism.

Die Wahl der Plattform muss jeder für sich und seine eigenen Bedürfnisse treffen, und die Wahl der Sprache richtet sich dann innerhalb der für diese Plattform zur Verfügung stehenden Sprachen an den Punkten: Persönliche Vorliebe, verfügbarer existierender Quellcode und ggf. Verfügbarkeit von Entwicklern.

Das hat nichts mit Glaubenskrieg zu tun, sondern mit reiner Wirtschaftlichkeit der Entscheidungen.

[jaenicke]

Zitat:

Zitat von Phoenix

Ich ziehe es lieber vor, dass meine Anwendungen die ich neu Schreibe auch auf Linux und dem Mac laufen. Wer das nicht braucht, der ist mit dem bisherigen Delphi sehr gut bedient.

Wobei das ja in den nächsten Versionen dann auch mit Delphi gehen soll. Allerdings ohne Mono oder ähnliches, sondern nativ. Und das ist für mich schon sehr interessant.

[mkinzler]

Die Frage ist ja nur, ob die Diskussion zur Frage passt. Weil diese beschäftigt sich primär mit der Platform, währrend ursprünglich nach der Sprache gefragt wurde.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke

Wobei das ja in den nächsten Versionen dann auch mit Delphi gehen soll. Allerdings ohne Mono oder ähnliches, sondern nativ. Und das ist für mich schon sehr interessant.

Die Frage ist aber ob dieser Ansatz nicht zu entgültigen Tod von Delphi beiträgt. CLX/Kylix under VCL.NET haben uns schon Jahre an IDE-Produktivität und Entwicklung gekostet (von den Kosten bei den Komponentenlieferanten nicht zu reden). Die VCL ist nunmal sehr WinAPI-Lastig. Und ob man das jeh Plattformunabhänig hin bekommt :gruebel:

Und seine Entscheidung auf was aufzustzen das es *irgendwann* evtl. geben soll (Wie war das noch mal mit Windows-Mobile-Support auf VCL.NET-Basis?) ist sehr fraglich.

[Phoenix]

Zitat:

Zitat von mkinzler

Die Frage ist ja nur, ob die Diskussion zur Frage passt. Weil diese beschäftigt sich primär mit der Platform, währrend ursprünglich nach der Sprache gefragt wurde.

Wenn es um Delphi (native) vs. C# (.NET, also Managed) geht, ist die Frage eigentlich immer die der Plattform.
Schliesslich kann Delphi Win32 nicht managed ausgeführt werden und C# nicht native. Diese zwei Fragen gehören also immer zueinender.

[mkinzler]

Die Sprache Delphi liegt aber auch Delphi.Prism zu Grunde, welches auch mananged ist. Deshalb gelten dann die Vorteile für .Net nicht nur für c# sondern auch für Delphi.Prism. Die Vorteile von nativ dagegen nicht.
Deshalb sollte man die Frage so abändern, dass es hier um die Plattform und nicht um die Sprache geht.

[HeikoAdams]

Zitat:

Zitat von mkinzler

Deshalb sollte man die Frage so abändern, dass es hier um die Plattform und nicht um die Sprache geht.

Öhm ... nein! Es sollte ein neuer Thread gestartet werden, da wir inzwischen von der Ausgangsfrage (Vorteile von Delphi gegenüber C#), die sich mit der Sprache C# beschäftigt hat, abgedriftet sind und nun über die Vor- und Nachteile der verschiedenen Plattformen (native vs. .net) diskutieren.

[mkinzler]

Aber irgendwie ging es nie um die eigentliche Sprache

[Alfredo]

Wenn es nur um die Sprache gegangen wäre, hätte ich Delphi nicht
gekauft.

Warum?

• Case ohne String
• kaufmännische Rundung funktioniert nicht richtig
• ich habe es aufgegeben, die ganzen Nicklichkeiten zu notieren

Darüber hinaus gibt es eine Vielzahl an Handlingsproblemen,
die natürlich nichts mit der Sprache an sich zu tun haben.

Was nutzt mir die beste Sprache, wenn ich damit keine stabilen
Programme oder nur mit sehr hohem Aufwand zu einem Endprodukt
komme. Denke da z.B. an Java.

Gruß
Alfred

[Luckie]

Du willst doch jetzt wohl nicht etwa behaupten, dass man mit Delphi keine stabilen Anwendungen erstellen kann oder dass es aufwendig sei mit Delphi eine Windows Anwendung zu entwickeln? Und dann führst gerade Java als Gegenbeispiel an. Weißt du, was es für ein Krampf ist mit Java eine Programm mit einer grafischen Oberfläche zu entwickeln?

[Viktorii]

@Luckie: So wie ich das verstanden haben meinte er es genau anders rum...

Ist Java denn da wirklich so schlimm? :| Hatte überlegt beim nächsten Projekt auf Java zu setzten, weil die Plattformunabhängigkeit bei diesem Projekt ein großer Vorteil für mich wäre....