Ist RemObjects die Zukunft von Delphi?

[michaelthuma]

Diskussionen über Sprachfeatures sind zumeist ideologisch motiviert. Indoktrination und MS Fanboyism gehört zusammen. Das ändert mal nichts an der Nützlichkeit von LINQ. .net kann sich nicht auf viel Ruhm stützen. LINQ für ERP beim Zugriff auf mystische Welten ist schon gut. Mich stört die Integration in die Sprache, genauso wie die Generics.


Man bekommt mit WPF und Teilen von .net für Komplexe GUIs selbst über mehrere Forms ein relativ konsistentes verhalten auf schmaler Codebasis hin. Auf der anderen Seiten sind viele Konstrukte eher dem Manko - alles ist ein Objekt geschuldet. Es scheint nach außen so.

Für jeden Windows Programmier ist .net eine Entgegenkommen auf bekanntem Terrain. Delphi Pascal solange man in der eigenen Welt bleibt ist es friktionsfrei. Remobjects hat den Vorteil der Zugang zur Problemlösung ist straight.

Die Probleme die Remobjects löst sind ganz andere. In dem Sinne kann RO nicht die Nachfolge antreten. Auf einer 400m Laufbahn sind die schon eher beim Überrunden. Die laufen dann zwar wenn der Schlusspfiff kommt möglw. knapp vor den anderen ins Ziel, aber die anderen hätten noch eine Runde. Ob das subjektiv betrachtet so segensreich ist, ich als Hobbyist lege eher Wert auf Gemütlichkeit. Man kann den Fortschritt nicht einholen, aber er holt einen ein. Das ist das Paradox und deswegen ist eine Technologie nicht zu wechseln nie falsch.

Wenn in der Welt zum selben Problem viel Lösungen existieren wird über die Einengung des Geistes - das ist bei Frameworks schwingt eine Denke mit - gearbeitet. .net Progammierer tragen ab dem 2ten Jahr ein Holzfällerhemd Mir wäre dann der eher puristischere Zugang lieber. Die BASH ist eh schon genug an sich. Man bekommt mit den RO Features ganz nette Vorschläge den Code zu verbessern. So XCode like und eigentlich mehr. Das ist recht nützlich.

Zitat von Union:

Zitat von Der schöne Günther:

(PS: Warum grade immer LINQ als Heilsbotschaft von .net?)

Schreibfaulheit, wie bei Generics. Und damit man sich abhängig macht und nicht mehr weiß, was im Hintergrund tatsächlich passiert.

[Medium]

Und dann gibt es noch Leute, die mit Softwareentwicklung ihr täglich Brot verdienen müssen...

[Phoenix]

Zitat von michaelthuma:

Diskussionen über Sprachfeatures sind zumeist ideologisch motiviert. [...] .net kann sich nicht auf viel Ruhm stützen. LINQ für ERP beim Zugriff auf mystische Welten ist schon gut. Mich stört die Integration in die Sprache, genauso wie die Generics. [...]
ich als Hobbyist lege eher Wert auf Gemütlichkeit.
[...]
Mir wäre dann der eher puristischere Zugang lieber. Die BASH ist eh schon genug an sich.

Dann stehst Du vermutlich auch auf esoterische Programmiersprachen wie Whitespace oder Brainfuck? Viel puristischer geht es ja kaum noch.

Zitat von Medium:

Und dann gibt es noch Leute, die mit Softwareentwicklung ihr täglich Brot verdienen müssen...

Das ist eher der Punkt. Es geht bei der Sprachentwicklung primär um usability und ease of use.

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.

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.

[Union]

Zitat von Phoenix:

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.

[Phoenix]

Zitat von Union:

Zitat von Phoenix:

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 von Phoenix:

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.

[jaenicke]

Zitat von mquadrat:

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 von jaenicke:

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

[jaenicke]

Zitat von Furtbichler:

Dies nun als Argument anzuführen, das Linq/Delphi/You name schlecht ist, ist schlecht.

Dass es schlecht sei, habe ich ja auch nicht geschrieben. Ich nutze es ja selbst ganz gerne mal (wohldosiert...).

Ich meinte damit nur, dass es damit einfacher ist schlecht lesbaren und dafür kompakten Code zu erzeugen als ohne. Das hat aber nichts damit zu tun, dass es schlecht wäre oder nicht, das war einfach nur eine ungewertete Feststellung.