Was ist FireMonkey?

[Daniel]

Ich denke, das führt jetzt ein wenig zu weit. Und wir sollten versuchen, aus persönlichen Ansichten nicht gleich "Tatsachen" formulieren zu wollen. Gerade die als vermeintlich absolut unausweichliche Konsequenz formulierte These mit den Absatzproblemen halte ich sogar für höchst kritisch, da sie nicht belegbar ist (weder in der einen noch in der anderen Richtung).

FireMonkey hatte ohne Zweifel einen schwierigen Start. Es ist seither eine Menge an Arbeit eingeflossen, noch reichlich Arbeit liegt vor den Entwicklern. Das Für und Wider einer plattform-übergreifenden GUI ist schon oft diskutiert worden. Diese Diskussion möchte ich nicht abwürgen, doch möchte ich an dieser Stelle mit dieser Diskussion wenigstens nicht wieder bei Null anfangen müssen. Wir würden uns ewig im Kreise drehen.

@Sebastian: Aus Deiner Wortwahl lässt sich herauslesen, dass Du Dich gerade "in Fahrt" geschrieben hast. Darf ich Dir einen Tee, ein Plätzchen und frische Brise zum Durchatmen servieren?

[Phoenix]

Zitat von Daniel:

@Sebastian: Aus Deiner Wortwahl lässt sich herauslesen, dass Du Dich gerade "in Fahrt" geschrieben hast. Darf ich Dir einen Tee, ein Plätzchen und frische Brise zum Durchatmen servieren?

Überhaupt nicht
War lediglich auf dem Sprung in den Zug. Jetzt bin ich grad "in Fahrt" auf dem Weg nach Hause. Und Tee und Plätzchen gibts hier im Bordrestaurant.

Mehr als Warnen kann ich nicht. Wenn jemand wirklich voll auf FM setzt wird er früher oder später merken, was er sich da angelacht hat.

Ich habe nur schon mehrfach leidsam erfahren, was es heisst auf irgendwelche wie auch immer gearteten Abstraktionsschichten zu setzen (das letzte mal bei mir war das .NET Entity Framework und die Telerik Web-Komponenten). Der Schmerz das hinterher wieder rauszuwerfen und doch mit YAGNI selber zu machen ist jedes mal nahezu gleich groß und vermeidbar gewesen, wenn man es gleich selber mit den jeweils richtigen / nativen Tools gemacht hätte.

Wir basteln jetzt auf der Arbeit einen eigenen Datenbanklayer, weil das EF zu lahm ist und Statements generiert die die Datenbank nicht versteht und die Controls selber mit jQuery, weil die Telerik-Controls zu lahm sind und in bestimmten Kombinationen miteinander integriert grandios versagen.

Den Leuten die voll auf FM setzen werden irgendwann merken dass eine solche Abstraktionsschicht eben nur genau das ist. Eine zusätzliche Schicht mit potentiell fehlerhaftem Code (= jeder Code hat Fehler, egal von wem, siehe meine anderen Beispiele oben, FM ist eben auch keine Ausnahme), die zwar vieles kann, nicht nicht alle benötigten Use-Cases von einem selber abdeckt und dennoch mit Use-Cases die man selber NICHT braucht umgehen können müssen, und deswegen schwierig anpassbar ist.

Ich will damit eigentlich nur sagen, dass jede Art von zusätzlicher Abstraktionsschicht mist ist, und dies besonders auf Schichten zutrifft, die eine so dermaßen große Fläche wie eine komplette Plattform abstrahieren müssen. Wenn das schon bei X-Browser Webkomponenten und DB-Abstraktionsschichten zu derben Problemen führt, dann ist das Problem bei Plattformen wie sie unterschiedlicher nicht sein könnten nicht kleiner, sondern größer.

[Bernhard Geyer]

Zitat von Phoenix:

Mehr als Warnen kann ich nicht. Wenn jemand wirklich voll auf FM setzt wird er früher oder später merken, was er sich da angelacht hat.

M. E. muss man sich überlegen bei einem großen Umbau ob man sich noch Desktop-Anwendungen antun will? Wieso nicht gleich eine reine Web-Lösung.

Zitat von Phoenix:

Ich habe nur schon mehrfach leidsam erfahren, was es heisst auf irgendwelche wie auch immer gearteten Abstraktionsschichten zu setzen

Eigentlich setzt man mit Delphi zu 100% auf Abstraktionsschicht. VCL - Abstrahiert GUI-Layer. Früher BDE - jetzt ADO/dbExpress: ereinheitlich teilweise den DB-Zugriff.

Zitat von Phoenix:

... gleich selber mit den jeweils richtigen / nativen Tools gemacht hätte.

Ich denke das ist das wichtigst: Prüfe es selbst und verlass dich nicht auf Marketing-Aussagen. Trifft aber auf jedliche Komponente/Framework/... zu.

Zitat von Phoenix:

Den Leuten die voll auf FM setzen werden irgendwann merken dass eine solche Abstraktionsschicht eben nur genau das ist. Eine zusätzliche Schicht mit potentiell fehlerhaftem Code

Die Frage ist was ist konstengünstiger: Eine zwischenschicht mit Fehlern oder 4 Implementierungen mit Fehlern (Objective-C - iOS, .NET - Windows Phone, ...)

[Stevie]

Zitat von Bernhard Geyer:

Die Frage ist was ist konstengünstiger: Eine zwischenschicht mit Fehlern oder 4 Implementierungen mit Fehlern (Objective-C - iOS, .NET - Windows Phone, ...)

Und die Entwickler, die sich mit allen davon gleich gut auskennen

[Darlo]

Glaubensdiskusion hin oder her. Aber warum ist Java den so verbreitet? Bestimmt nicht weil es performant, optisch schön und dazu noch ne übersichtliche Sprache ist.

[Bernhard Geyer]

Zitat von Darlo:

Glaubensdiskusion hin oder her. Aber warum ist Java den so verbreitet? Bestimmt nicht weil es performant,

Java ist nicht langsamer als Delphi. Aufgrund der GC kann es auch teilweise schneller sein. In der c't gabs mal performance-Tests zwischen C++/Java/Delphi und C#.

Einfaches Fazit: Nur bei Numbercrunshing war C## schneller.
Bei allen anderen Dingen, vor allem bei Grundkonzepten von OO war C++ letzter und die anderen drei Sprachen ähnlich schnell.

Zitat von Darlo:

optisch schön

Wie soll eine Programmiersprache optisch schön sein? Wenn du damit erzeugte GUI's meinst. Mit Swing kannst du problemlos Apps erstellen die genauso schön oder hässlich sind wie Delphi/C++/...-Anwendungen. Dieses Vorurteil hält sich weil bei vielen (kostenlosen opensource-apps) einfach nicht viel zeit auf eine schöne GUI gelegt wird.

Zitat von Darlo:

und dazu noch ne übersichtliche Sprache ist.

Ok. Es gibt einige Sprachefeatures die ich bei Delphi schöner finde. Vor allem Properties vermiss ich (Jedesmal setXX und getXX aufzurufen finde ich blöd).

[jaenicke]

Zitat von Darlo:

Glaubensdiskusion hin oder her. Aber warum ist Java den so verbreitet? Bestimmt nicht weil es performant, optisch schön und dazu noch ne übersichtliche Sprache ist.

Zufall. Die meisten weit verbreiteten Sprachen haben sich nicht durchgesetzt, weil sie in irgendeiner Weise besonders gut waren. Egal ob C/C++, Java oder PHP. Sie konnten für die gewünschten Zwecke benutzt werden und das war das Entscheidende. Ob sie das gut oder schlecht machen, war dabei zweitrangig. Insbesondere weil es nicht immer viele Alternativen gab.

Beispiel Java:
Was wäre denn die Alternative gewesen? Mir fällt auf Anhieb wenig ein. Heute sieht das anders aus, aber zu der Zeit?

Zitat von Bernhard Geyer:

Java ist nicht langsamer als Delphi. Aufgrund der GC kann es auch teilweise schneller sein.

Heute nicht, aber als ich vor 10 Jahren damit angefangen habe waren selbst einfachste Javaprogramme deutlich langsamer als Delphiprogramme und fühlten sich einfach nur "schlecht" an. Sowohl bei der Entwicklung als auch im fertigen Programm.

Wenn ich heute Java mit Lazarus vergleiche, ist Java eindeutig schneller und besser, insbesondere was die IDEs angeht. Beim Vergleich mit Delphi XE2 sieht es anders aus.

Zitat von Bernhard Geyer:

Mit Swing kannst du problemlos Apps erstellen die genauso schön oder hässlich sind wie Delphi/C++/...-Anwendungen. Dieses Vorurteil hält sich weil bei vielen (kostenlosen opensource-apps) einfach nicht viel zeit auf eine schöne GUI gelegt wird.

Richtig. Beste Beispiele sind OpenOffice oder Lazarus, wenn man sie mit den kommerziellen Pendants vergleicht. Die beiden fressen sehr viele Arbeitsstunden alleine durch die fehlende Ergonomie der Oberfläche. Wobei bei Lazarus zumindest ein wenig versucht wurde zu verbessern gegenüber Delphi 7. Zwar nichts im Vergleich zu neueren Delphis, aber immerhin.

Leider sieht es unter der Oberfläche nicht viel anders aus. Der TV-Browser ist z.B. kriechlangsam, wenn man nicht wirklich viel Rechenpower hat. Nicht weil es in Java geschrieben ist, sondern einfach weil es offenbar schlecht optimiert ist.