Ist RemObjects die Zukunft von Delphi?

[Phoenix]

Zitat:

Zitat von Union (Beitrag 1250844)

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Jede Zeile die ich als Entwickler nicht mehr schreiben muss, ist schonmal eine Zeile weniger die einen Bug enthalten könnte und eine Zeile weniger die ich testen muss.

Jede Zeile die ich auf diese Art und Weise spare wurde von jemand anders geschrieben und ich habe auf Bugs in den Compilern / Frameworks nur begrenzt Einfluss.

Prinzipiell korrekt. Nur wenn man das konsequent durchzieht müsstest Du ja erstmal anfangen Deinen eigenen Compiler zu bauen.

Nun kann man aber zum glück davon ausgehen, das ein Compiler der z.B. von Microsoft bereitgestellt wird - genauso wie das .NET Framework - eine extrem intensive QA durchläuft. Trotzdem durchgerutschte Bugs fallen bei einer Nutzerbasis in der Größenordnung dann aber auch eher früher als später auf und werden in aller Regel auch gefixt.

Aber ja, natürlich sind da auch tatsächlich mal Bugs drin. Ich bin auch kürzlich mal über einen gestolpert. Da gab es dann aber auch schon einen Hotfix für. Einen Webserver selber schreiben würde ich dann eben doch nicht unbedingt wollen.

[mquadrat]

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Jede Zeile die ich als Entwickler nicht mehr schreiben muss, ist schonmal eine Zeile weniger die einen Bug enthalten könnte und eine Zeile weniger die ich testen muss.

Kommt drauf an wie lesbar das ganze am Ende noch ist. Bei manchen "Vereinfachungen", die mir über den Weg gelaufen sind, muss man 10 Minuten nachdenken, bevor man verstanden hat, was der Programmierer da eigentlich gemacht hat. Dann lieber drei Zeilen mehr und man versteht es sofort. Kurz ist nicht immer besser.

[Phoenix]

Zitat:

Zitat von mquadrat (Beitrag 1250851)

Kommt drauf an wie lesbar das ganze am Ende noch ist. Bei manchen "Vereinfachungen", die mir über den Weg gelaufen sind, muss man 10 Minuten nachdenken, bevor man verstanden hat, was der Programmierer da eigentlich gemacht hat. Dann lieber drei Zeilen mehr und man versteht es sofort. Kurz ist nicht immer besser.

Stimmt, deswegen schrieb ich ja auch:

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Im professionellen (= man verdient Geld damit) Bereich ist man auf Mittel angewiesen, die Produktivität steigern und es gleichzeitig erlauben, sehr sauberen, gut les- und wartbaren Code zu produzieren der am Ende auch noch funktioniert.

;-)

[jaenicke]

Zitat:

Zitat von mquadrat (Beitrag 1250851)

Bei manchen "Vereinfachungen", die mir über den Weg gelaufen sind, muss man 10 Minuten nachdenken, bevor man verstanden hat, was der Programmierer da eigentlich gemacht hat.

Vor allem LINQ erinnert manchmal eher an Brainfuck als an C#. Ich hatte da mal ein Beispiel vor mir, da habe ich nur noch gedacht WTF. Das lag in dem Fall auch daran, dass die Variablen a bis g hießen, aber selbst nach deren Ersetzung habe ich minutenlang nachdenken müssen.

Natürlich gibt es auch schöne LINQ Beispiele, keine Frage. Aber es ist ein Beispiel für ein Feature, bei dem man mehr auf die Lesbarkeit aufpassen muss als anderswo.

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1250855)

Natürlich gibt es auch schöne LINQ Beispiele, keine Frage. Aber es ist ein Beispiel für ein Feature, bei dem man mehr auf die Lesbarkeit aufpassen muss als anderswo.

Das richtige Werkzeug in der Hand eines Kretins mutiert zum Folterwerkzeug. So gesehen ist Delphi die schlimmste Sprache, die es gibt, weil ich einmal ein Delphiprogramm gesehen habe, das ganz schlimm war.

So wie es auch C-Freaks gibt (und sogar Wettbewerbe), wie ich am meisten Funktionalität in am wenigsten Code reinquetsche (Prinzip der maximalen Boshaftigkeit), gibt es natürlich auch Frickler, die mit Linq/Delphi/You name it Dinge anstellen, die grauslig sind. Dies nun als Argument anzuführen, das Linq/Delphi/You name schlecht ist, ist schlecht.

[vagtler]

http://www.delphipraxis.net/1242331-post8.html

[p80286]

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Im professionellen (= man verdient Geld damit) Bereich ist man auf Mittel angewiesen, die die Produktivität steigern und es gleichzeitig erlauben, sehr sauberen, gut les- und wartbaren Code zu produzieren der am Ende auch noch funktioniert.

Zunächst muß der Code funktionieren, dann sollte er wartbar und verständlich sein!

Gruß
K-H

[Furtbichler]

Zitat:

Zitat von p80286 (Beitrag 1250887)

Zunächst muß der Code funktionieren, dann sollte er wartbar und verständlich sein!

Falsch. Zunächst sollte der Code verständlich und wartbar sein. Denn dann wird er auch funktionieren bzw. kann dazu gebracht werden. Es gibt eigentlich nichts Schlimmeres als die Einstellung 'Hauptsache, et läuft', das ist nämlich mit mangelndem Qualitätsbewustsein gleichzusetzen. Nicht falsch verstehen: Code muss funktionieren, nur wie man dahinkommt, ist mittlerweile ausschlaggebend und unterscheidet zwischen guter oder schlechter Qualität.

@vagtler: :thumb:

[Sherlock]

Oh, wie ich mir wünsche, Beiträge bewerten zu dürfen!
Dein Beitrag, Furtbichler, leuchtet ganz oben bei den wirklich wichtigen Beiträgen zur Software-Entwicklung.
:thumb:

Hmm, das hört sich ziemlich ironisch an, ist aber absolut ernst gemeint!

Sherlock

[p80286]

Zitat:

Zitat von Furtbichler (Beitrag 1250888)

Code muss funktionieren, nur wie man dahinkommt, ist mittlerweile ausschlaggebend und unterscheidet zwischen guter oder schlechter Qualität.

Das kann ich voll unterschreiben.

Gruß
K-H