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...