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. :mrgreen: Du bist allerdings hier in der Delphi-Praxis und nicht in der C-Praxis. :zwinker: 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:

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:

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:

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:

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:

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:

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:

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:

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? :shock: :cheer:

[Luckie]

Zitat:

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

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

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:

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

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

[Alfredo]

Zitat:

Es gibt noch kaum noch Vorteile von Delphi gegenüber C# und auch kein Alleinstellungsmerkmal.

Im Bereich des Zugriffs auf Datenbanken die nicht von MS stammen sehr wohl.

ADO.Net ist von seinem Grundkonzept m.E. für einen Praktiker eine absolute Fehlkonstruktion.

Gruß
Alfred

[Bernhard Geyer]

Zitat:

Zitat von Alfredo

ADO.Net ist von seinem Grundkonzept m.E. für einen Praktiker eine absolute Fehlkonstruktion.

Wieso?

[Alfredo]

Zitat:

Wieso?

Das asynchrone Modell lautet wie folgt:


Daten werden aus der Datenbank abgefragt, in das Dataset geladen und
die Verbindung wieder geschlossen und die Daten offline weiterbearbeitet.

Viel Spass beim zurückschreiben der Daten.


Zurückblättern in einer Datenbank geht auch nur mit Tricks.


Gruß
Alfred

[HeikoAdams]

Nu muss ich hier auch mal meinen Senf dazu geben 8)

Seit meinen Chefs vor einigen Wochen jemand den Floh ins Ohr gesetzt hat, das Delphi total veraltet, und sowie schon so gut wie tot sei (LÜGE!!) und mit C# angeblich alles viel einfacher, schöner und schneller geht, "darf" ich mich jetzt auch mit dieser "Sprache" auseinander setzen. Meine Meinung zu C# ist eindeutig: :kotz:

C# verleitet, nein, es nötigt einen dazu, unübersichtlichen Code zu fabrizieren, da man immer und überall Variable deklarieren kann und mit Klammer, Ausrufezeichen etc um sich werfen muss, anstatt entsprechende Schlüsselwörter zu verwenden. Also eher was für schreibfaule Programmierer als für gewissenhafte Softwareentwickler :evil: Ich finde Delphi ist da durchdachter, da es einen dazu zwingt, wenigstens halbwegs lesbaren Code zu schreiben. Gegen fehlende oder katastrophale Formatierungen von Sourcecode is ja noch kein Kraut gewachsen.

Ich muss ehrlich sagen, das ich bislang keinen objektiven Vorteil von C# gegenüber Delphi gefunden habe. :dp:

[Elvis]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Alfredo

ADO.Net ist von seinem Grundkonzept m.E. für einen Praktiker eine absolute Fehlkonstruktion.

Wieso?

Das hört man fast nur von Leuten, die vorher irgendwelche Connections auf irgendwelche Forms oder Datamodules gezogen haben.
Das funktioniert mit ADO.Net natürlich überhaupt nicht gut. Aber ADO.Net ist auh entworfen wurden um sinnvollen Datenzugriff zu vereinfachen. Nicht solchen unwartbaren Klickibunti-Connection-auf-den-Designer-ziehen Krempel.

[HeikoAdams]

Zitat:

Zitat von hanspeter

Es gibt noch kaum noch Vorteile von Delphi gegenüber C# und auch kein Alleinstellungsmerkmal.

Doch:

• native Compiler -> keine bloated Runtime notwendig
• keine Runtime = eine potentielle Fehlerquelle weniger
• einfach zu erlernen
• strukturierter Aufbau des Sourcecode
• Quellcodes sind für dritte leicht lesbar

Also, wenn ich noch länger nachdenke, dann fallen mir sicher noch einige Vorteile ein 8)

[mkinzler]

Irgendwie wird hier nicht die Sprache sondern eher die Platform verglichen :gruebel:

[Bernhard Geyer]

Zitat:

Zitat von Alfredo

Daten werden aus der Datenbank abgefragt, in das Dataset geladen und
die Verbindung wieder geschlossen und die Daten offline weiterbearbeitet.

Viel Spass beim zurückschreiben der Daten.

Zurückblättern in einer Datenbank geht auch nur mit Tricks.

Wir haben in unserer App genau sowas implementiert und sind glücklicherweise seit einiger Zeit TDataset und DB-Senstive Controls los. Haben damit auch einige Performancelücken lösen können die durch DB-Sensitive Controls und rückwärts scrollbare große Datenmengen (teilweise mit DBGrid-Bindung) verursacht wurden (haben DB's >> 10 GB im Einsatz) gelöst.

Aber AFAIK gibt es für Prototyp-Erstellung mittlerweile in .NET (2.0) eine Delphi-Like DB-Bindung.

[Alfredo]

Hallo Elvis,

dann schreib doch mal mit ADO.NET eine Lagerbuchhaltung oder ein
Kassenbuch.

Es gibt eine Vielzahl von praktischen Beispielen, bei denen ADO.NET
zu erheblichen Problemen bei der Realisierung führt.

Greif mal direkt auf Firebird zu.

Warum soll ich mir dass alles antun, wenn eine einzige Komponete
im Zusammenspiel mit der Datenbank dies alles "just in time"
erledigt.

Für was gibt es SQL-Befehle die die Datenmenge im Dataset ohne
Probleme auf ein Minimum beschränken.


Gruß
Alfred

[hanspeter]

Zitat:

Zitat von HeikoAdams

[*] keine Runtime = eine potentielle Fehlerquelle weniger

Unser Projekt benötigt mehr als ein Dutzend dll.
Teilweise in unterschiedlicher Konfiguration. (Freischaltmodell)
Da muss mit den runtime BPL von Delphi gearbeitet werden.
Die BPL Hölle ist ein vielfaches der dll Hölle.
Beherrschbar ist das Ganze nur, wenn vor einem Update das
gesamte Projekt komplett neu kompiliert wird.
Vorher alle DCU und bpl löschen.
Bei uns erledigt das ein Buldserver. Der läuft jede Nacht und benötigt mehr als eine Stunde.
Ein Problem mit der Net - runtime hatte ich noch nicht.
Ich rede allerdings von einer abgesicherten Serverumgebung.

Gruß
Peter

[jfheins]

Zitat:

Zitat von HeikoAdams

• native Compiler -> keine bloated Runtime notwendig
• keine Runtime = eine potentielle Fehlerquelle weniger
• einfach zu erlernen
• strukturierter Aufbau des Sourcecode
• Quellcodes sind für dritte leicht lesbar

Hmmmm ....

• Auch für Delphi ist eine Runtime notwendig. Sie wird sogar in die exe einkompiliert. Oder warum ist eine Delphi-Anwendung mit einem leeren Form 500kb groß? Und seit XP SP2 und höher dürfte .net auch auf jedem PC vorhanden sein. P.S.: Du hast auch schon die C++ Runtime auf deinem PC. Die gibts schon seit Win95. Und niemand hat sich je beschwert, dass für C++ Anwendungen bloated Runtimes notwendig seien. Und auf das Nativ kann ich gerne verzeichten, wenn die Anwendung nicht langsamer läuft, dafür aber mit wenig Aufwand nach Linux portierbar ist ;)
  
• Und die Delphi VCL+RTL ist Bugfrei? Guck mal ins QC
• Okay, Delphi ist "sprechender" und deshalb für Anfänger etwas besser geeignet. Den Punkte gebe ich dir ^^
• Sowohl mit Delphi als auch mit C# kann man strukturierten Sourcecode schrieben. Und sowohl mit Delphi als auch mit C# kann man Spaghetti-Code schreiben.
• Eine Mischung aus den beiden vorherigen Punkten...

[HeikoAdams]

Ich bezog mich mit der Aussage auch nur darauf, das Runtime Bugs in der Regel zuerst dem Anbieter der Software angelastet werden.
Dieser muss dann erst einmal Zeit und Geld investieren, um die Ursache des Fehlers zu suchen, nur um dann festzustellen, das es ein Bug in der .net-Runtime ist, für den er nichts kann. Danach darf er dann nochmal Zeit und Geld investieren, um den Bug in der Runtime zu umschiffen und bei jedem Runtime Update prüfen, ob der Workaround noch notwendig ist. SO kann man sich auch Arbeit machen, wenn man keine hat :wink:

Zitat:

Zitat von jfheins

Und seit XP SP2 und höher dürfte .net auch auf jedem PC vorhanden sein.

Dabei dürfte es sich aber - wenn überhaupt - um eine .net 2.0 Runtime handeln, sofern man nicht immer die aktuellsten M$ Produkte installiert hat, was man aber nicht bei jedem PC voraussetzen sollte.

Zitat:

Zitat von jfheins

Du hast auch schon die C++ Runtime auf deinem PC. Die gibts schon seit Win95. Und niemand hat sich je beschwert, dass für C++ Anwendungen bloated Runtimes notwendig seien.

Dann schau Dir mal die Dateigröße der Setup Routine der C++ Runtime und die der .net 3.5 Runtime an :zwinker: Die .net 3.5 Runtime ist inzwischen bei ca 230 MB. Die muss man dann potentiell mit in die Installation packen oder während selbiger aus dem Netz nachladen. Viel Spaß!

[MagicAndre1981]

Zitat:

Zitat von Elvis

Das hört man fast nur von Leuten, die vorher irgendwelche Connections auf irgendwelche Forms oder Datamodules gezogen haben.
Das funktioniert mit ADO.Net natürlich überhaupt nicht gut. Aber ADO.Net ist auh entworfen wurden um sinnvollen Datenzugriff zu vereinfachen. Nicht solchen unwartbaren Klickibunti-Connection-auf-den-Designer-ziehen Krempel.

:thumb: genau!

Zitat:

Zitat von HeikoAdams

Dann schau Dir mal die Dateigröße der Setup Routine der C++ Runtime und die der .net 3.5 Runtime an :zwinker: Die .net-Runtime ist inzwischen bei > 200 MB. Die muss man dann potentiell mit in die Installation packen oder während selbiger aus dem Netz nachladen. Viel Spaß!

und? die C++ Runtime bietet nur die C++ Grundfunktionen, mehr nicht. .Net bietet eine riesige Klassenbibliothek bei der fast alles drin ist, was man bei Delphi (Win32) oder VC++ (Win32) nachbauen muss. Du kannst die Bootstrapper Pakete auch mitliefern.

[Alfredo]

Zitat:

Irgendwie wird hier nicht die Sprache sondern eher die Platform verglichen

Eine Sprache losgelöst von seinem damit zu erstellenden Endprodukt ist doch
genau der Fehler, den heute alle Programmiersprachen haben.

Warum also sind

• Formulare
• allgemeine Datenbankschnittstelle
• Datagrid(Cursorsteuerung, Editfunktionen)
• Editfelder für Zahlen

nicht Teil einer Programmiersprache.

Gruß
Alfred

[HeikoAdams]

Zitat:

Zitat von MagicAndre1981

und? die C++ Runtime bietet nur die C++ Grundfunktionen, mehr nicht. .Net bietet eine riesige Klassenbibliothek bei der fast alles drin ist, was man bei Delphi (Win32) oder VC++ (Win32) nachbauen muss.

Du vergleichst Äpfel mit Birnen und gibst es auch noch zu 8) Bei C++ kann man ja theoretisch wählen, ob man die MFC, die VCL, QT, GTK oder ähnliches für die GUI verwenden will. Aus dem Grund reicht es für die C++ Runtime, wenn sie nur die Grundfunktionen bietet. Für alles andere sind grafische Toolkits verantwortlich. .net ist da quasi die eierlegende Wollmilchsau, die ein Rundumsorglos Paket bietet. Insofern ist der Begriff "runtime" im eigentlichen Sinne für die .net Runtime nicht ganz zutreffend, da es ja eher Runtime + grafisches Toolkit ist.

Zitat:

Zitat von MagicAndre1981

Du kannst die Bootstrapper Pakete auch mitliefern.

Jo, dann bedankt sich der Kunde, wenn die Setup Routine 230 MB aus dem Netz nachladen will. Okay, in Zeiten von Flatrates und DSL ist das zwar nicht mehr so dramatisch, aber selbst mit ner 1000er Leitung dauert sowas doch noch ein paar Minuten.

Zitat:

Zitat von Alfredo

Warum also sind

• Formulare
• allgemeine Datenbankschnittstelle
• Datagrid(Cursorsteuerung, Editfunktionen)
• Editfelder für Zahlen

nicht Teil einer Programmiersprache.

Modularisierung? KISS (Keep It Small and Simple)-Prinzip?

[Progman]

Ich für meinen Teil lege folgende Überlegung zu Grunde:
Wenn ich mit meinem Delphi2007 ein Programm erstelle, dann kann ich sicher sein, dass ich es auf fast alle Windows-Systeme (Win98, NT, Win2000, XP, Vista und Windows7) kopieren kann und es funktioniert. Bei C# ist das nicht gegeben. Dazu kommen oft noch Versions-Probleme mit dem installierten .NET-Framework.
Und die Sprache Pascal ist einfach aussagekräftiger als C (und alle Ableitungen). Meine Meinung dazu :)

[Alfredo]

Zitat:

KISS

Würde

@ 17,20 DCPUSHBUTTON

wirklich eine Programmiersprache verkomplizieren?

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


Gruß
Alfred

[HeikoAdams]

Zitat:

Zitat von Alfredo

Würde

@ 17,20 DCPUSHBUTTON

wirklich eine Programmiersprache verkomplizieren?
Diese Befehlsyntax hat z.B. für Xbase++ eine Einmanfirma entwickelt.

IMHO ja. Mein erster Gedanke wäre "Was will mir der Autor damit sagen". Aber ansonsten dürften Codegear/Microsoft da eher der richtigen Ansprechpartner sein :zwinker:

[mkinzler]

Zitat:

Zitat von Alfredo

Zitat:

KISS

Würde

@ 17,20 DCPUSHBUTTON

wirklich eine Programmiersprache verkomplizieren?

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


Gruß
Alfred

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

[generic]

Zitat:

Seit meinen Chefs vor einigen Wochen jemand den Floh ins Ohr gesetzt hat, das Delphi total veraltet, und sowie schon so gut wie tot sei (LÜGE!!) und mit C# angeblich

Der soll mal zur Roadshow gehen.

z.B.
am 7.9. in Dortmund
am 9.9. in Hannover

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