Vorteile von Delphi gegenüber C#

[RedOne]

Ich hab mit PHP begonnen, gefolgt von "lange" C# und schliesslich abgelöst von Delphi.
Also kann niemand sagen, was man zuerst lernt, gefällt einem :-)

Was mir an C# nicht gefällt, ist die Qualität des Codes. In C# wird viel häufiger qualitativ schlechterer Code produziert. Wieso Objekte freigeben, irgendwer macht dies schon...
Variablen werden irgendwo deklariert und es herscht, ziemlich verallgemeinert natürlich, ein grösseres Chaos. Das sind so meine Erfahrungen, die ich mit Mehrpersonenprojekten gemacht habe.

Dinge wie "{" oder "end" sind sicherlich auch Geschmackssache. Ich kann allerdings von mir sagen, dass mich das lesen mit geschweiften (oder Geschwungenen? Keine Ahnung, wie diese betitelt werden) Klammern mehr anstrengt. Ich habe wirklich mühe, mich in solchem Code zu konzentrieren.
In Delphi wird man gewisserweise auch dazu gezwungen, "schöneren" Code zu schreiben, was von mir aus gesehen sich immer auf die Qualität der Software ausübt.

Was mir an C# allerdings wirklich besser gefällt, ist Case Sensitive, da dies wiederum der Korrektheit des Codes zu gute kommt.

Auch sehr Mühe habe ich mit Visual Studio. Nebst den enormen Ladezeiten (zuerst die Umgebung, danach erneut die Toolpalette) gefällt mir das Handling überhaupt nicht (und ich habe auf VS begonnen und bin erst später zu RAD gewächselt). Die Entwicklungsumgebung hat geniale Dinge, doch die 5%, die ein Programmierer am meisten braucht sind einfach schlecht. Wieso muss ich für die Codeansicht zwei Tasten drücken, die nicht gerade nebeneinander liegen? Wieso muss ich um von der Code-Ansicht wiederum in den Designer zu wechsel zwei diesmal andere Tasten drücken?
Wieso ist das durchkompilieren irgendwie auf Ctrl + Alt + B (oder irgendwo da).
Dies sind kleine Dinge, die sich jedoch häufen und mich dauernd genervt haben.
Zugegeben, auch das RAD-Studio hat teils unüberlegte Dinge (z.B. mehrere Zeilen einrücken mit Tab... respektive eben nicht mit Tab sondern einer komischen Kombination).

C# hat allerdings auch sehr viel gutes, dass darf man nicht vergessen. Doch werden diese Dinge von den meisten Programmierern nicht verwendet, weil sie nicht für den "alltäglichen Gebrauch" sind.

Einen weiteren Roman könnte man über die Geschwindigkeit schreiben (bis zu 40mal langsamer als Delphi).
Aber weil mein Zug fährt, lass ich dieses Thema nun :-)

Mein Fazit: Ich finde, mit Delphi wird qualitativ besserer Code geschrieben während C# halt auch von "Kiddys" benutzt werden konnte. Frontpage ist auch einfach als Notepad, aber das Ergebnis erklärt alles ;-)

Gruss

[Bernhard Geyer]

Zitat:

Zitat von JamesTKirk

Was heißt hier "nur UTF-8"? Was braucht man mehr? Braucht man unbedingt UTF-16 oder WideStrings? Ich denke nicht. Und UTF-8 unterstützen alle gängigen Plattformen

Windows verwendet ab NT UCS2 und ab W2K UTF-16. Verwendet nun dein Programm intern UTF8 muss für jedes Zeichnen eines Textes dieser UTF8-Text passend gewandelt werden und mit den entsprechenden Wide-API-Aufrufen dargestellt werden. Das ist mit Sicherheit nicht gerade Performance-Steigernd wenn viel Text dargestellt wird der sich öfter ändert. Der Weg den Delphi2009 geht ist sinnvoller als UTF8. Java und .NET verwenden von Hause aus UTF-16 um hier kein unnötiges Performancegrab zu haben.

Zitat:

Zitat von JamesTKirk

(mit den entsprechenden DLLs sogar Win9x).

Win9x hat keine UTF8 API Es hat eine handvoll funktionierten Wide-API-Aufrufe für UCS2-Strings.

Zitat:

Zitat von mkinzler

UTF-8 ist sogar flexibler als UTF-16. Windows verwendet aber UTF-16. Der Vorteil ist dabei, dass jedes Zeichen wie bei Ansi eine feste Breite hat (16Bit); bei UTF-8 ist diese zeichenabhängig

Das was du meinst war UCS2 und wurde von NT verwendet. UTF-16 ist genauso flexibel wie UTF-8 und hat den Nachteil der flexiblen längen (2-Byte für Zeichen der BMP bzw. 4 Byte für sonstige Zeichen (z.B. Klinkonisch :-))

[JamesTKirk]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von JamesTKirk

Was heißt hier "nur UTF-8"? Was braucht man mehr? Braucht man unbedingt UTF-16 oder WideStrings? Ich denke nicht. Und UTF-8 unterstützen alle gängigen Plattformen

Windows verwendet ab NT UCS2 und ab W2K UTF-16. Verwendet nun dein Programm intern UTF8 muss für jedes Zeichnen eines Textes dieser UTF8-Text passend gewandelt werden und mit den entsprechenden Wide-API-Aufrufen dargestellt werden. Das ist mit Sicherheit nicht gerade Performance-Steigernd wenn viel Text dargestellt wird der sich öfter ändert. Der Weg den Delphi2009 geht ist sinnvoller als UTF8. Java und .NET verwenden von Hause aus UTF-16 um hier kein unnötiges Performancegrab zu haben.

Zitat:

Zitat von JamesTKirk

(mit den entsprechenden DLLs sogar Win9x).

Win9x hat keine UTF8 API Es hat eine handvoll funktionierten Wide-API-Aufrufe für UCS2-Strings.

Ich lass mich ja durchaus belehren :mrgreen:

Ich kann nur mutmaßen, was die letztendliche Entscheidung dafür war UTF-8 zu wählen:
- die LCL verwendet AnsiStrings und keiner wollte auf WideString umstellen (bezogen auf: man wird nicht dafür bezahlt)
- es hängt vielleicht auch damit zusammen, dass die WideString Unterstützung plattformabhängig ist (aber nagelt mich jetzt nicht drauf fest)
- aktuelle Linux Systeme verwenden auch meist UTF-8 (keine Ahnung was OS X hier macht)
- auf die bisschen Perfomanceeinbußen mit der Konvertierung von UTF-8->Ansi->UTF-16 (letzterer Schritt wohl Win API intern, da Lazarus glaube (!) ich die Ansi API verwendet) kommts nicht an, da die LCL sowieso etwas langsamer is, als ihr pures Windows Pendent (durch die ganze Abstraktion).

Aber nun genug des Offtopics, sonst kriegen wir noch Haue :mrgreen:

[Alfredo]

Zitat:

Ich kann nur mutmaßen, was die letztendliche Entscheidung dafür war UTF-8 zu wählen:

Nicht genügend Entwicklungskapazitäten(Info von einem Entwickler).

Gruß
Alfred

[Meflin]

Zitat:

Zitat von Alfredo

Versuche einfach nur einmal eine anständige Entwicklungsumgebung aufzutreiben.
Bist Du mit Java überhaupt produktiv anfängst bist Du mit Delphi schon fertig.

Eclipse? Netbeans?

Zitat:

Zitat von RedOne

Was mir an C# nicht gefällt, ist die Qualität des Codes. In C# wird viel häufiger qualitativ schlechterer Code produziert. Wieso Objekte freigeben, irgendwer macht dies schon...

Das ist in der Tat die völlig richtige Frage: Wieso Objekte freigeben? Genau dafür ist der Garbage Collector da.

Und bei aller Liebe, die Qualität des Codes hängt in allererster Linie vom Autor ab, und nicht von der verwendeten Sprache. Man kann genauso in Pascal schlechten Sourcecode produzieren. Für den Großteil der ernsthaften Entwickler werden jedoch die Beschränkungen, die Pascal einem auferlegt, früher oder später einfach nervig. Chrome/Prism ist da genau der richtige Schritt. Hat aber - außer dem begin und end - auch nicht mehr viel mit Pascal gemein.

[mkinzler]

Zitat:

Man kann genauso in Pascal schlechten Sourcecode produzieren.

Es fällt einem dort nur schwerer.

Zitat:

Für den Großteil der ernsthaften Entwickler werden jedoch die Beschränkungen, die Pascal einem auferlegt, früher oder später einfach nervig. Chrome/Prism ist da genau der richtige Schritt.

Und die wären?

Zitat:

Hat aber - außer dem begin und end - auch nicht mehr viel mit Pascal gemein.

Also ich finde Delphi.Prism ist klar Pascal

[Meflin]

Zitat:

Zitat von mkinzler

Und die wären?

Wieso soll ich so oft erwähntes wieder aufzählen? Ziehe von Prism Delphi ab und du hast so ziemlich deine Antwort.

[Phoenix]

Also ich arbeite relativ viel mit Prism - aber für mich ist Prism immernoch echtes Pascal.
Was für Beschränkungen meinst Du denn nun (und bitte nur solche Anführen, die nicht mit der darunter liegenden Plattform zu tun haben).

Eigentlich schränkt Prism (aber auch wieder durch .NET) mehr ein als Delphi (keine benamsten Konstruktoren etc.).

[mkinzler]

Delphi.Prism ist Pascal egal ob du der Meinung bist oder nicht. Und wenn du Pascal schlecht findest, dann ist das auch ok.

[Meflin]

Zitat:

Zitat von Phoenix

Was für Beschränkungen meinst Du denn nun (und bitte nur solche Anführen, die nicht mit der darunter liegenden Plattform zu tun haben).

Also gut, die drei, welche mir am spontansten einfallen, weil sie mich wohl am meisten an Delphi W32 nerven ;)

• Code:

  case nonOrdinalVar of
    nonOrdinalType: Blubb;

• Code:

  for i: Integer = X do

  (genaue Syntax grad vergessen... könnt aber stimmen so :stupid: Geht sowieso in erster Linie um die "Inline-Deklaration")
• Code:

  property x: Integer read y * 10

Zitat:

Eigentlich schränkt Prism (aber auch wieder durch .NET) mehr ein als Delphi (keine benamsten Konstruktoren etc.).

So, da hätte ich jetzt gern mehr Beispiele, vor allem aber eine Erklärung, inwieweit das eine Einschränkung sein soll. Man kann halt keine verschiedenen parametergleichen Konstruktoren machen. Naja... Achso, ich seh grade, du beziehst das auf .Net. Naja, das gilt ja dann nicht ;)

Zitat:

Zitat von mkinzler

Delphi.Prism ist Pascal egal ob du der Meinung bist oder nicht.

:lol: Achso, definierst du das neuerdings? Prism ist ein Pascal-Derivat. Prism verletzt aber gleichzeitig fundamentale Pascal-Prinzipien (Inline Deklaration). Imho ist das in etwa so sinnvoll wie zu behaupten "Java ist C" (oder vllt. C++, da ja OOP noch dabei ist).