Ist Delphi wirklich tot.

[Daniel]

Sie werden ja in 2007 die Lücke zu .NET II schließen. Nur dürfen sie sich dann nicht darauf ausruhen und müssen schleunigst noch im gleichen Jahr .NET III integrieren. Im kommenden Jahr haben sie also eine echte Chance, die Lücke zu schließen und somit wieder eine Alternative zum VisualStudio zu werden. Wenn das klappt, ist's gut, wenn nicht ... naja, dann ... öhm ... jedenfalls werden die Kunden nicht ewig bereit sein, mit diesem großen Abstand hinter .NET her zu laufen. Das ist außerdem schlecht für das Image und zieht das gesamte Produkt runter. Leider.

[Elvis]

Zitat von Daniel:

Sinnvoll heißt in diesem Zusammenhang wenigstens die Lücke zu .NET II und III zu schließen

Sinnvoll heißt IMHO: Bin ich mit Sprache X produktiver als in Y, werde ich auch in Zukunft in Sprache X Zugriff auf neue Technologien haben bevor sie final werden.
Das heißt kann ich sie evaluieren oder sogar ihren Impact auf meine Projekte evaluieren bevor sie final werden. Kann ich selbst einen gewissen Wissenstand in dieser Technologie aufbauen bevor sie Final wird? Und kann ich dadurch einem Kunden eine darauf basierende Lösung kurz nach RTM dieser Technologie anbieten?
Das wäre eine sinnvolle Sprache, verglichen mit all den anderen .Net Sprachen.
Nicht vergessen: der Funktionsumfang ist unter den meisten .Net Sprachen praktisch der gleiche.
Delphi und Chrome mögen hier durch MetaClasses hervorstechen, aber das ist nun wirklich kein must-have.

Zitat:

nativer Code für Win64 hilft da auch nicht viel, denn es gibt wahrlich nur wenige Anwendungen, die ernsthaft von 64bit-Code profitieren würden.

Nehmen wir mal, du bietest eine Shell extension zu deiner Anwendung an. Nun, unter Win64 kannst du diese nehmen und wegschmeißen. Man kann keine 32Bit DLL in einen 64Bit Prozess laden.
Oder die guten alten ISAPI Filter, wer schreibt denn sowas in Delphi? Na, da sehe ich doch einige, die ihre Hand heben.
Tja, wenn der Kunde auf einen neuen 64Bit Server umsteigt kannst du dich von ihm verabschieden.
Ein 64Bit IIS kann schließlich keine Delphi(32) DLL laden.

64Bit mag für den klassischen Client/Server App-Dev unnützes Whizzbang sein, aber für einige ist es praktisch das Aus, wenn ihnen nicht schnell ein Ausweg einfällt.
Nicht wenige überlegen sich sogar ganz von Pascal abzuschwören, einige hoffen auf FreePascal...

[hanspeter]

Zitat von Daniel:

Sie werden ja in 2007 die Lücke zu .NET II schließen. Nur dürfen sie sich dann nicht darauf ausruhen und müssen schleunigst noch im gleichen Jahr .NET III integrieren.

Zwei Updates in einem Jahr.
Bei den Borland Apothekenpreisen.
Wer soll das bezahlen?


Was ist mit Delphi-Net einfacher, schneller produktiver ?
Nur das zählt.
Kann Delphi-Net keinen Mehrwert gegenüber VS2005 bieten, brauche ich es
irgendwann nicht mehr.

Gruß Peter

[Daniel]

@Elvis:
Die letzte, die von Dir beschriebene, Technologie-Lücke zu Microsoft können sie nie schließen, da diese ganzen Sachen ja genau von dort aus Redmond kommen. Wer wirklich stets auch aktuelle Technologien einsetzen will, bevor sie final werden, der muss bei Microsoft bleiben. Aber das sehe ich nicht als das Haupt-Problem an, sie müssen nur sehen, dass sie selber auch schon im Beta-Zyklus der jeweiligen Technologien mit entwickeln und nach den jeweiligen Finals in endlicher Zeit eine Lösung haben.

Mit den Shell-Extensions hast Du Recht - aber das ist doch nur, wenn man den Markt betrachtet, eine weitere Nische. Und selbst die Summe der Nischen gibt doch nicht wirklich was her.

[Catbytes]

Solange noch Spiele in Win32/64/wasauchimmer produziert werden, wird diese Plattform nicht aussterben.

Ich kenne kein Spiel, das auf .NET aufbaut. Ich kann mir auch kein Anno, Sims, wasauchimmer in .NET vorstellen.

Unterschätzt die Spieleindustrie nicht - die ist mittlerweile größer als Hollywood.

[Nils_13]

Zitat von Catbytes:

Solange noch Spiele in Win32/64/wasauchimmer produziert werden, wird diese Plattform nicht aussterben.

Ich kenne kein Spiel, das auf .NET aufbaut. Ich kann mir auch kein Anno, Sims, wasauchimmer in .NET vorstellen.

Unterschätzt die Spieleindustrie nicht - die ist mittlerweile größer als Hollywood.

.NET ist einfach (zum Glück ) mommentan noch zu lahm und außerdem: wieso will ich überhaupt mein System updaten ? Es muss auch ohne laufen. .NET ist nur dazu da, damit ein paar reiche Säcke noch mehr Kohle über's Internet verdienen können. Das ist meien Auffassung dazu.

[Hansa]

Zitat von DGL-luke:

@Hansa: Wenn ich irgendwoher eine umfassende Ausbildung fürs .Net-Framework kriegen würde ... würde ich neue Projekte nur noch in .Net anfangen.
Ich glaube nicht, dass .Net sich irgendwann im Sande verläuft.

Das glaube ich erst, wenn ich es auch sehe. Es gibt namhafte Softwarefirmen, die definitiv .NET vorerst links liegen lassen ! Betonung liegt auf vorerst !! Deshalb auch die Anmerkung über Word.NET. Luckie hat die Wirtschaftlichkeit angesprochen. Und das heißt : was kostet eine komplette Neuentwicklung ? Welche Vorteile würde das bringen ? Bei krachneuen Projekten wäre die Frage : was kostet die Aufrüstung auf Vista ? TCO ist das Stichwort.

[DGL-luke]

Zitat von bernau:

Zitat von DGL-luke:

Denn außer Win32 kann man mit Delphi im Moment nichts vernünftiges machen.

So so.

Lustig ist es dann immer, wenn ich diese Floskel höhre und im gegenzug Frage, "was kann ich mit DotNET machen, was ich mit Win32/64 nicht machen kann?". Dann mal Butter bei die Fische. Erklärt es mir. (Nicht nur Du. Luke)

Ich lass mich ja gerne überzeugen. Aber bis jetzt habe ich noch nichts überzeugendes gehört, ausser daß DotNet der Standart der Zukunft ist.

Gerd

Wen interessierts was man damit machen kann? Irgendwann wird Microsoft nur noch Win64 für Treiber und .Net für Usermode-Code unterstützen... Schluss, aus, Ende, Delphi32 rest in peace. So einfach ist das.

natürlcih ist das etwas überzogen.

Das vermeintliche Totschlagargument "zeig mir irgendwas was in Win32 nicht geht" ist keines mehr, sobald Win32 nicht mehr existiert...

Im übrigen halte ich .Net für sehr viel besser als natives Coden. .Net nimmt einem einfach so viel Arbeit ab...

[Phoenix]

[quote="Nils_13"]

Zitat von Catbytes:

Solange noch Spiele in Win32/64/wasauchimmer produziert werden, wird diese Plattform nicht aussterben.

Ich kenne kein Spiel, das auf .NET aufbaut. Ich kann mir auch kein Anno, Sims, wasauchimmer in .NET vorstellen

http://www.coding4fun.de bzw. RocketCommander http://www.microsoft.com/germany/msd...v/default.mspx
Gibt's da Sogar mit Source. Und der ist für ein 3D-Spiel erstaunlich wenig. .NET macht's möglich.

Zudem ist es so, dass die neuen Konsolenspiele für die XBox 360 eigentlich nur noch in .NET angefangen werden und damit sowohl auf der XBox als auch auf dem PC laufen werden. Managed DirectX 10 zieht Dir die Socken aus.

Viele PC-Spieler-Hersteller werden sich die Chance nicht mehr lange nehmen lassen, ihre Spiele an einen zusätzlichen Kundenkreis (Konsolen-Spieler) verkaufen zu können - ohne Mehraufwand(!). Dafür steckt in dem Markt zu viel Geld was die sich nicht entgehen lassen wollen.

Wieso sollte ich ein Spiel jetzt noch in C++ anfangen, wenn ich massig Aufwand haben werde das auf eine Konsole zu portieren und ich zudem noch eine unmanaged API verwenden muss, wenn ich doch die Möglichkeit habe das gleiche mit weniger Aufwand und sicherer zu schreiben?

[phXql]

Zitat von Nils_13:

Zitat von Catbytes:

Solange noch Spiele in Win32/64/wasauchimmer produziert werden, wird diese Plattform nicht aussterben.

Ich kenne kein Spiel, das auf .NET aufbaut. Ich kann mir auch kein Anno, Sims, wasauchimmer in .NET vorstellen.

Unterschätzt die Spieleindustrie nicht - die ist mittlerweile größer als Hollywood.

.NET ist einfach (zum Glück ) mommentan noch zu lahm und außerdem: wieso will ich überhaupt mein System updaten ? Es muss auch ohne laufen. .NET ist nur dazu da, damit ein paar reiche Säcke noch mehr Kohle über's Internet verdienen können. Das ist meien Auffassung dazu.

Ich bezweifle, dass .NET soviel lahmer is als Win32. Grund? Just-in-time compiling. Der Managed Code wird mit allen möglichen Optimierungen einmal kompiliert, dann ist er kompiliert im Speicher. Win32 mag jetzt noch schneller sein, wenn allerdings eine neue CPU mit SSE3 oder was weiss ich rauskommt, und das .NET-Framework wird daran angepasst, dann wird .NET schneller sein.