Vorteile von Delphi

[Hubble]

So langsam wirds stressig. Ich glaub das nächste mal stell ich mich in unser Statdion und schweke die Bayern-Fahne, da gibts nicht so viel Haue. ;)
Mache erst mal Pause.

Cu Hubble

[malo]

Zitat:

Zitat von Hubble

mäßiges exception handling

Bitte genauer beschreiben, ich weiß grad nicht, was du meinst.

Zitat:

schlechte Pointernutzung

In C++, ja :mrgreen:

Zitat:

VCL nicht Threadfest

Zitat:

Objekte können nur mit .create erzeugt werden und wieder gelöscht werden

Das find ich auch gut. Ich hab noch nie etwas anderes gebraucht.

Zitat:

Klassen und Ausprogrammierung sind immer getrennt

It's not a bug, it's a feature. Das ist eine der Vorteile in Delphi.

Zitat:

nicht ausgereifte Projektverwaltung

Redest du gerade von der IDE oder von der Sprache?


Von wegen "unsauberes Programmieren" kann man sich jedoch auch streiten. Jede Sprache hat ihre Vorteile. In Delphi ist IMHO, dass man strukturiert Variablen immer an den Anfang setzen muss, für alles einen eigenen Bereich hat, und nichts "mal eben irgendwo" machen kann etc. Ob es ein Fluch oder ein Segen ist, soll jeder selbst entscheiden. Ich bekomme jedenfalls das Grauen, wenn ich einen C++-Quelltext sehe, in dem in jeder 15. Zeile eine Variable deklariert wird. Wenn ich ein wenig weiterlese, weiß ich gar nicht mehr, welche Variable was genau machen soll. Und wenn ich es nachlesen will, muss ich den gesamten Quelltext durchstöbern und suchen.


In Delphi ist ein Nachteil (bei größeren Projekten hauptsächlich), dass man alles "mal eben" zusammenklicken kann. Da friemelt man irgendwie eine GUI zusammen, baut hier noch was ein, und da noch was ein...
Aber wird man trotzdem in Delphi dazu verleitet, schlampig zu programmieren (im Vergleich zu C++)?
Ich denke, ich C++ ist das noch schlimmer. Hingeschmierte Einzeiler sind oft schwerer zu lesen oder zu warten als ein strukturierter Delphi-Quelltext, finde ich.

Was ich damit sagen will: Sowohl in Delphi, als auch in C++ wird man irgendwie zur schlampigen Programmierung verleitet. Aber das kann man weniger der Sprache zuordnen, sondern eher den Entwickler selbst. Denn der entscheidet ja, wie der Code aussehen soll. Und wenn er schlampig programmiert, ist das nicht die Schuld der Sprache, sondern die des Entwicklers. Und im Endeffekt ist Vieles auch noch eine Geschmacks- bzw. Gewohnheitsfrage... ;)

[supermuckl]

Zitat:

In Delphi ist ein Nachteil (bei größeren Projekten hauptsächlich), dass man alles "mal eben" zusammenklicken kann. Da friemelt man irgendwie eine GUI zusammen, baut hier noch was ein, und da noch was ein...

und genau das zeichnet delphi positiv aus, da man damit produktiver sein kann.

[Daniel Schuhmann]

Zitat:

Zitat von Hubble

In C++ schreib ich mir immer erst ein Objekt welches die Daten hält und schau dann weiter.
In Delphi kommt erst die Graphik. Ich gebe unverholen zu, daß Delphi VC++ in Sachen Graphik weit überlegen ist, aber das ist auch oft das Problem. Der Chef sieht nen Dilaog und denkt "Ah is ja schon fertig" und schon wird noch mehr gepfuscht.

Das ist dann aber wohl eher ein Kommunikationsproblem als ein Problem der Programmiersprache bzw der IDE. Ich finde die Reihenfolge Oberfläche bauen und dann ausprogrammieren wesentlich intuitiver.

[tommie-lie]

Zitat:

Zitat von Hubble

Ich habe nicht bahauptet, daß jeder in Delphi schlampig programmiert sondern das man nur verleitet wird schlecht zu programmieren.

Ich weiß, was du behauptet hast. Dennoch sehen es wohl die wenigsten gerne, wenn "ihre" Sprache als eine Sprache bezeichnet wird, die Unordnung anzieht ;-)

Zitat:

Zitat von Hubble

In C++ fällt es mir wesentlich leichter Ordnung zu halten.

Meine Meinung als Programmierer, der sich einbildet, beide Sprachen gut zu können (der aber trotzdem C++ sympathischer findet): Bei C++ ist es auch nötiger, Ordnung zu halten.

Zitat:

Zitat von Hubble

Die Delphi Projekte an denen ich mirarbeite oder mitgearbeitet habe waren allesamt schlecht durchdacht und unsauber implementiert. Weils eben so einfach ist mal nen neuen Grid mit Schnickschack in den Dialog reinzuhängen der dann auch die Daten darin speichert.

Das ist in der Tat ein Problem.

Zitat:

Zitat von Hubble

Ich versuche immer möglichst viel im Stack abzulegen, der is schneller als der heap ist einfacher zu Verwalten vom Betriebssystem.

Der Stack ist beim Zugriff weder schneller noch langsamer, iss ja auch nur Speicher, der die gleichen Zugriffszeiten hat wie der Chip daneben ;-)
Wie gesagt, die Allokierung mag beim Stack tatsächlich größer sein, ich würde den STack aber nicht für etwas größeres missbrauchen.Was mir an den Objekten auf dem Stack gefällt, ist, daß ich einfach mit arbeiten kann, ohne mir Gedanken zu machen. Ein wenn man sich einen Huafen Hilfsklassen deklariert hat, verwaltet man sich in Delphi erstmal einen Wolf. In C++ schreibt man einfach die Variable hin und gut iss, das ist sehr angenehm.

Zitat:

Zitat von Hubble

Ja das stimmt, aber in Delphi werden alle mit create erzeugten Objekt dann nicht automatisch gelöscht sondern schwirren weiterhin irgendwo im Speicher rum.

Stimmt, jetzt, wo du's sagst... Steht in der Hilfe anders, im Quellcode ist es aber so (das dürfte der Unterschied zwischen Theorie und Praxis sein ;-)). Sakura, ein paar tröstende Worte von dir dazu?

Zitat:

Zitat von Hubble

Kein Ahnung was eine ABI ist

Application Binary Interface. In Delphi sind dir vielleicht DCUs aufgefallen, das sind vorkompilierte Pascal-Dateien. Kommt Borland auf die Idee das Binärinterface dieser Dateien zu ändern, kannst du eine solche DCU nicht mehr mit zur nächsten Compilerversion mitnehmen. Ähnlich sieht es mit C++ aus. Als mit dem G++ 4.0 eine neue ABI eingeführt wurde, durften C++-Bibliotheken neu kompiliert werden, weil die Datenstrukturen schlichtweg nicht mehr kompatibel waren.

Zitat:

Zitat von Hubble

Will man dann eine alte Version des Programms damit erstellen dann knallts.

Ja aber inwiefern knallt es denn? Was sind die Effekte? Fehlermeldungen? Mir fällt auf Anhieb nichts diesbezüglich ein, deswegen frage ich.

Zitat:

Zitat von alzaimar

Zurück zu Delphi: Gerade die Freiheit, zu frickeln, globale Variablen zu verwenden (was ist daran verwerflich? soll ich eine dämliche Klasse für eine globale Variable verwenden?), Assembler einzuschleusen etc. etc. etc. macht Delphi doch zu einem professionellen Tool, so wie eine SQL-DBMS oder ein richtig gutes Küchenmesser. Ich habe die Wahl! Hurra! Ich bin autark! Frei in der Wahl der Waffeln! Bei Java und den anderen reinen OOPS bin ich eingezwängt und muss zeitaufwändig auch die kleinesten Frickeltools 'designen', :kotz: .

Ich kann bei C++ ebenfalls globale Variablen einführen und Assembler-Code inlinen. Globale Variablen halt ich persönlich für unschön. Ja, ich führe meine Variablen lieber als Member meiner Fenster-Klasse hinzu, wenn ich keine andere Wahl habe, bevor ich im globalen var-Bereich meine eigenen Variablen unter Form1 deklariere. Daß die Form aber auch nur eine Klasse ist (in die eigentlich alles rein sollte, was mit dem Fenster zu tun hat), realisieren am Anfang die wenigsten.

Zitat:

Zitat von sakura

Nur weil der Compiler hin und wieder weiß, womit er es zu tun hat und einem einige Dinge verzeiht... Was ist daran so schlecht.

Ich persönlich finde es einfach unübersichtlicher.

Zitat:

Zitat von alzaimar

Imho sind z.B. Templates keine Spracheigenschaft, sondern doch ehere eine Eigenschaft eines Präprozessors, oder?

Sie sind Teil des Standards und somit der Sprache. Ob das nun durch einen getrennten Präprozessor, einen Multipass-Compiler oder durch eine Glaskugel implementiert wird, ist erstmal egal. Makros und Templates sind aber nicht eine Eigenschaft des Präprozessors, sondern definierter Teil der Sprache.

Zitat:

Zitat von Hubble

So langsam wirds stressig. Ich glaub das nächste mal stell ich mich in unser Statdion und schweke die Bayern-Fahne, da gibts nicht so viel Haue. ;)

Du kriegst hier keine Haue. Wenn du das so empfindest, hast du andere Theads zu diesem Thema noch nicht gesehen :mrgreen:
Ich bin beispielsweise eher auf deiner Seite als auf der der Delphianer, aber ich bin kein Fanatiker, in keine der beiden Richtungen.

Zitat:

Zitat von malo

Ich bekomme jedenfalls das Grauen, wenn ich einen C++-Quelltext sehe, in dem in jeder 15. Zeile eine Variable deklariert wird.

Du liest die falschen Quelltexte von den falschen Personen.

Zitat:

Zitat von malo

Ich denke, ich C++ ist das noch schlimmer. Hingeschmierte Einzeiler sind oft schwerer zu lesen oder zu warten als ein strukturierter Delphi-Quelltext, finde ich.

Du liest immer noch die falschen Quelltexte.

Zitat:

Zitat von malo

Aber das kann man weniger der Sprache zuordnen, sondern eher den Entwickler selbst. Denn der entscheidet ja, wie der Code aussehen soll.

Das sagte schon Der_Unwissende.

Zitat:

Zitat von alzaimar

ich bin auch Koch

Gibt es auch was, was du nicht kannst? :mrgreen:

[malo]

Zitat:

Zitat von supermuckl

Zitat:

In Delphi ist ein Nachteil (bei größeren Projekten hauptsächlich), dass man alles "mal eben" zusammenklicken kann. Da friemelt man irgendwie eine GUI zusammen, baut hier noch was ein, und da noch was ein...

und genau das zeichnet delphi positiv aus, da man damit produktiver sein kann.

Betonung auf kann. Es kann auch zu einem schlimmen Albtraum werden, wenn man nicht aufpasst, und man eventuell noch "normalen Quelltext" mit GUI vermischt. Das ist einer der Nachteile. Allerdings geb ich dir insofern auch recht: Ich persönlich bastle auch oft die GUI schnell zusammen und kümmere mich dann um den Rest. Allerdings sollte man auf jeden Fall darauf achten, alles strikt zu trennen, sonst wird es schnell unübersichtlich. Ich denke, das ist es, was unser C++-Freund damit ausdrücken wollte ;)

[Daniel G]

Zitat:

Zitat von Hubble

Was ich in den letzten Jahren lernen mußte:
In Delphi wird man zum schlampigen Programmieren verleitet.

Und ein Ferrari verleitet mich zum Rasen.... :stupid:

Es liegt an dieser komischen Eiweißstruktur, die da vor dem Bildschirm an der Tastatur sitzt, ob das Endprodukt eine Katastrophe wird. Da hilft auch die schönste Sprache nichts, wenn der Programmierer ein Chaot ist. Übrigens habe ich schon einige Beispiele in C++ gesehen, wo mir schlichtweg die Galle hochkam. Es ist (meiner bescheidenen Meinung nach) wesentlich einfacher in C++ irgendetwas zu schreiben, das keiner mehr durchblickt, als in Delphi.

[Hubble]

Oh man Jungs(und Mädels)
Ist ja echt klasse was man mit ein paar Kommentaren aus einem eingeschlafenem Thread alles machen kann.

Geh jetzt schlafen und träum von C++ Monstern die gegen Delphi Mutanten kämpfen. :spin2:

Hubble

[Hubble]

Zitat:

Zitat von Sanchez

Zitat:

Zitat von Hubble

Außerdem dauerts Stunden oder Tage bis man einen neuen Entwicklerrechner mit allen Komponenten zu laufen gebracht hat.

Diese Zeit kann man sich allerdings verkürzen indem man einmalig etwas Zeit investiert und sich ein eigenes Package mit allen benötigten Komponenten basteöt. Das macht allerdings wieder Mehraufwand bei Versionswechsel der Komponenten.

Danke für den Tip, werde das bei Gelegenheit versuchen.

Hubble

[Hubble]

Zitat:

Zitat von alzaimar

Deine Argumentation impliziert, das ein DBMS eine Haufen Sch*** ist und SQL die schlimmste und unperformanteste DB-Sprache überhaupt. Warum? Weil ich mit SQL so dermassen langsame und grottenschlechte Datenbanken entwickeln kann, das jedes ordendliche Gericht die Todesstrafe (oder zumindest lebenslange Verachtung) verhängen würde. Ich hab hier gerade einen Studenten der kennt sich mit MySQL aus und hat eine MSSQL-DB hingezimmert, die mich wirklich verzweifeln lässt. "Man kann mit SQL ganz leicht hochperformante, elegante, robuste und leicht wartbare DB erstellen." man kann aber auch den größten Mist hinzimmern, den man sich vorstellen kan.

Thema Datenbank und Borland: War ja alles klasse auf den ertsten Blick(Ich spreche immer noch von Delphi 6).
So wurde vor ca. 6-7 Jahren die Entscheidung getroffen die BDE mit Paradox zu verwenden.
Die BDE war damals State of the art und sollte bis in alle Ewigkeit mit sämtlichen Datenbanken der Welt kompatibel und super wartbar sein.
Jetzt haben wir die Kiste voll mit graphischen Elementen welche die BDE nutzen. Irgendwann sind wir aber gezwungen mal auf eine richtige Datenbank umzusteigen und das heißt das Superdelphitool von damals bricht uns jetzt den Hals.
( ich bin übrigens ein häufiger Nutzer von SQL und finde gute Datenbanken klasse )

Zitat:

Zitat von alzaimar

Es kommt nicht auf das Werkzeug an, sondern auf den Anwender. Die besten Küchenmesser (ich bin auch Koch) sind sauscharf und man kann sich damit mal eben den Arm abschnippeln, ohne das man es merkt (nun ja). Sie sind aus weichem Stahl, sodass die Klinge unbrauchbar wird, wenn man damit das falsche Material bearbeitet. Ist damit das Messer Schrott? Nein! Der Anwender! Denn weichen Stahl kann ich am schärfsten schärfen. Idiotensichere Messer sind zwar idiotensicher, aber dafür kannst Du sie nach 2 Monaten wegschmeissen.

Diese Methapher passt übebrigens super. Du kannst dasselbe Messer nicht zum Braten aufschneiden und Spargel schälen (bin kein Koch) verwenden.
Ich sehe auch die Vorzüge von Delhpi. Schnelle kleine Tools welche ein Aufgabe erledigen. Ein Bericht, eine Datenbankeingabe oder ein Scannertool für Barcode.
Ich habe sogar schon überlegt ein Projekt mit Delphi und VC++ zu mixen und so beide Vorteile zu nutzen.
Meiner Erfahrung nach, sobald man am Ende mit den Großen Aktionen ist und Übersicht und Flexibilität mehr zählt als Schnelligkeit, hab ich noch nie gute Ergebnisse mit Delphi gemacht.
Liegt eventuell an den verschiedenen alten Projekten die mir verpasst wurden, ist bei mir aber so.

Ich liege im übrgigen gar nicht so extrem weit von Deiner Position weg werde wohl aber nie ein überzeugter Delphianer werden.
Wir haben uns gerade die neue Version bestellt, diese wird im neuen Jahr auch eingesetzt werden und ich hoffe auf Besserung aber überzeugt muß ich noch werden.

Ich hab da was gehört: Ist Andreas Kosch nicht gerade vom Delphi Papst zum Visual Studio konvertiert? (korrigiert mich falls das falsch ist)