Was geht ab bei Embarcadero?

[fatalerror]

So langsam habe ich Zweifel an einer Zukunft von Delphi. Als Anwender seit Version 1.0 von Delphi machen mich verschiedene Punkte nachdenklich:

• Nick Hodges gefeuert
• Kritische Einträge im Usenet (Newsgroups) werden von Embarcadero gelöscht
• Programmfehler (und davon gibts hunderte) werden, wenn überhaupt, erst mit kostenpflichtigen Updates behoben
• Einträge in der QC werden als behoben gekennzeichnet, obwohl sie bei mir immer noch auftreten, bzw ohne dass Updates ausgegeben werden
• Nicht ausgegorene Features (Generics, Ribbon Controls) werden im Betastadium mit teuer bezahlten Updates an den Anwender ausgeliefert
• Mitgelieferte Controls aus dem letzten Jahrtausend, sind noch heute nicht themesfähig
• Ein mindestens in Ansätzen brauchbarer gratis mitgelieferter Reportgenerator ist nicht in Sicht

Das mag ja alles i.0 sein für ein Tool das wie zu Zeiten von Delphi 1 unter 100 CHF bzw bei ca 50 € gekostet hat und für Hobbyzwecke verwendet wird. Als professioneller Softwareentwickler, werde ich mich wohl oder übel mit viel Wehmut nach neuen Werkzeugen umsehen müssen, oder was meint ihr?

Ist es langsam an der Zeit sich nach einer Alternative umzusehen?

[jbg]

Zitat:

Zitat von fatalerror (Beitrag 1037402)

Nick Hodges gefeuert

Es ist nicht bekannt, warum er gefeuert wurde.

Zitat:

Kritische Einträge im Usenet (Newsgroups) werden von Embarcadero gelöscht

Meiner Meinung nach wollten Sie damit wohl eine Eskalation verhindern, haben sie aber dadurch erst ausgelöst. Denn die Postings von Simon Kissel (wird das hier jetzt gelöscht :roll: ) enthielten nichts, was in meinen Augen ein Löschen rechtfertigen würde. Aber da er lebenslänglich gebannt ist, hat man seine Postings gelöscht, was dann zur Eskalation führte.

Zitat:

Programmfehler (und davon gibts hunderte) werden, wenn überhaupt, erst mit kostenpflichtigen Updates behoben

Das finde ich auch ein Armutszeugnis. Klar, sie sind nicht Microsoft und haben Geld ohne Ende, aber seit Delphi 8 haben sie mit der IDE zu kämpfen und haben sich mehrmals in der Richtung geirrt (Kylix, C++BuilderX, Delphi.NET).

Zitat:

Einträge in der QC werden als behoben gekennzeichnet, obwohl sie bei mir immer noch auftreten, bzw ohne dass Updates ausgegeben werden

Da hat Embt ein technisches Problem. Die Kunden nutzen Quality Central wohingegen die Entwickler das hausinterne RAID nutzen. Und ich habe auch schon gesehen, dass JIRA Einträge "behoben" wurde. Die haben also 3 unterschiedliche Bugtracking Systeme. Und dass die nicht ordentlich synchronisiert werden können ist verständlich. Unverständlich ist jedoch, warum sie drei brauchen und nicht eines ausreicht.

Zitat:

Nicht ausgegorene Features (Generics, Ribbon Controls) werden im Betastadium mit teuer bezahlten Updates an den Anwender ausgeliefert

Bei den Features stellte sich wohl die Frage, nehmen wir das noch in das Produkt auf obwohl es nicht fertig gestestet ist, damit die neue Version überhaupt einen Mehrwert zur Vorgängerversion hat.

Zitat:

Mitgelieferte Controls aus dem letzten Jahrtausend, sind noch heute nicht themesfähig

Mit Delphi 2010 ist nun endlich das TDBGrid "gethemed".

Zitat:

Ein mindestens in Ansätzen brauchbarer gratis mitgelieferter Reportgenerator ist nicht in Sicht

Mit den mitgelieferten 3rdParty Komponenten hatte die noch nie Glück. Ich sag nur Indy, Rave und all die vergangenen Komponenten.

[mkinzler]

Zitat:

Zitat von fatalerror:
Nick Hodges gefeuert
Es ist nicht bekannt, warum er gefeuert wurde.

Und das wird wohl auch so bleiben.

Zitat:

Programmfehler (und davon gibts hunderte) werden, wenn überhaupt, erst mit kostenpflichtigen Updates behoben

Das ist leider schon länger so.
Btw. gibt es aber kein fehlerfreies Produkt.

[cookie22]

das ist doch die gleiche diskussion, die es schon seit ewigkeiten gibt. delphi liegt im sterben, delphi benutzt eh keiner mehr, u.s.w..

für mich persönlich gibt es immer noch keine alternative zu delphi, mit delphi bin ich schneller als mit jeder anderen lösung.

ausserdem sieht es mit alternativen ja auch mehr als dünn aus, mehr als vs ist da auch nicht.

Zitat:

...Mitgelieferte Controls aus dem letzten Jahrtausend, sind noch heute nicht themesfähig...

dafür gibt es wohl für keine andere sprache soviele 3rd party komponenten, die grösstenteils auch noch frei sind.

Zitat:

Nicht ausgegorene Features (Generics, Ribbon Controls) werden im Betastadium mit teuer bezahlten Updates an den Anwender ausgeliefert

die komponenten, die mit delphi selbst kommen, waren noch nie das gelbe vom ei. das ist seit version 1 so. wie gesagt es gibt soviele gute alternativen.

ich kann nur sagen mit delphi 2010 bin ich wirklich zufrieden, es ist mit abstand die beste delphi version die es gibt.

[fatalerror]

Zitat:

Zitat von cookie22 (Beitrag 1037427)

das ist doch die gleiche diskussion, die es schon seit ewigkeiten gibt. delphi liegt im sterben, delphi benutzt eh keiner mehr, u.s.w..

Nein, ich behaupte nicht, dass Delphi stirbt, bedenklich finde ich nur die Richtung in welche der Weg von Embarcadero geht

Zitat:

Zitat von cookie22 (Beitrag 1037427)

für mich persönlich gibt es immer noch keine alternative zu delphi, mit delphi bin ich schneller als mit jeder anderen lösung.

Nach über 30 Jahren Programmieren mit Pascal, geht es mir genau gleich. Was aber nicht heissen soll, dass nach einer Einarbeit in eine andere Sprache, der Lösungsweg nicht schneller, eleganter und effizienter sein kann

Zitat:

Zitat von cookie22 (Beitrag 1037427)

ausserdem sieht es mit alternativen ja auch mehr als dünn aus, mehr als vs ist da auch nicht.

Doch, Alternativen sind genügend da, neue und interessante Sprachen sind ebenfalls auf dem Markt.

Zitat:

Zitat von cookie22 (Beitrag 1037427)

dafür gibt es wohl für keine andere sprache soviele 3rd party komponenten, die grösstenteils auch noch frei sind.

Das mag ja für Hobbyprogrammierer auch zutreffen, als professioneller Entwickler stösst man da aber sehr rasch auf Probleme. Programme müssen über Jahre gewartet werden und man gerät in eine Abhängigkeit von mehreren Zuliefern. Nicht alle Firmen sind so kulant wie Turbopower und stellen ihre Produkte als Open Source zur Verfügung, wenn sie untergehen.

[cookie22]

Zitat:

Doch, Alternativen sind genügend da, neue und interessante Sprachen sind ebenfalls auf dem Markt.

welche davon sind denn nur ansatzweise mit delphi vergleichbar?

Zitat:

Das mag ja für Hobbyprogrammierer auch zutreffen, als professioneller Entwickler stösst man da aber sehr rasch auf Probleme. Programme müssen über Jahre gewartet werden und man gerät in eine Abhängigkeit von mehreren Zuliefern. Nicht alle Firmen sind so kulant wie Turbopower und stellen ihre Produkte als Open Source zur Verfügung, wenn sie untergehen.

freie komponenten liegen im allgemeinen im source vor, das sollte also kein problem sein. das hat nichts mit hobbyprogrammierer oder nicht zu tun.

[himitsu]

Zitat:

Zitat von cookie22 (Beitrag 1037431)

welche davon sind denn nur ansatzweise mit delphi vergleichbar?

jetzt kommt bestimmt gleich Einer mit C# (wobei ein Großteil davon naturgemäß von Delphi stammt ... und heutzutage hat doch eh jeder mindestens die nötigen .net-Frameworks 1.0, 2.0 und 3.5 installiert :stupid: )

[fatalerror]

Zitat:

Zitat von cookie22 (Beitrag 1037431)

freie komponenten liegen im allgemeinen im source vor, das sollte also kein problem sein. das hat nichts mit hobbyprogrammierer oder nicht zu tun.

Hier gilt klar zu trennen. Sogenannt freier Code ist meist nicht frei! In der Regel liegen freie Komponenten nicht als Freeware vor sondern unterliegen einer Lizenz, die es professionellen Entwicklern nicht erlauben diese Komponenten zu verwenden, ohne den eigenen Sourcecode zur Verfügung zu stellen.

Sollten ausnahmsweise die Lizenzbedingungen eine Codeänderung noch erlauben, so ist die Einarbeitungszeit in den fremden Code in der Regel zu aufwändig um die Komponente selbst abzuändern. oder hättest Du Lust und Zeit alle Fehler im Reportgenerator zu beheben, ohne deinem Kunden den Aufwand dazu verrechnen zu können?

[fatalerror]

Zitat:

Zitat von cookie22 (Beitrag 1037431)

welche davon sind denn nur ansatzweise mit delphi vergleichbar?

Warum muss eine Alternative mit Delphi vergleichbar sein? Als ich mit Delphi startete gabs nichts vergleichbares, und es war ein Abenteuer mit dieser Entwicklungsumgebung zu beginnen.

Weshalb sollte _ich_ nicht im reiferen Programmiererleben nochmals mit einer neuen Entwicklungsumgebung einen neuen Schritt wagen und zb mal go verwenden?

[mkinzler]

Diese Diskussion hatten wir hier schon öfters. Und auf ein Ergebnis sind wir nie gekommen und werden wir auch diesmal nicht.
Der einzige Nebeneffekt war oft, dass man sich in die Haare gekommen ist und es in Folge zu Austritten kam.

[Hansa]

Da sage ich nur : Totgesagte leben länger. Siehe Delphi. :mrgreen: Es hängt alles davon ab, wie lukrativ ein Produkt ist. Immer wieder "wo ist eine kostenlose Delphi-Version ?". Das ist Totengräberei an Delphi.

So, jetzt Nähkästchen : Warum gibts denn kein Turbo-Delphi Explorer mehr ? Weil das zu viel konnte und das "richtige" Delphi im Verkauf behindert hat. Wurde jedenfalls offiziell so gesagt (Mike Swindell oder wie der heisst). Desweiteren wurde die Version (auch hier) ausgetrickst. 8-) Wen wunderts denn da, dass das vom Markt genommen wurde ?

Apropos Turbopower : dürfte weithin unbekannt sein, aber da war folgendes : lukrativ war das wohl schon, aber eine Spiele-Fa. brauchte aus dem Komplettpaket was die hatten, eine spezielle Komponente und die haben dann kurzerhand den ganzen Laden aufgekauft. Krass. :shock:

Man braucht nicht mal nach Amerika zu gehen. Was ist mit Enz geschehen ? Alte Hasen dürften den noch kennen. Stichwort : BTree-Isam/Filer. Denen brach der Umsatz weg. Warum ? Wegen Delphi 1. :P Dadurch war Finito. Zumindest der Hauptentwickler ist bei KHK gelandet. Und wo sind die ? Weg. Jetzt Sage-KHK. Aufgekauft.

Also, lange Rede kurzer Sinn : statt Hektik zu verbreiten, besser abwarten und Tee trinken. Meistens kommt es anders und manchmal als man denkt. Die Diskussion ist sowieso eigentlich überflüssig. Das soll jetzt alles nicht heissen, dass die alles richtig machen ! Aber hier ändert sowieso wohl keiner was. C'est la vie.

P.S.: War klar : roter Kasten läuft fast über. Wahrscheinlich krieg ich jetzt Haue. :mrgreen:

[cookie22]

Zitat:

Zitat von fatalerror (Beitrag 1037433)

Zitat:

Zitat von cookie22 (Beitrag 1037431)

freie komponenten liegen im allgemeinen im source vor, das sollte also kein problem sein. das hat nichts mit hobbyprogrammierer oder nicht zu tun.

Hier gilt klar zu trennen. Sogenannt freier Code ist meist nicht frei! In der Regel liegen freie Komponenten nicht als Freeware vor sondern unterliegen einer Lizenz, die es professionellen Entwicklern nicht erlauben diese Komponenten zu verwenden, ohne den eigenen Sourcecode zur Verfügung zu stellen.

Sollten ausnahmsweise die Lizenzbedingungen eine Codeänderung noch erlauben, so ist die Einarbeitungszeit in den fremden Code in der Regel zu aufwändig um die Komponente selbst abzuändern. oder hättest Du Lust und Zeit alle Fehler im Reportgenerator zu beheben, ohne deinem Kunden den Aufwand dazu verrechnen zu können?

doch gerade bei delphi komponenten sind die lizenzen doch meistens mehr als gut integrierbar. es gibt kaum kompos die unter gpl laufen. das meiste geht als public domain, mpl ode lgpl und ist damit für den professionellen einsatz gut zu gebrauchen.

Zitat:

Warum muss eine Alternative mit Delphi vergleichbar sein? Als ich mit Delphi startete gabs nichts vergleichbares, und es war ein Abenteuer mit dieser Entwicklungsumgebung zu beginnen.

Weshalb sollte _ich_ nicht im reiferen Programmiererleben nochmals mit einer neuen Entwicklungsumgebung einen neuen Schritt wagen und zb mal go verwenden?

womit ausser c# kann man denn ähnlich produktiv arbeiten?

[fatalerror]

Zitat:

Zitat von mkinzler (Beitrag 1037438)

Diese Diskussion hatten wir hier schon öfters. Und auf ein Ergebnis sind wir nie gekommen und werden wir auch diesmal nicht.
Der einzige Nebeneffekt war oft, dass man sich in die Haare gekommen ist und es in Folge zu Austritten kam.

Sorry, der Weg, den die Diskussion nimmt gefällt mir auch nicht mehr. Ich wollte eigentlich hier nicht eine Diskussion über Fehler von Delphi starten. _ich_ persönlich habe in letzter Zeit einfach Mühe den Weg von Embarcadero zu verstehen bzw zu akzeptieren.

Ich suche für _mich_ Alternativen zu Delphi und sage nicht, Delphi sei schlecht oder Delphi wird sterben oder möchte Embarcadero sagen was sie zu tun haben.

Also meine Usrsprungsfrage im ersten Posting war doch die Frage nach Alternativen zu Delphi, oder irre ich mich da?

Was ich mal angeschaut habe ist go, scheint mir ein interessantes Projekt zu sein

[mkinzler]

Wobei nicht nur die Sparche, sondern auch das "Darum" betrachtet werden muss. D ist als Sprache recht fortschrittlich. Der Rest fehlt halt fast komplett.

[Meflin]

Zitat:

Zitat von cookie22 (Beitrag 1037444)

womit ausser c# kann man denn ähnlich produktiv arbeiten?

Ach, nimm dir IRGENDWAS was nen Garbage Collector hat und schon ist das Leben schöner :tongue:

Ich persönlich bin bei D2007 stehen geblieben. Und damit seit Win7... von Delphi abgekommen. Was Emba betrifft, hatte ich von Anfang an so meine Zweifel. Ich warte eigentlich darauf, dass Delphi zu einer DBMS-Umgebung mit integrierter Scriptingsprache degeneriert ^^

[WInfo]

Zitat:

Zitat von cookie22 (Beitrag 1037427)

das ist doch die gleiche diskussion, die es schon seit ewigkeiten gibt. delphi liegt im sterben, delphi benutzt eh keiner mehr, u.s.w..

Jetzt warten wir mal ab, was D2011 bringt, wenn da nicht etwas vernünftiges dabei rumkommt, werd ich wohl auch anfangen den Markt neu zu sondieren.

Aber das Ökosystem muss auch passen und nicht Native ist keine Alternative. Aber darum kann ich mir im Herbst gedanken machen. Jetzt ist noch Zeit zum Teetrinken.

[fkerber]

Hi,

Zitat:

Zitat von Meflin (Beitrag 1037459)

Ach, nimm dir IRGENDWAS was nen Garbage Collector hat und schon ist das Leben schöner :tongue:

aus aktueller Erfahrung kann ich das so nicht stehen lassen. ;)
Mach mal ne ordentliche GUI mit Java - da hilft kein GC der Welt.


Grüße, Frederic

[himitsu]

Zitat:

Zitat von Meflin (Beitrag 1037459)

und schon ist das Leben schöner :tongue:

immer diese faulen Programmierer :tongue:

Aber mal im Ernst, diese "Schrottteile" können auch nerven, vorallem wenn nicht deaktivierbar.

[Mschmidt]

Also ich bin zufrieden.
Ich habe D2009, sämtliche DevExpress Lizenzen (mit Source), TurboPower (da benutz ich nur die Verschlüsselungen),
die DevArt DB Componenten (Unidac, OracleDac) und Fast-Report in der Rundumsorglosversion. Zugegeben, alles zusammen nicht ganz billig.
Mehr braucht ein Entwickler doch nicht. Ich verwende weder die mitgelieferten Datenbank-Teile noch die Standard-Controls. :-)
Da mein beruflicher Focus auf Richclient im C/S Umfeld liegt bin ich also "rundum versorgt". Auf 64 Bit kann ich verzichten
und Treiber baue ich nicht. Was will ich mehr:?:

:Mschmidt

[himitsu]

Zitat:

Zitat von Mschmidt (Beitrag 1037477)

Ich verwende weder die mitgelieferten ... Standard-Controls. :-)

Keine Buttons, Edits, Labels, Panels, TOpenDialogs, TForms, Frames oder so? :shock:

[Mschmidt]

bis auf Forms/Frames nein. Schau dir mal die DevExpress (http://www.devexpress.com/Products/VCL/) VCL Bibliothek an.
Ich verwende überhaupt keine Panels und Labels - da DevExpress einen Layoutmanager liefert, der das automatisch mit eigenen macht.

Die OpenDialog/Savedialog/MessageDlg Componenten von D haben den Nachteil, dass sie nicht unterscheiden, auf welchen BS sie laufen.
Sprich, sie sehen unter Vista/w7 genauso aus wie unter XP. Auch hier verwende ich eigene bzw. die von TMS. :-)
:-mschmidt

[mirage228]

Zitat:

Zitat von Mschmidt (Beitrag 1037549)

Die OpenDialog/Savedialog/MessageDlg Componenten von D haben den Nachteil, dass sie nicht unterscheiden, auf welchen BS sie laufen.
Sprich, sie sehen unter Vista/w7 genauso aus wie unter XP. Auch hier verwende ich eigene bzw. die von TMS. :-)
:-mschmidt

Da würde ich zumindest bei D2010 widersprechen. Bei D2010 gibt es einen per Default aktivierten Schalter (UseLatestCommonControls oder so), mit dem die jeweils neuesten Dialoge (TaskDialog in MessageBoxen z.B.) oder die neue Öffnen und Speicher-Dialoge verwendet werden. MessageDlg(!) allerdings müsste tatsächlich von der VCL über eine eigene Form zusammengebaut sein oder überall gleich aussehen - aber der Rest ist da schon adaptiv.

Viele Grüße

[HeZa]

[QUOTE=fatalerror;1037446]

Zitat:

Zitat von mkinzler (Beitrag 1037438)

Was ich mal angeschaut habe ist go, scheint mir ein interessantes Projekt zu sein

Wie baut man denn mit GO eine RichClient-Anwendung? Ich habe da nur kurz auf die Seite geschaut und dazu nichts gefunden. Hast du dazu vielleicht einen Link für mich?

Delphis Stärken sind die einfache Erstellung von komplexen Benutzeroberflächen (für Windows) und die Datenbank Anbindungen.

Wenn man keine komplexen Benutzeroberflächen (komfortable Grids, Drag/Drop, Docking, TreeView etc.) braucht, ist man mit fast jeder anderen Hype-Sprache besser bedient (und vor allen Dingen günstiger).

Ein Einschränkung muss ich allerdings doch noch machen. Die Syntax. Ich bin ein Fan von BEGIN /END. Ich mag nicht diese C-Varianten der For-Schleife und einiges andere auch nicht (schrecke aber auch nicht davor zurück diese zu benutzen :) ).

Ich habe mich zuletzt in Scala eingelesen und bin von dessen Features sehr angetan. Noch mehr begeistert hat mich allerdings Delphi Prism 2011. Enthält viele der Features von Scala (und einige mehr) in einer Syntax die jeder sofort verstehen kann (meine Behauptung :-D ).

Ich benutze Prism nicht, weil man bei uns gerne bei alt bewährtem Bleibt (und auch das hat seine Berechtigung), aber das wäre mein erster Kandidat wenn ich nach einer alternative zu Delphi Win32 suchen würde.

[HeikoAdams]

Ich denke, das Hauptproblem von Delphi/Emb ist, das ihre Kommunikation mit den (potentiellen) Kunden nicht passt und sie bestehenden Kunden nicht so Recht das Gefühl geben, das man sich um bestehenden Probleme kümmert. Man muss doch nur mal schauen, wie viele Einträge es in der QC gibt, die seit Jahren offen sind und zu denen es null Feedback vom Emb gibt.
Der Kunde muss so im Prinzip bei jedem neuen Release entweder hoffen, das "seine" Fehler behoben sind oder versuchen, über die QC eine Antwort auf diese Frage zu bekommen.

BTW: "Alle bekannten Fehler behoben" wäre doch ein hübsches Verkaufsargument für ein neues Delphi Release ;)

[mkinzler]

Damit würde man aber offiziell zugeben müssen, das es Fehler gibt.

[hanspeter]

[QUOTE=HeZa;1037568]

Zitat:

Zitat von fatalerror (Beitrag 1037446)

Delphis Stärken sind die einfache Erstellung von komplexen Benutzeroberflächen (für Windows) und die Datenbank Anbindungen.

Wenn man keine komplexen Benutzeroberflächen (komfortable Grids, Drag/Drop, Docking, TreeView etc.) braucht, ist man mit fast jeder anderen Hype-Sprache besser bedient (und vor allen Dingen günstiger).

Naja, im komerziellen Bereich bei C/S Systemen sind die Datenanbindungen nicht mehr das gelbe vom Ei.
Mit den Standardcomponenten ist kein oder nur ein eingeschränkter verbindungsfreier Betrieb möglich.
Hier ist Bastelei notwendig. Zumindest in Net ist das Databinding besser gelöst.
Und was komplexe Oberflächen angeht WPF? Wincontrols unterscheiden sich nur wenig von Delphi Oberflächen.
Das nur am Rande.

Gruß

[HeikoAdams]

Zitat:

Zitat von mkinzler (Beitrag 1037579)

Damit würde man aber offiziell zugeben müssen, das es Fehler gibt.

Tschuldigung, aber wer glaubt, das so komplexe Systeme wie Delphi absolut fehlerfrei sind, dem ist eh nicht mehr zu helfen 8-)

[mkinzler]

Es gibt keine wirklich fehlerfreien Programme (abgesehen von "Hallo Welt!" und Co.)
Aber kein Unternehmen ( und EM schon 2 Mal nicht) würde eine neues Produkt so bewerben (Ausnahme: Waschmittel). Denn dann könnte man darin Mängel der Vorgänger sehen, welche man dann für diese beheben müsste ( was BOR/CG/EM ja aus Tradition nicht macht)

[HeikoAdams]

Zitat:

Zitat von mkinzler (Beitrag 1037586)

Es gibt keine wirklich fehlerfreien Programme (abgesehen von "Hallo Welt!" und Co.)
Aber kein Unternehmen ( und EM schon 2 Mal nicht) würde eine neues Produkt so bewerben (Ausnahme: Waschmittel). Denn dann könnte man darin Mängel der Vorgänger sehen, welche man dann für diese beheben müsste ( was BOR/CG/EM ja aus Tradition nicht macht)

Ich hatte eigentlich gedacht, das die Ironie in dem Satz mit dem Verkaufsargument erkennbar wäre :-D

[HeZa]

[QUOTE=hanspeter;1037580]

Zitat:

Zitat von HeZa (Beitrag 1037568)

Zitat:

Zitat von fatalerror (Beitrag 1037446)

Delphis Stärken sind die einfache Erstellung von komplexen Benutzeroberflächen (für Windows) und die Datenbank Anbindungen.

Wenn man keine komplexen Benutzeroberflächen (komfortable Grids, Drag/Drop, Docking, TreeView etc.) braucht, ist man mit fast jeder anderen Hype-Sprache besser bedient (und vor allen Dingen günstiger).

Naja, im komerziellen Bereich bei C/S Systemen sind die Datenanbindungen nicht mehr das gelbe vom Ei. Mit den Standardcomponenten ist kein oder nur ein eingeschränkter verbindungsfreier Betrieb möglich. Hier ist Bastelei notwendig. Zumindest in Net ist das Databinding besser gelöst. Und was komplexe Oberflächen angeht WPF? Wincontrols unterscheiden sich nur wenig von Delphi Oberflächen.

Ich gebe dir vollkommen Recht. Trotzdem sind die Erstellung von komplexen Benutzeroberflächen (für Windows) und die Datenbank Anbindungen die Stärken von Delphi. Brauche ich also eine Alternative, muss diese für die Erstellung von komplexen Benutzeroberflächen (in kurzer Zeit) geeignet sein und die einfache Anbindung von Datenbanken unterstützen. Von daher wäre dann auch Delphi Prism als dotNet-Sprache die erste Alternative die ich testen würde.

[sh17]

Also wir haben vor kurzem den Schritt von Delphi 6 mit TntControls nach Delphi 2010 gewagt. Und ich muss sagen, ich bereue es nicht. Die Umstellung ging relativ flott, nachdem wir den ganzen TNT-Kram rausgeschmissen haben. Nun ist noch Feinarbeit dran. Die IDE ist zu Delphi 6 natürlich komplett anders und vieles ist neu. Aber sie ist genaus so stabil. Von daher, kann nur besser werden.

[IBExpert]

Zitat:

Zitat von hanspeter (Beitrag 1037580)

Hier ist Bastelei notwendig. Zumindest in Net ist das Databinding besser gelöst.

naja, Databinding Verfahren welcher Art auch immer sind auch nicht immer das gelbe vom Ei, ich kenn da diverse Kundenprojekte aus der Praxis, bei denen man sich darauf verlassen hat, das die Zugriffsschicht das schon gut und performant macht, ob das nun in .NET auf Basis Linq ist oder diverse Java App Server sind, oder auch Delphi Midas. Was der eine als Vorteil sieht, nämlich kein SQL schreiben zu müssen, resultiert aber meist darin, das am Ende trotzdem SQL an den Server geschickt wird. Es gab mal vor Jahren eine Anfrage hier in der DP, wo als Resultat ein SQL mit verschachtelten In Operator mit ca 2000 Werten erzeugt wurde.

Wenn deine Middleware nun Daten von 1000 Records braucht und diese wie leider sehr oft auf 1000 unterschiedliche SQLs verteilt, dann brauchst du dir über Performance keine Gedanken machen. Damit hast du als Programmierer oder auch Softwareentwickler das Leben zwar eine gewisse Zeit einfacher, wenn dann aber Datenmengen größer werden und die Anzahl Benutzer größer wird, dann stehst du in einer Sackgasse.

Nur weil MS da diverse speicherbasierende Optimierungen in den SQL Server gepackt hat ist das auch mit vergleichbar großen Datenmenge mit Linq zum Beispiel benutzbar, aber es gibt diverse Projekte, da fallen die Microsoft Produkte durch deren Lizenzkosten schon mal weg (das betrifft selten kleine Firmen, meist sind das auch Enterprise Unternehmen).
Wir haben gerade so einen Fall, bei dem ein Zeitarbeitsunternehmen für 4000 User die Arbeitszeitmeldungen via Weboberfläche in das Zielsystem Navision zurückschreiben muss. Laut Microsoft heißt das relativ einfach, das man 4000 named Client Lizenzen braucht, kann man sich ja vorstellen was das kostet. Nun gut, ist mit Firebird, Apache, PHP und IBExpert realisiert, läuft ohne Lizenzkosten und eine Job in Navision holt sich die Daten von Firebird. Spart eine Unmenge an Geld und ist extrem flexibel. Aber das gehört eigentlich gar nicht zum Thema....

Ich kenne diverse Kunden, die Midas verfluchen, aber durch jahrelange Programmierung doch sehr damit verheiratet sind. Wenn ich bei denen im Monitoring auf dem FB Server nachschau, was die Applikationen für SQLs ablaufen lassen, dann kann mir kaum jemand sagen, wo im Quellcode genau dieser Teil hinterlegt ist. So einfache Klassiker wie die Property Recordcount, die die Anzahl der Records ermittelt, in dem die einfach auf den Client heruntergeladen werden und dort gezählt werden, lass ich mal außen vor, das findet man schon leicht mal. Auch RequestLive Queries auf TDataset Basis machen nicht immer das was man so denkt, aber je nach Bibliothek kann man das recht gut eingreifen, z.B. IBDAC.

Wenn du aber wie ich für einen Kunden mit dem Magenta T vor der Haustür mal einen Kabel/Fasern Kopierprozess auf Basis eines Appservers optimieren sollst, bei dem Kabel mit Fasern von einem Standort zu einem anderen verschoben werden sollen (1 Kabel mit 72 Fasern, d.h. 73 Datensätze müssen angefasst werden), der Appserver auf dem Weg dahin aber ca 1500 Transaktionen mit weit über 100000 SQLs veranstaltet, und je nach Lust und Laune zwischen 30 und 50 Fasern verschiebt, aber leider nie 72, weil irgendeine der Transaktionen auf einen Deadlock lief, dann ist der Begriff optimieren da einfach fehl am Platze. Ich hatte als Lösung dafür gerne mal fdisk vorgeschlagen, Platte löschen und neu anfangen, geht aber auch nicht immer. Das ist ein krasses Beispiel, aber leider Realität. Und dummerweise glauben viele, das man dadurch das man die Abstraktionsschicht dazwischen packt, erhebliche Vorteile hat. Kurzfristig mag das sein, aber ganz oft geht das tierisch in die Hose, wenn es denn nachher ans Eingemachte geht und man mit diversen Gigabyte an Daten zu tun hat.

Die Nutzung der Standardkomponenten in Delphi sollte man auch da lassen wo die sind, ohne eigene Architektur muss man halt Kompromisse eingehen, aber die sind aus meiner Sicht für 90% der Delphi Anwender ok und dir restlichen 10% benötigen da eh eigene Lösungsansätze. Der Umstieg auf eine andere Plattform (z.B. .NET mit Linq) ersetzt da aber nur den Teufel durch den Belzebub.

Schöne Grüße

Holger
www.ibexpert.com

[Phoenix]

Zitat:

Zitat von IBExpert (Beitrag 1037806)

Es gab mal vor Jahren eine Anfrage hier in der DP, wo als Resultat ein SQL mit verschachtelten In Operator mit ca 2000 Werten erzeugt wurde.

Auja. Das war ich ;-) Kann ich mich noch gut dran erinnern. Muss zwischen 2001 und 2004 gewesen sein.

Das dabei benutze Framework hatte einen OR-Mapper im Bauch, der in dieser Konstellation gewaltig auf die Nase gefallen ist. Lag aber auch zum Teil an falscher Benutzung des Tools.

[DeddyH]

Zitat:

Zitat von Phoenix (Beitrag 1037824)

Das dabei benutze Framework hatte einen OR-Mapper im Bauch, der in dieser Konstellation gewaltig auf die Nase gefallen ist.

[OT] *Hüstel* Kenne ich das Framework zufällig :mrgreen:? [/OT]

[Phoenix]

Jupp. ;-)

[mkinzler]

Es scheint mir, dass wir etwas vom Thema abgekommen sind :zwinker:

[Viktorii]

Auch auf die Gefahr hin wieder etwas offtopic zu werden:

Zitat:

Zitat von cookie22 (Beitrag 1037427)

ausserdem sieht es mit alternativen ja auch mehr als dünn aus, mehr als vs ist da auch nicht.

Wie sieht es denn da mit QT aus? Hab da selber nur wenig Erfahrung, wollte mich aber in naher Zukunft stark damit auseinandersetzen.
Zwar nicht als Alternative zu Delphi :angel: sondern als Alternative zu MFC unter WinCE :kotz:

C# werde ich mir diesbezüglich aber auch mal anschauen :)

[mleyen]

Zitat:

Zitat von Viktorii (Beitrag 1037842)

Wie sieht es denn da mit QT aus?

Gerüchte besagen, dass D2011´s UCL darauf basiert. :duck:

[mkinzler]

Zitat:

Zitat von mleyen (Beitrag 1037848)

Zitat:

Zitat von Viktorii (Beitrag 1037842)

Wie sieht es denn da mit QT aus?

Gerüchte besagen, dass D2011´s UCL darauf basiert. :duck:

Du UCL wird es frühestens mit D2011 geben

[Viktorii]

Ich meinte jetzt Qt unabhängig von Delphi...