Ist Delphi wirklich tot.

[Phoenix]

Zitat von Skatspieler:

Borland hat wohl mit der Auslagerung der Entwicklungsparte richtung Codegear betriebswirtschaftlich das einzig richtge getan.

Das sehen viele Borländer anders. Die IDE-Sparte war das, was Borland das Geld eingebracht hat, nicht die ALM-Sparte. Im Prinzip haben sie den einzig gewinnbringenden Bereich ausgegliedert.

Das MS die einzigen sind, die im Entwicklungsbereich mit .NET vorne dran sind ist aber auch falsch. RemObjects zeigt, dass man auch vorne (rein Technologisch gesehen) mitspielen kann. Ich hoffe inständig, dass sich CodeGear da ne Scheibe von abschneidet.

[hanspeter]

Das Problem von Delphi ist die VCL und die konzeptionelle Einbindung in das Entwicklungssystem.
Vor über 10 Jahren und für Win32, war die Entwicklung revolutionär.
Seit dem hat sich aber praktisch kaum etwas getan.
VCL schleppt immer noch Fehler vom ersten Tag an mit sich herum. (z.B. Referenzzählung bei Interfaces,Unicode, thread-Sicherheit)
Mit BPL einen Standard schaffen zu wollen, der zu nichts kompatibel ist, nicht einmal in aufeinanderfolgenden Versionen,
rächt sich jetzt.
Die Methodik zur Komponenteneinbindung im Entwicklungssystem ist überholt und von Version zu Version anfälliger geworden.
Ich muß ein paar Altprojekte pflegen, da ist es sinnvoll in einer virtuellen Maschine für jedes Projekt eine angepasste Delphi-Version bereitzuhalten.
Dabei rede ich noch nicht einmal davon, das sich die VCL von dem Ausflug nach CLX immer noch nicht erholt hat.
Der Compiler stagniert seit D7 in der Entwicklung, von marginalen Änderungen abgesehen.
Net ist aus den Erfahrungen der Delphi/VCL Entwicklung entstanden und ist einfach der modernere Ansatz.
Mit jeder Version nach Delphi 7 hat sich nun wiederholt, das die Erstauslieferung instabil und erst nach ein oder 2 Updates für kommerzielle Zwecke brauchbar wurde.
Selbst für ein non break Release wie D2007 kann es doch nicht sein, dass nach ein oder 2 Monaten über 300 Bugs gefixt werden müssen und das ist erst die Spitze vom Eisberg.
Wenn im BDS2007 dem Hörensagen ein neuer Compiler daherkommt, dann graust es mir schon davor aber das werde ich sicherlich nicht mehr mit machen.
Wo aber soll Delphi hingehen?
VCL.NET war ein Holzweg. Wer braucht ein Framwork als Wrapper für ein Framework ?
Wie es gehen könnte, hat Remobjects mit Chrome bereits vorgemacht. Codegear zeigt jetzt Aktionismus und bringt Delphi für alle
möglichen Sprachplattformen heraus, hoffentlich verzettelt man sich dadurch nicht.
Codegear kann bis heute noch keine tragfähigen strategischen Planungen bezüglich der Weiterentwicklung von Delphi und einer vernünftigen Einbindung des Net-Framworkes vorlegen.
Damit sind im Moment auch keine Planungen zur Weiterführung langfristig bestehender Projekte möglich.
Wenn die Win32 Plattform nicht eine Renesance erlebt, dann wird Delphi parallel zu dieser Plattform zurückgehen.
In meinem kommerziellen Umfeld plant praktisch jeder einen Wechsel des Entwicklungssystems, weg von Delphi in den nächsten ein
bis 2 Jahren.
Wenn es hier ein funktionierendes Konvertierungstool gäbe, das VCL in Net konvertiert, dann gänge diese Entwicklung
noch viel schneller.

Gruß
Peter

[Skatspieler]

Zitat von mkinzler:

Man könnte das auch als selbsterfüllende Prophezeihung sehen, da man erwartet, daß CodeGear verschwindet kann man das auch beschleunigen und deren Produkte wegen dieser Erwartungen meiden.
Aber CodeGaer sichert sich ja durch Einführung neuer Produkte für PHP und Ruby ja auch ab.

Codegear bleibt auch nix anderes übrig, als z. Z. die PHP und die Win32 Produktschiene schnellstmöglich zu füllen, da sie auf NET-Basis nix aktuelles brauchbares gebacken bekommen (wenn cih mich nicht täusche ist der zuletzt von Delphi unterstützte NET-Standard in der Version 1.1 oder ?). Das Zeitfenster für die 32 BIT Welt wird nicht mehr allzulange geöffnet bleiben. Mit der 64 BIT Welt dürfte eher das dunkle Zeitalter für Codegear beginnen.

Borland bzw. Inprise hat mit seiner Produktpolitk bereits für einige Enttäuschungen bei vielen Entwickern gesorgt (ich denke da z. B. an die Einstellung des Kylix Projekts unter Linux, fatal, dass man unter Linux keine Alternative anbietet und unter NET meilenweit hinter her hinkt, von den wirtschaftlichen Unwägbarkeiten mal abgesehen oder die Umfirmierungen von Borland zu Inporise und Inprise zu Borland ), daher bin ich, was die Produktpolitik bei Codegear angeht, sehr vorsichtig.

Bei Eintritt in die 64 BIT Welt (die Frage ist nur wann die 64 BIT endgültig salonfähig wird) werde ich mir sehr genau überlegen,
weche Programmierplattform wirklich Perspektive hat.

MS hat mit der Gewinnung (Abwerbung ?) des des ehem. Borland Mitarbeiters Heijlsberg, einen sehr guten Griff (und Schachzug) gemacht.
MS hat enorme finanzielle, personelle Ressourcen und die entsprechenden Schlüsseltechnologien in der Hand, da wird eine kleine Fa., wie Codegear, einfach nicht mehr mithalten können. Codegear ist einfach von der Entwicklersparte sehr abhängig und könnte damit u. U. nicht in der Lage sein, durch Produktdiversifikation eine nächste anstehende wirtschaftliche Schwächephase ausreichend zu kompensieren, falls es zu erheblichen Nachfrageschwankungen kommen sollte. Gerade wenn man nur wenige Produkte hat, muss man Nischen (das ist hier z. B. PHP) sehr gut besetzen können, was teilweise gelungen sein mag. Allerdings müssen die anderen Produkte, die in einem schwer umkämpften markt (wie Win32 es bereits ist und NET es werden wird, zeitnah und in guter Qualität für die entsprechende Plattform angeboten werden und da könnte es in Zukunft mächtig hapern.

Bei MS weiss man zumindest, dass Zukunftsfähigkeit bzw. Überlebensfähigkeit von Softwareprodukten auf Grund der vorstehend genannten Voraussetzungen gegeben ist. Dieser Punkt könnte bei Eintritt in die 64 BIT Welt sehr grosser Bedeutung beigemessen werden. Wenn MS die zukünftigen 64 BIT Betriebssysteme und die NET Technologie richtig strukturiert und miteinander sinnvoll verzahnt, werden die MS-Entwicklerwerkzeuge die erste Wahl für einen zukünftgen Windows/NET-Programmierer werden.

Ich werde nicht nochmal den Fehler begehen und mit Produkten arbeiten, deren Lebenszyklus durch eine (ungeradlinige) Produktpolitik oder durch finanzielle Risiken eines Herstellers öfters in Frage gestellt wird. Manchmal habe ich es schon bereut, dass ich kein C++ gelernt habe.

Insbes. zwingt auch seit einigen Jahren die Registrierungs- bzw. Aktivierunspolitk einiger Softwareanbieter dazu, genauer zu schauen, ob der Hersteller einer Software auch in finanzieller Hinsicht über einen Zeitraum von mehr als 3 - 5 Jahren
überlebensfähig ist. Wenn ein Softwarehersteller insolvent wird, kann es u. U. sein, dass eine Aktivierung von wieder neu installierten SW-Produkten nicht mehr möglich wird.

Bei Codegear habe ich nicht gerade ein grosses Vertrauen, was die finanzielle Überlebensfähigkeit angeht. Ich denke mal, dass mit der Auslagerung oder der Abspaltung die finanziellen Risiken eher noch gestiegen sind.

Bei einer Fa., wie MS muss ich mir da wengier Sorgen in dieser Hinsicht machen.

Wer mit einem Riesen wie MS konkurrieren will, der muss wirklich sehr schnell und (qualitativ) sehr gut sein.

Da habe ich bei Codegear doch noch erhebliche Bedenken..

Mal schaun, was die Zukunft noch bringt.

Gruss, der Skatspieler

[jbg]

Zitat von hanspeter:

Selbst für ein non break Release wie D2007 kann es doch nicht sein, dass nach ein oder 2 Monaten über 300 Bugs gefixt werden müssen und das ist erst die Spitze vom Eisberg.

Wenn man die ganzen "Bugfixes" der Hilfethemen rausnimmt, bleibt nicht viel übrig. Die meisten Bugs wurden nicht wirklich behoben (zumindest kommt es mir so vor mit den Bugs in die ich reinlaufe).

Zitat:

Wenn im BDS2007 dem Hörensagen ein neuer Compiler daherkommt

Irgendwie bezweifle ich das. Wenn D2007 und C++2007 die vorangeschobenen Personalities sind, dann kann das Gesamtpaket nicht auf einmal nicht mehr abwärtskompatiblen sein. Das fängt schon beim Registry Key BDS\5.0 an. BDS 2007 müsste in Fall eines neuen Compilers auf BDS\6.0 oder sonstwas installieren. Und das bezweifle ich gewaltig. Aber lassen wir uns mal im Herbst überraschen.

Zitat:

VCL.NET war ein Holzweg. Wer braucht ein Framwork als Wrapper für ein Framework ?

Welches Framework hat es den "gewrapped" ? Und wenn du jetzt als Antwort die "WinAPI" schreibst, dann muss ich dich leider darüber informieren, dass WinForms auch auf die WinAPI zugreift.

Zitat:

Wenn es hier ein funktionierendes Konvertierungstool gäbe, das VCL in Net konvertiert, dann gänge diese Entwicklung
noch viel schneller.

Klingt danach dass man sich ein goldenes Näschen verdienen könnte. Leider habe ich dafür aber keine Zeit. *den Jocker weiterreich*

[jbg]

Zitat von Skatspieler:

Wenn ein Softwarehersteller insolvent wird, kann es u. U. sein, dass eine Aktivierung von wieder neu installierten SW-Produkten nicht mehr möglich wird.

Ich nutze da schon seit Delphi 6 die reg***.txt Datei. Einmal per Web aktivieren, Email wegsichern und mehrmals neuinstallieren.

[hanspeter]

Zitat von jbg:

Und das bezweifle ich gewaltig. Aber lassen wir uns mal im Herbst überraschen.

Und genau das ist das Problem!
Ich möchte die Zukunft meiner Firma planen und nicht von einem Hersteller abhängig machen, der mich im Herbst überrascht
oder auch nicht.
Ich will wissen, wann ich mit was rechnen oder nicht rechnen kann und dann planen.
Und mit Framework-Wrapper meine ich die PInvoke Orgie, die Borland.dll und die Tatsache das einen jeder reinrassige
Net Programmierer für geisteskrank erklärt, wenn man mit einer Delphi.net - dll anrückt und er diese einbinden soll.
Das hat sich aber aufgrund des Versionsabstandes Net1.1 -> Net3.0 ohnehin erledigt.
Meines Erachtens ist ja bis jetzt noch nicht einmal richtig klar, ob Codegear an der Net-VCL festhält und
diese nur auf Net 2.0 erweitert oder mit einer tragfähigeren Lösung kommt.
Die Politik von MS, schon lange vor dem Erscheinen eines Produktes RC herauszugeben, schafft halt mehr Planungssicherheit.

Gruß
Peter

[Gecko]

Zitat von Skatspieler:

Mit der 64 BIT Welt dürfte eher das dunkle Zeitalter für Codegear beginnen.

Was hat 64Bit hiermit zu tun? Also nativer 64Bit Code läuft wunderbar auf einem 64Bit OS. Wahrscheinlich sogar noch schneller als managed code.
Wenn man dann einen 64Bit Compiler hat, gehts doch.

[Gecko]

Zitat von hanspeter:

Dabei rede ich noch nicht einmal davon, das sich die VCL von dem Ausflug nach CLX immer noch nicht erholt hat.

Das verstehe ich jetzt nichtso ganz. CLX wurde doch unabhängig von der VCL entwickelt.

[mkinzler]

Zitat:

Dabei rede ich noch nicht einmal davon, das sich die VCL von dem Ausflug nach CLX immer noch nicht erholt hat.

IMHO war nicht der Ausflug zu CLX sondern die fehlende Umsetzung dieser und die Rückkehr zur VCL das Problem. Hätte man den Abkehr von der Plattformabhängigkeit konsequent vollzogen und dann ein CLX.Net satt ein VCL.Net entwickelt wären viele Probleme nicht aufgetreten.

[Edit: Richtiges Zitat eingefügt]

[hanspeter]

Zitat von Gecko:

Das verstehe ich jetzt nichtso ganz. CLX wurde doch unabhängig von der VCL entwickelt.

Öffne eine beliebige VCL Quelldatei deiner Wahl in BDS2006 oder höher.
Auch wenn Kylix gestorben ist, begegnet dir auf Schritt und Tritt

{$IFDEF LINUX}

{$ENDIF}
{$IFDEF MSWINDOWS

{$ENDIF}


Peter