Vorteile von Delphi

[Binärbaum]

Zitat von Hubble:

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

Ach wirklich?
Was ist z.B. bei C, wo man (unter Umständen) z.B. in der main-Funktion am Ende das "return 0;" als letzte Anweisung weglassen kann, weil sich die meisten Compiler schon denken, dass es da hin soll. Da gibt es auch noch etliche andere Beispiele, wo man nicht ganz sauber programmieren muss und das Programm trotzdem läuft, weil der Compiler implizit irgendwelche Dinge annimmt, die so eigentlich gar nicht im Quelltext stehen. Da wird man doch zum "schlampigen" Programmieren geradezu animiert.

[Hubble]

Oh weh, das ging ja schnell.

Schönen Gruß an meine 16310 Feinde.
Bin im Moment beschäftigt, werde mich aber dazu äußern.

Hubble

[Der_Unwissende]

16309 maximal

Stimme dir zwar nicht wirklich zu, aber auch nicht der Meinung der anderen hier (oh man, habe ich jetzt eine eigene Meinung? Muss ich ändern).
Ihr solltet alle mal weniger pauschalisieren, man kann genauso gut in Delphi wie in C/C++, Java, Haskell, wasWeißIch super unsauber programmieren. Das alles hat wenig mit dem Thread und natürlich auch wenig mit der Sprache an sich zu tun. Oder denkt ihr irgendwer kam mal auf die Idee sich eine Sprache auszudenken, die Krypto heißt und so kryptisch ist, dass man garnicht sauber und übersichtlich mit der arbeiten kann?
Und falls ja, habt ihr dann auch eine Idee warum es keine solche Sprache unter den so gern genannten / verwendeten? Sprachen geschafft hat?

Also ich muss sagen, dass man in C/C++ einige Konstrukte hat, die man in Delphi nicht so einzeilig hässlich nachbilden kann, aber die sind einfach super konstruiert. Mag sein das ein paar Hobbyprogrammierer denken, dass so etwas ihren Code individueller macht, aber wenn Code verifiziert werden muss oder erweitert oder verkauft oder oder oder, dann hält man sich auch in der C Welt an guten Stil.
Andersherum garantiert mir niemand, dass mein Delphi Programm wirklich sauber ist. Schon diese Funktion in einer Funktion Zeugs finde ich persönlich so super unübersichtlich (wo genau fängt jetzt eigentlich die Funktion an?), dazu kommt noch, dass ich meine Variablen deklariere bevor ich sie benutze (natürlich in C auch der Fall, aber nicht mehr in C++). Das sind natürlich imperative Überbleibsel um die ich nicht rumkomme. Macht für mich den Code nicht immer lesbarer. Das man Exceptions nicht markieren kann (throws .... á la Java) wäre auch nett und natürlich eine Prüfung ob dieser Fehler behandelt wird (ich kann in Delphi einfach übersehen).

Es gibt wirklich gute (konstruierte) Beispiele, warum C/C++ oder Delphi super schlechten Code haben, den kein Schwein lesen kann, aber wenn man sich etwas bemüht hat jede Programmiersprache das Potenzial sauberen, strukturierten und guten Code zu liefern. Keine Sprache macht einen Entwickler besser oder schlechter. Alle bieten den relativ gleichen Funktionsumfang, die Wahl (und das wurde schon oft genug gesagt) hängt doch eher von persönlichen Referenzen ab.
Und bitte hört endlich mit dem entweder oder auf, es gibt hier unter den 16310 Leuten bestimmt genug, die sowohl Delphi als auch C/C++/C#/Java/HastDuNichtGesehen benutzen und auch wissen wann und warum sie welche der Sprachen nehmen oder eben nicht. Und insbesondere die, der 16310 die auch ihr Geld damit verdienen (nicht alle aber sicherlich die Meisten) sind auch in der Lage sauberen Code zu erzeugen (Wofür gibt es denn Konventionen?)

Gruß Der Unwissende

[Sanchez]

Hallo zusammen,

Zitat von Hubble:

Hat jemand mal versucht mit der VCL in verschiedenen Threads zu arbeiten?
Is nich einfach, wenns überhaupt geht. Man muß immer drauf achten zyklisch ein ProzessMessages
auszuführen sonst steht das ganze Programm 100 Jahre falls eine VCL Event nicht beendet wird.
Wird dann ein zweites ausgelöst, dann ist das erste Event unterbrochen bis das zweite fertig ist.

Ja, schon des öfteren. Solange du den Hauptthread nich völlig auslastest, brauchst du kein ProcessMessages.
In einem seperaten Thread hat so ein Aufruf überhaupt nix verloren. Vermutlich meinst du damit,
dass synchroninisierte Aufrufe um auf die VCL zuzugreifen den Thread hängen lassen, solange der Hauptthread
im Stress ist. Das ist dann aber IMHO ein Design-Fehler. Wenn ich schon mit Threads arbeite, dann lasse ich den
Hauptthread nicht schuften, sondern einen eigenen Thread.

grüße, daniel

[Hubble]

Zitat von Hubble:

Und die VCL ist nur für procedurale Vorgehensweise aus dem letzten Jahrhundert geeignet.

Ziehe diesen Satz von mir vollständig zurück!

Zitat von tommie-lie:

Zitat von Hubble:

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

Mit dieser Aussage hast du dir in diesem Forum jetzt circa 16310 Feinde geschaffen

Ich habe nicht bahauptet, daß jeder in Delphi schlampig programmiert sondern das man nur verleitet wird schlecht zu programmieren. In C++ fällt es mir wesentlich leichter Ordnung zu halten.
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.
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.

Zitat von tommie-lie:

Zitat von Hubble:

Soweit OK aber dann:In delphi muß ich erst mal var schreiben dann die Instanz erzeugen,
initialiseiren dann wieder löschen und zu allem Überfluß hockt das
blöde Teil nicht auf dem schnellen Stack sondern auf dem lahmen heap

Schnell/Lahm? Wenn der Speicher einmal allokiert ist, ist mir das auch egal.
Außerdem ist die Geschichte mit "var" nur eine Syntaxeigenschaft von Pascal. Du legst da übrigens eine lokale Variable an, soviel zu globalen Variablen.

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

Zitat von tommie-lie:

Zitat von Hubble:

das wars? Nein denn was is wenn ne Exception ausgelöst wird

Was, wenn in deinem C++-Beispiel eine Exception ausgelöst wird?

In C++ wird bei allen auf dem Stack erzeugten Objekten der Destruktor ausgelöst und die Exception automatisch weitergeworfen. (Wie in diesem Beispiel)
Macht man das gleiche in Delphi ohne try except , dann würde das Objekt nicht gelöscht und immer mehr Speicherlöscher entstehen.

Zitat von tommie-lie:

Zitat von Hubble:

Damit hätten wir 7 unübersichtliche Zeilen in Delphi und 1 Zeile in C++.
Und falls die Exception weiter geworfen werden muß, dann kommen noch ein paar Zeilen dazu.
In Delphi muß man einfach in jeder Routine Exceptions fangen, falls auch nur ein
Objekt benutzt wird, und diese Exception weiterschmeißen.

Exceptions werden auch in Delphi bis zur nächstinnersten Exception-Behandlung weitergereicht.

Ja das stimmt, aber in Delphi werden alle mit create erzeugten Objekt dann nicht automatisch gelöscht sondern schwirren weiterhin irgendwo im Speicher rum.
Hatte bisher nie Probleme mit Exceptions. Erst seit dem in Delphi code hab ich Probs mit Expetions.

Zitat von tommie-lie:

Zitat von Hubble:

Also: Man drückt auf Button 1 und bevor dieser fertig ist auf Button 2. Grande Problema in VCL.
Natürlich gibt es da einen Workaround, ist aber sehr umständlich und man muß fast alles umstellen.

Ja, ziemlich eklig, ist aber in C++ prinzipiell nicht anders, wenn du eine Bibliothek zum Anzeigen von grafischen Controls benutzt, die nicht multi-threaded ist. Oder du spaltest dir gleich beim Drücken von Button1 ein ganz sauber einen Thread ab und lässt den werkeln, dann sollte auch Button2 reagieren, und wenn du dort selbiges machst, laufen am Ende zwei Threads. Dabei sind selbstveränstlich die üblichen Vorkehrungen gegen Race Conditions und anderweitige Synchronisierungprobleme zu treffen.

Korrekt

Zitat von tommie-lie:

Zitat von Hubble:

Habt Ihr schon mal mit Komponenten in Delphi geschafft. Is echt supi. Alles schnell und schön.
Aber wehe es gibt ein Update und die Entwickler müssen mit verschiedenen Versionen arbeiten.
Ist schlicht nicht möglich.

Inwiefern? Wenn sich die ABI ändert, bist du unter C++ genauso verloren, wenn deine Bibliothek lediglich als binary-only vorliegt.

Kein Ahnung was eine ABI ist, auf jeden Fall gibts hier immer Ärger wenn mal wieder neue Versionen von den ganzen Komponenten gibt. Will man dann eine alte Version des Programms damit erstellen dann knallts.
Natürlich gibt's in VC weniger Möglichkeiten und ich habe damals weniger Komponenten in dieser Art verwendet, aber die Thematik ist mit Delpho 6 nicht gut gelöst. Ich hoffe die Neuen Versionen beheben solche Probleme.
Außerdem dauerts Stunden oder Tage bis man einen neuen Entwicklerrechner mit allen Komponenten zu laufen gebracht hat.

Hubble

[alzaimar]

Hubble: Deine Meinung ist fundiert, aber die Argumente sind ungenau und nicht zuende gedacht (imho). Aber so ist das: 2 Leute, 2 Meinungen. So, jetzt aber, Du Schuft :
1. Mit Delphi schlampig programmieren.
Absolut korrekt. Aber: It's not a bug, it's a feature. Ich kann mit Delphi sehr schnell ein funktionierendes und stabiles Programm zusammenklicken. Wirklich sehr schnell. Neulich habe ich einen Reportgenerator mit 1000 Bells&Whistles in 30 Minuten zusammen geklickt. Auf der anderen Seite wird man in Delphi auch absolut katastrophale Frickelsoftware erstellen können, die nich nicht mal das 'S' in 'Software' wert ist. Ist das eine Schwäche von Delphi? Nun, da kann man geteilter Meinung sein. Programmiersprachen, mit denen man zwangsweise stabile Programme schreibt, sind natürlich für Anfänger und Frickelchaoten die richtige Wahl, aber nicht für mich, denn ich programmiere seit 30 Jahren.

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.

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.

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', .

Die besten Werkzeuge lassen dem Anwender die größte Freiheit!

2. Die vielen Komponenten
Ich hatte früher 100+ Komponentensammlungen installiert und fand mich richtig cool. Bis ich auf D4 wechseln musste. Dann war Schluss. Ich verwende eine 2 Sammlungen, aber die Richtigen. Ähnliches für C++ (VC++) kosten das 10 fache und sind dann nur halb so gut, ehrlich.
Wie gesagt, ich muss die vielen Features nicht verwenden, aber ich kann. Ich kenne andere IDE nicht, aber die Komponentensammlungen sind nicht so verbreitet, oder? Mit .NET kann Alles anders werden (.NET wurde übrigens vom VCL-Erfinder Anders Heijlsberg entwickelt. Der wurde *gerade wegen der Eleganz der VCL* von Microsoft abgekauft, das nur mal so am Rande).

Ich glaube, der VCL-Ansatz (eine ordendlich durchstrukturierte Klassenbibliothek) macht Code erst stabil. Was Du meinst, sind die 'SysUtils' etc. Units, die eben Prozeduren anbieten. Mein Gott, muss Alles gleich OO sein?

Noch was zu OOP: "Die reine Leere, ist meistens die reine Lehre"

[Sanchez]

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.

[Hubble]

@alle

Wollte Euch nicht Euer Delphi nehmen sondern nur mal die echten Probs ansprechen.
Mir ist egal ob ich begin oder { schreibe.
Selbst an die komische Syntax beim else mit und ohne Strichpunkt kann ich mich gewöhnen.

Da gibt andere Probs:
mäßiges exception handling
schlechte Pointernutzung
VCL nicht Threadfest
Objekte können nur mit .create erzeugt werden und wieder gelöscht werden
Klassen und Ausprogrammierung sind immer getrennt
nicht ausgereifte Projektverwaltung
keine STL
keine echten Templates

Das sind die Fakts die mir in Summe Delphi verleidet haben. Denn anfangs war ich durchaus begeistert von Delphi weil alles zu schnell und einfach ging. Aber mit der Zeit...

Hubble

[sakura]

Zitat von Hubble:

mäßiges exception handling

Stimmt imo nicht, aber wenn man nicht weiß, wann man try..except und wann try...finally nutzt, dann mag man das so sehen.

Btw, Dein Bespiel mit automatischer Objektfreigabe kann man auch in Delphi 6 bauen.

Zitat von Hubble:

schlechte Pointernutzung

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

Zitat von Hubble:

VCL nicht Threadfest

Ist WinForms auch nicht, und das ist richtig neu Da muss man auch aufpassen wer wann welche Control manipulieren darf. Es ist aber, zugegeben, schon viel eleganter gelöst.

Zitat von Hubble:

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

Mit Create löscht man keine Objekte. Aber ich denke mal, Du hast Dich hier beim Schreiben überrannt. Und wie gesagt, wer sich mit Delphi auskennt, der weiß auch, wie man die von Dir aufgeführte Limitierung umgeht. Zugegeben, der Ansatz über den Stack hätte Delphi auch nicht schlecht getan, aber dann wiederum gibt es auch Gegenargumente

Zitat von Hubble:

Klassen und Ausprogrammierung sind immer getrennt

Das ist die strukturierte Sprache Pascal und einfach eine Glaubenssache. Da kann man nicht diskutieren - so ist es einfach

Zitat von Hubble:

nicht ausgereifte Projektverwaltung

Die ist bestimmt noch nicht alles was es sein könnte, aber schon viel besser in der aktuellen Version.

Zitat von Hubble:

keine STL

Nun gut, und warum brauche ich die in Delphi - oder anders, was machst Du mit der, was Du in Delphi nicht tun kannst.

Zitat von Hubble:

keine echten Templates

Stimmt, aber kommt Zeit kommen Lösungen. Und da habe ich schon perverse für gesehen

Zugegeben, ich liebe Delphi, aber ich diskutiere auch gerne die Für und Wider von Delphi. Also, ich warte auf Deine Antworten

......

[alzaimar]

Es *gibt* ja IDE die das eine oder Andere besser machen z.B. Templates, oder wenigstens einen Präprozessor, aber automatische Objektfreigabe ist ja wohl der größte Dreck, den ich kenne. Eine Java Applikation eines Praktikanten ist gerade deshalb nicht zu gebrauchen. Und das einzige Projekt, das ich nicht bugfrei bekomme, arbeitet mit automatischer Objektfreigabe.

Trotzdem sind die Argumente durchaus eine Überlegung wert, aber leider fängst Du mit der Sprache Delphi an und hörst dann mit der Borland IDE auf. Imho sind z.B. Templates keine Spracheigenschaft, sondern doch ehere eine Eigenschaft eines Präprozessors, oder?

Welche IDE ist denn nun wirklich Besser? Ich steig ja gerne um, zumal D2005 wohl etwas wackelig daher kommt und D2006 die Marktreife noch nicht bewiesen hat....