Ist Delphi so Bedeutungslos ?

[sh17]

Ich bin eigentlich noch nicht in die Not gekommen, bei Emba direkt Support in Anspruch zu nehmen. Und wenn das wg eines Bugs in Delphi so wäre, sieht man ja, was daraus wird. Mit gefällt halt nur nicht die Richtung von Delphi. Immer mehr Komponenten von Drittherstellern werden einverleibt bzw andere geben die Unterstützung komplett auf. Und da sind viele gute Komponenten dabei. z.B. TPrintPreview. Das sieht man schon an den Indy-Komponenten. Ich möchte die nicht in der IDE. Ich möchte den aktuellen Trunk verwenden und selbst entscheiden. Nur setzen andere Teile in der IDE wieder auf den Indys auf, also kann ich hier Verrenkungen mit Pfaden usw. anstellen. Ich möchte eine IDE mit ordentlichem Compiler, Debugger und den Grundlagen - meinetwegen VCL oder FireMonkey. oder QT oder oder. Aber alles andere...

Mein Idee war nur eine zweite Firma mit mehr Interesse für den Kunden am Markt zu platzieren, die Support für FPC mit (irgend einer) IDE für finanzielle Entlohnung bietet. Wobei FPC soweit geändert wird/wurde, um Delphi-Projekte/Kunden direkt abgreifen zu können. Quasi als ernstzunehmende Alternative. RemObjects machts vor - finde ich

[Unx]

Zitat von cookie22:

Zitat von JamesTKirk:

...Und hier gibt es ein paar Punkte, die by-design nicht Delphi kompatibel sind, da im Gegensatz zur VCL die LCL nicht nur auf Windows lauffähig ist. Du kannst zwar rein prinzipiell die VCL nach ein paar Korrekturen mit FPC kompilieren (habe ich mal mit der VCL von Delphi 6 gemacht), aber was nützt es dir großartig? Du bist dann weiter an Win32 (vlt auch Win64) gebunden und hast nur den Compiler ausgetauscht...

Genau das ist das größte Problem von FPC/Lazarus. Cross-Platform auf Biegen und Brechen.

Einen der größten Vorteile von Delphi, nämlich die Unmenge an Komponeten kann Lazarus nicht für sich nutzen. Die meisten Kompos laufen gar nicht oder müssen mühevoll angepasst werden. Damit schießt sich Lazarus selbst ins bein.

Schon mal probiert deine unmengen an Komponenten in FireMonkey zu nutzen?
Damit schießt sich Delphi wohl nach deiner Ansicht auch selbst ins bein.

[cookie22]

Von FireMonkey halte ich im jetztigen Zustand rein gar nichts. Man kann es kommerziell nicht nutzen. Ausserdem wäre ein Wrapper für Native Controls mir da wesentlich lieber als der geskinnte Kram. Zumindest könnte Emba entsprechende Skins mitliefern, aber nicht mal dazu reicht es.

Der Unterschied zwischen Cross-Platform bei Lazarus und Delphi ist, dass wenn sich FM durchsetzt, die kommerziellen Kompos auch nach FM portiert werden.

[Union]

Zitat von cookie22:

Der Unterschied zwischen Cross-Platform bei Lazarus und Delphi ist, dass wenn sich FM durchsetzt, die kommerziellen Kompos auch nach FM portiert werden.

Portieren geht wohl kaum - das wäre bei den meisten Komponenten eine komplette Neuentwicklung. Ist Dir schon mal aufgefallen, dass die einzigen die für FM was halbwegs nutzbares rausgebracht haben, diejenigen sind deren Komponenten mit XE3 mitgeliefert werden? Da wurde bestimmt ordentlich Druck ausgeübt, "wenn ihr das nicht liefert, ersetzen wir Euch in der nächsten Version".

[Unx]

Eigentlich sieht es düster aus mit Komponenten für FireMonkey.

OpenSource Komponenten ala JVCL wird es sicher nicht mehr geben.
Wer kauft sich schon eine immer teurer werdende Arbeitsumgebung um Komponenten aus Spass und Freude zu entwickeln?

So kann eigentlich keine Community um FireMonkey herum entstehen.

Embarcadero schiebt sich so selbst in eine Sackgasse wenn sie keine freie FireMonkey Community Edition herraus bringt,
den von den entstehenden OpenSource Projekten hätten wir kommerzelle Nutzer auch einen Nutzen.

[QuickAndDirty]

Zitat von Unx:

Embarcadero schiebt sich so selbst in eine Sackgasse wenn sie keine freie FireMonkey Community Edition herraus bringt,
den von den entstehenden OpenSource Projekten hätten wir kommerzelle Nutzer auch einen Nutzen.

Emba lebt vom Login Effekt.
Aber ich glaube nicht einen Meter weit das OpenSource Projekte sooo hilfreich sind.
Manche ja.
Aber wenn man sieht wie dann alles unter GPL kommt hilft das nur bedingt.
Und selbst wenn es ne brauchbare Lizenz bekommt ist das Lizenz-Wirrwar doch recht Groß...zum Teil ein Lizenzmodell je Komponente.

Wäre cool, wenn TApplication und TServiceApplication ein Urheber-property eingebaut hätten so das alle Komponenten die das als Teil ihrer Lizenz haben sich da selbstständig so registrieren das der Author zufrieden ist.

[Dalai]

Zitat von QuickAndDirty:

Emba lebt vom Login Effekt.

Meinten Sie "Vendor Lock-in"?

MfG Dalai

[QuickAndDirty]

Zitat von Dalai:

Zitat von QuickAndDirty:

Emba lebt vom Login Effekt.

Meinten Sie "Vendor Lock-in"?

MfG Dalai

Ja ich habe mich verschrieben.
http://de.wikipedia.org/wiki/Lock-in-Effekt

"The Windows API is so broad, so deep, and so functional that most ISVs would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead..."
"It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO, our lack of a sexy vision at times, and many other difficulties [...] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move."
"In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago."

-Microsofts Manager für C++-Entwicklung Aaron Contorer


So ähnlich läuft das auch mit Delphi.

[Codehunter]

Zitat von QuickAndDirty:

In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago.

Hätte nicht gedacht, dass die so selbstreflektierend sein können. Grad an dem "Franchise" haben sie aber damals mit dem .Net gerüttelt als sie die Standards offenlegten. Ich hatte damals schon fast an "Universal Binaries" geglaubt, als das Projekt Mono bekannt wurde. Und heute? Haben sie aus .Net ein noch größeres Monstrum gemacht als aus dem WinAPI.

Ich glaube, alle Versuche seitens Borland/Codegear/Emba dagegen anzustinken mit VCL, CLX, FMX und was weiß ich noch für Buchstaben, werden an den begrenzten Kapazitäten seitens der jeweiligen "Delphi-Firma" scheitern. Darum denke ich dass es ein Kardinalsfehler ist, bei Delphi durch immer neue plattformunabhängige Frameworks punkten zu wollen. Die Stärken von Delphi waren mal die Datenbanken. Da liegt auch der Fokus der meisten professionellen Anwender. Also anstatt immer weiter Ressourcen in die Pflege irgendwelcher Cross-Plattform-Frameworks zu stecken, sollte man sich lieber auf seine Kernkompetenzen beschränken.

Für MacOS, iOS, Linux usw. muss man nicht zwangsläufig die eine Delphi-IDE immer weiter aufblasen sondern kann auch ein separates Produkt hinstellen. Wer es braucht der kaufts, wer nicht der lässt es. So müssten wenigstens nicht die Windows-Datenbank-Entwickler die Apple-Experimente seitens Emba mitfinanzieren, woraus sich ja die derzeitigen Mondpreise ergeben.

[bernau]

Zitat von Codehunter:

Darum denke ich dass es ein Kardinalsfehler ist, bei Delphi durch immer neue plattformunabhängige Frameworks punkten zu wollen. Die Stärken von Delphi waren mal die Datenbanken.

Sehe ich anders. Delphi kann auch datenbanken. Aber grade die Flexibilität auch andere Programm (grafische, wissenschaftliche, Tools etc) zu schreiben, ohne die Programmiersprache zu wechseln, ist das Plus von Delphi. Sonst wäre DBase heute das Top Produkt.

Zitat von Codehunter:

Da liegt auch der Fokus der meisten professionellen Anwender.

Nö. Da bin ich komplett anderer Meinung. Der Fokus liegt auf Plattformunabhängigkeit. Das ist die Zukunft.