@Hans Peter
@Phoenix
@Threaderöffner
Moin,
ich glaube das das Hauptproblem bei Delphi (bzw. früher Borland / jetzt CodeGear) einfach ist, dass mit der NET-Entwicklung von Microsoft enfach nicht Schritt gehalten werden kann.
Wenn ich mir nebenbei den Aktienmarkt Chart von Borland anschaue, stelle ich fest, dass die 4 jährige Aktienmarkthausse an Borland relativ spurlos vorbeigegangen ist, was evtl. als Indiz für die, in meinen Augen, gescheiterte Produkt- und Firmenpolitik gewertet werden kann.
Borland hat im ende Sept. 2002 bei ca. 7,80 USD notiert am 06.03.2007 bei 4,89 US (Wertverlust der Aktie bei ca. über 37 % !?)
Der Nasdaq Composite Index dagegen konnte in diesem Zeitraum seinenen Wert nahe zuverdoppeln (ATL in 2002 bei ca. 1100 P. heute steht der deutlich über 2300 P. (Borland ist im Nasdaq gelistet).
Aber zurück zum eigentlichen Thema.
Das
BDS 2006 setzt auf Net 1.1 auf und MS ist schon bei Net 2.0 (3.0 dürfte evtl. bald vor der Tür stehen).
Da MS das Tempo bei NET wesentlich bestimmt, da es dieses erschaffen hat und stets weiterentwickelt, wird man wohl nicht daran vorbei kommen, bei den Entwicklungswerkzeugen auch ins MS-Regal zu greifen, wenn man mit der NET-Entwicklung Schritt halten will (=> entscheidend ist natürlich dabei, dass man als Entwickler (ob Hobby oder Prof.) dem NET-Prinzip Zukunfsfähigkeit auf längere Sicht zutraut (5 - 10 J. im Minimum) was noch fraglich ist.
Ich setze z. Z. noch die Delphi7 Prof. ein, davor habe ich mit Turbo Pascal 7.00 gearbeitet.
Aber so wie ich die Tendenz sehe werde ich die Entwicklerprodukte von Borland bzw. dessen Nachfolger (CodeGear) nicht mehr in die engere Auswahl einbeziehen.
Schmerzlich ist das Borland sich in der Tat (wie schon von einigen Vorrednern beschrieben) verzettelt hat und (der Nachfolger) in meinen Augen kein klares schlüssiges und zeitgemässes Konzept mehr hat, auf dem Markt der Entwicklerprodukte zu bestehen zumind. für den Teil der mich zukünftig interessieren würde.
Schade ist, dass Borland Kylix nicht wesentlich weiter entwickelt hat bzw. das Codegear für Linux keine passenden Entwicklungswerkzeuge bietet, dann hätte man als Entwickler und Anwender auch reelle Chancen gehabt sich früher oder später von den Fesseln der MS-Dominanz in div. Teilbereichen ein wenig zu lösen.
Ich glaube, das CodeGear zukünftig nicht in der Lage sein wird, bei NET im MS-Tempo Schritt zu halten. MS ist mit .NET eigentlich ein genialer Schachzug gelungen. Kein Fremdanbieter von Entwicklungswerkeugen aber auch von Anwendungssoftware wird in der Lage sein, den Zeitvorteil von MS auf ein erträgliches Mass in der eigenen Programmentwicklung zu reduzieren.
MS hat als Eigenentwickler vom .NET autom. einen enormen Wettbewerbs(zeit)vorteil für die Plazierung von anderen Produkten die für die Entwicklung von Entrwicklungsprodukten oder von Endprodukten relevant sind.
Ich glaube wer heute vor der Entscheidung steht, welches Entwicklungssystem auf mittelfristige Sicht in die engere Auswahl zu ziehen ist, der wird .NET und damit wahrscheinlich eines der MS-Werkzeuge in die engere Wahl einbeziehen müssen. Java könnte evtl. wg. der plattformunbahängigkeit noch eine ernste Alternative bzw. Konkurrenz zu .NET bleiben.
Wobei ich, wenn ich mir so eingie JAVA-Anwendungen so anschau, das kalte Grausen bekomme. JAVA Anwendungen bringen bei mir das AOL häufig zum Absturz.
Wahrscheinlich werde auch ich schweren Herzens
bei der nächsten Entwicklungsumgebung ins MS-Regal greifen (wahrscheinlich Visual C# für NET). Als Hobbyentwickler werde ich die Entscheidung aber aller Voraussicht nach noch ca. 6 - 12 Mon. auf die lange Bank schieben.
Ich hoffe nur, dass wenn Delphi mal sterben sollte (was den Anwendern und auch Borland bzw. CodeGewar nicht zu wünschen ist) , dass dieses Forum uns trotzdem lange (aktiv) erhalten bleibt.
Habe mich hier eigentlich ganz wohl gefühlt, auch wenn ich schon länger nix mehr geschrieben habe.
Gruss, der Skatspieler
P.S: Was ich noch vergessen habe: Für C# (Visual C#) dürfte auch noch eine relativ reichhaltige und fundierte Dokumentaton bzw. Verfügbarkeit von Medieninhalten (Bücher, Skripte usw) sprechen (=> was diesbezüglich früher in der Vergangenheit für C und C++ galt dürfte gegenwärtig und zukünftig für C# gelten).