Ist Delphi so Bedeutungslos ?

[musicman56]

Zitat von Perlsau:

Zitat von p80286:

Einspruch Euer Ehren, dann wäre MS nie das geworden was es heute ist. Der Kunde muß glauben, daß ein Produkt gut für ihn ist, und das ist sehr subjektiv.

Und diesen Glauben erwirkt man durch? Richtig! Marketing!

Schön langsam wird aus dieser Erkenntnis wohl auch der Schluss: Solange die "bestehenden" Delphi-Entwickler glauben ein gutes Produkt in den Händen zu haben, solange wird Delphi nicht in der Bedeutungslosigkeit verschwinden. Denn die Delphi-Gemeinde ist nach wie vor groß, und diese erst mal zu behalten wäre wohl aus Marketing-Sicht von Emba die erfolgreichere Strategie, als jedes Jahr eine neue Version mit neuen Bugs herauszubringen, und dabai darauf zu schielen, was andere Sprachen oder Entwicklungsumgebungen können.

Es liegt mir fern, Emba gute Ratschläge erteilen zu wollen, die werden schon selber den (aus ihrer Sicht) richtigen Plan haben. Man möge dabei aber mal bedenken: Sich auf die eigenen Stärken zu besinnen, hat noch niemandem geschadet.

[Bernhard Geyer]

Zitat von musicman56:

Sich auf die eigenen Stärken zu besinnen, hat noch niemandem geschadet.

Das Problem ist aber mittlerweile das eine Kernstärke: "Sehr gutes RAD-Tool für Windows" an Bedeutung verliert. Hat man mit schon im Serverbereich (Terminal Services und Co. außen vor) keinerlei Relevanz (Linux und Co. im bereich Webserver lassen Grüßen) so ist mit der Smartphone/Tablet-Entwicklung ein weitere Bereich entstanden bei dem Delphi einen bedeutungslosen Stand hat.

[musicman56]

Zitat:

Das Problem ist aber mittlerweile das eine Kernstärke: "Sehr gutes RAD-Tool für Windows" an Bedeutung verliert.

Da stimme ich dir zu. Aber, Emba hat es IMHO versäumt, sich konsequent in Richtung "Windows" weiter zu entwickeln. Wenn man beispielsweise die Energie die man in FM gesteckt hat, in eine 64-Bit IDE gesteckt hätte, dann könnte man beispielsweise auch mal eine Projektgruppe komplett compilieren, ohne dass die IDE abschmiert.

Der Trend mag ja allgemein hin zu "mobile Apps" gehen, aber in Firmen und Betrieben werden nach wie vor PC's laufen. Vermehrt in einer 64-Bit-Umgebung. Ich bin auch überzeugt davon, dass sich ein Großteil der Delphi-Programmierer noch mehrheitlich mit Windows beschäftigt. Das ist der "Kernel" der Delphi-Programmierer, und die hat man sträflich vernachlässigt. Zu Gunsten einer Pseudo-Multi-Plattform-Entwicklungsumgebung die schon aus Ihren Grundsätzen heraus so niemals funktionieren kann und wird.

[Bernhard Geyer]

Zitat von musicman56:

Da stimme ich dir zu. Aber, Emba hat es IMHO versäumt, sich konsequent in Richtung "Windows" weiter zu entwickeln. Wenn man beispielsweise die Energie die man in FM gesteckt hat, in eine 64-Bit IDE gesteckt hätte, dann könnte man beispielsweise auch mal eine Projektgruppe komplett compilieren, ohne dass die IDE abschmiert.

Das Speicherproblem ist vermutlich uralt. D6 müllt nach ca. 30 Projekten den Speicher auch soweit zu das man die IDE neu starten muss.

Zitat von musicman56:

Der Trend mag ja allgemein hin zu "mobile Apps" gehen, aber in Firmen und Betrieben werden nach wie vor PC's laufen.

Das schon. Jedoch mit den Smartphone/Tables kommt diese Zweit verstärkt im Firmenumfeld. Es ist einfach mit einem 500g Tablet Checklisten an fertigen Produkten Durchzugehen als wenn man wegen des Gewichts Papierchecklisten drucken muss um diesen Zeitaufwendig wieder in Elektronische Form zu bringen.

Zitat von musicman56:

Vermehrt in einer 64-Bit-Umgebung.

Für >90% der Anwendungsfälle tut es auch eine 32-Bit App im 64-Bit Umfeld.

Zitat von musicman56:

Ich bin auch überzeugt davon, dass sich ein Großteil der Delphi-Programmierer noch mehrheitlich mit Windows beschäftigt.

Klar doch, jedoch sind genügend schon gewechselt weil sie nur Windows bedienen können.

Zitat von musicman56:

Das ist der "Kernel" der Delphi-Programmierer, und die hat man sträflich vernachlässigt.

64-Bit kann ich bestätigen. Aber sonst? Welche teile der Windows-Welt die neu dazu gekommen sind wurden nicht bedient?

Zitat von musicman56:

Zu Gunsten einer Pseudo-Multi-Plattform-Entwicklungsumgebung die schon aus Ihren Grundsätzen heraus so niemals funktionieren kann und wird.

Sie kann funktionieren wenn man es richtig und konsequent macht. Dies ist jedoch keine Lösung die man in 1-2 Wochen entwickelt.

[DSCHUCH]

Zitat von Bernhard Geyer:

Das Problem ist aber mittlerweile das eine Kernstärke: "Sehr gutes RAD-Tool für Windows" an Bedeutung verliert. Hat man mit schon im Serverbereich (Terminal Services und Co. außen vor) keinerlei Relevanz (Linux und Co. im bereich Webserver lassen Grüßen) so ist mit der Smartphone/Tablet-Entwicklung ein weitere Bereich entstanden bei dem Delphi einen bedeutungslosen Stand hat.

so ähnlich denke ich auch. delphi punktet sehr eingegrenzt auf GUI entwicklung. dort ist es auch sehr gut, seit jahren größtenteils kompatibel, wie MEising auch geschrieben hat. unsere codes und oberfläche sind zT vor 2000 entstanden und mit minimalsten aufwand bis heute portiert.

allerdings hört(e) es dann sofort auf. weder web, noch server, wie bernhard sagt. bedeutet : für jede komplexere anwendung fängt man an technologien zu mischen, was einfach unglücklich ist, dann sucht man natürlich nach einer umgebung, die mehr erfordernisse erfüllt.

davon abgesehen das wir und auch andere firmen die ich kenne, delphi eigentlich nur als compiler benutzen, da keine der mitgelieferten komponenten für größere anwendung taugt(e) (bzw man massig funktionen nachimplementieren mußte)

* skinning -> DevExpress
* vernünftige DB Grid -> DevExpress (gibt noch andere, braucht man qualität hat man aber schnell nur noch 2-3)
* datenbankanbindung -> DevArt, UniDAC, etc pp
* report generatoren (es gab IMHO noch NIE einen vernünftigen in Delphi, jetzt FR ist der erste, benutzen wir schon seit dem erscheinen) -> Fast Report, List und Label, etc
* Vernünftiges Build tool (FinalBuilder)

Resultat von dem ganzen ist, das eine Entwicklerlizenz mittlerweile nicht 2000€, sondern bald 5000€ kostet, wo man wirklich langsam umfällt, habe ich auch schon öfters mit dem vertrieb vom EMB ausgewertet...

derzeit gab es ja viel bewegung. man muß schauen, wieviel aufgeholt wird, das derzeitige konzept ist zweifelos gut, multiplattform, servertechnologien, problematisch nur das alles noch im beta status ist und zu häufig klimbert und nicht wirklich rund. man benenne nur das leidige thema datasnap, funktioniert bei uns jetzt auch gut, aber der leidensweg war so lang und teuer, das wir mit sicherheit die nächste zeit nicht wieder so blauäugig eine neue technologie vom EMB einführen werden und wieder zum alten konzept "kaufe externe komponente" zurückkehren werden.

[stahli]

Ich halte den Ansatz von FMX auch für gut. Die Probleme stecken im Detail.

FMX finde ich unnötig kompliziert aufgebaut und außerdem ist es natürlich unfertig.
Die Styles sollten in der jetzigen Form wieder abgestellt und durch ein einfaches Skinning zum Zeichnen von Rahmen und Flächen ersetzt werden (wird sicher nicht passieren).

Ich hoffe, dass EMB das Framework nochmal grundlegend überholt, auch wenn eine Abwärtskompatibilität damit nicht mehr gegeben wäre.
FMX könnte die Zukunft werden, aber noch nicht in der aktuellen Form.

[cookie22]

Zitat von Bernhard Geyer:

Aber sonst? Welche teile der Windows-Welt die neu dazu gekommen sind wurden nicht bedient?

Metro ist wohl das beste Beispiel. Delphi ist mit neuen Technologien immer viel zu langsam. Ein anderes Beispiel war der 64 Bit Compiler. Da hat uns Mathias 2011 als "Vorreiter/Early Adopters/Technik-Freaks" bezeichnet, weil wir für 64 Bit entwickeln wollten. Solange Emba an solch antiquirten Mustern festhält und sich da auch nicht reinreden lässt, wird Delphi es weiterhin schwer haben. Ich denke Metro Support sehen wir frühestens in XE5 oder 6. Wahrscheinlich genau dann wenn man mit Windows Apps keinen Cent mehr verdienen kann.

Zitat von Bernhard Geyer:

Für >90% der Anwendungsfälle tut es auch eine 32-Bit App im 64-Bit Umfeld.

Auch wenn das so ist, sehen das viele Kunden leider anders. Wenn der Kunde 64 Bit will, dann sollte man das auch liefern können.

[mkinzler]

Zitat:

Metro ist wohl das beste Beispiel.

Echte Metro Apps (Windows Store) kann man sowieso nur mit VS erzeugen. Zudem will ja MS laut Gerüchten die Win8-API in Blue durch eine neuere ersetzen.

Der 64Bit Support dauerte viel zu lange. Aber man kann ja in der vorhandenen 32Bit IDE 64 Bit Anwendungen erzeugen.

[Insider2004]

Metro ist der neue lahme Gaul nach .Net von Microsoft. Das Ding wird nie fliegen, weil der MS-Marktanteil im Mobilebereich nahezu gegen Null tendiert. Was soll da EMBA noch abgreifen? Nichts! Die sollen lieber mal ihre VCL renovieren (Region support, etc..) und ihre Bugs beseitigen. Sonst verlieren sie die Win32/64-Kunden auch noch. Und die bringen die Hauptkohlen. Wenn das erledigt ist, kann man Android und Linux anfassen.

[Codehunter]

Vielleicht sollte man "Delphi" nicht immer synonym für IDE und Programmiersprache verwenden. Ich bin mit Object Pascal wie es in XE2 vorhanden ist, eigentlich ganz zufrieden. Pascal hat für mich schon immer eine gewisse Eleganz im Vergleich zu z.B. C++ oder C# gehabt. Wobei C# schon viel "schöner" wirkt. Darum konnte ich mit der Diskussion um anonyme Funktionen und Traits gar nichts anfangen.

Ich mag die Sprache Object Pascal, die aktuelle IDE dagegen mag ich nicht. Die wirkt für mich wie Stückwerk, wie eine Ansammlung lose zusammengewürfelter Einzelteile. Der 64-Bit-Compiler, FMX, das Hilfesystem... Alles macht einen "angeflanschten" Eindruck, nicht als würde es dazu gehören.