Wie schätzt Ihr die Weiterentwicklung von .NET ein?

[Daniel]

Ach je - in die Richtung pauschaliert ist das ebenso falsch wie es falsch wäre, jedem Trend hinterher zu laufen. Wir alle profitieren von vielen Konstanten, die sich über die Zeit zu Standards etabliert haben. Seien es Übertragungsprotokolle oder CPU-Layouts.

[Meflin]

Zitat von Daniel:

Ach je - in die Richtung pauschaliert ist das ebenso falsch wie es falsch wäre, jedem Trend hinterher zu laufen.

Da hast du sicherlich Recht. Mir geht es auch weniger darum, jedem Trend "hinterherzulaufen" (im Sinne von auf den Zug aufspringen). Aber "die Win32 API gibt es seit XY Jahren, die gibt es auch die nächsten XY Jahre noch, da muss ich mir doch sonst nichts anschauen" ist einfach nicht legitim

(Und da kann man auch Win API mit jeder beliebigen anderen Technologie austauschen)

[Assarbad]

Zitat von Meflin:

Da hast du sicherlich Recht. Mir geht es auch weniger darum, jedem Trend "hinterherzulaufen" (im Sinne von auf den Zug aufspringen). Aber "die Win32 API gibt es seit XY Jahren, die gibt es auch die nächsten XY Jahre noch, da muss ich mir doch sonst nichts anschauen" ist einfach nicht legitim

Korrekt. Aber die Attitüde sich lieber nicht mit den Interna (also bspw. Win32-API) zu beschäftigen herrscht in meinem Umfeld vor. Meiner Meinung nach zu unrecht, wie man immer wieder dann sieht, wenn die Leute bei Problemen nicht weiterkommen und fragen. Etwas Grundlagenwissen würde in vielen Fällen aber schon den Weg zur Lösung aufzeigen.

Nur bei .NET kann man ja wohl kaum mehr von "early adopters" sprechen

[mquadrat]

Ich gehöre - wenig überraschend - auch zu denen, die sich möglichst weit entfernt von der WinAPI aufhalten. Ist halt eine Geschmackssache. Ich persönlich bin der Ansicht je weiter sich die Programmierung von den unteren Ebenen löst, desto besser. Manchmal steht man dann natürlich dumm da, wenn niemand einen Wrapper geschrieben hat und man doch wieder an die WinAPI ran muss. Aber irgendeinen Tod muss jeder sterben.

Den Sinn von J# habe ich noch nie verstanden, genau wie ich auch den Sinn von Prism nicht verstehe.

Das eigentliche Thema ist ja die Weiterentwicklung. Bei .NET sehe ich da einfach viel Potential. MS hat einfach eine große R&D Abteilung, die können verschiedene Sachen ausprobieren, schauen was sich sonst noch so auf CodePlex tut und das ganze dann implementieren. Die R&D bei Emba ist selbstverständlich wesentlich kleiner und muss sehr zielgerichtet vorgehen. Viele der OpenSource-Entwicklungen / Experimente im Delphi-Umfeld laufen aus. Die Anzahl der Fremdquellen ist also auch kleiner. Das begrenzt natürlich die Möglichkeiten. Ich bin mir allerdings ziemlich sicher, dass die neue Cross-Plattform GUI ein neues Databinding kriegt und MVVM unterstützen wird - alles andere wäre schwer nachzuvollziehen. Emba hat IMHO eine gute Chance. Sie können schauen was im .NET Umfeld passiert, welche Entwicklungen angenommen werden und welche verworfen werden und nur das angenommene übernehmen. Dazu kommt, dass (fast) jedem Delphi-Entwickler klar ist, dass ein Umbruch ansteht.

Alles was ich gerne in Delphi hätte hängt ja mehr oder weniger zusammen. Hat man ein Databinding mit dem man Objekteigenschaften schnell und einfach binden kann (und die neue RTTI schafft ja die Voraussetzungen dafür), dann macht es Sinn über einen ORM nachzudenken bzw. eine neue Datenschnittstelle, die u.a. mit einem ORM ausgestattet ist. Hat man Modell und Bindung ist MVVM nur noch ein kleiner Schritt. Und geschickt eingesetzt kann man mit der Bindung auch gleich die Grundlagen einer Workflow-Engine mit long-running Transactions abwickeln. Und sollte die neue GUI auf einem XML-Dialekt basieren kann man den Workflow-Editor mit eigenen Aktivitäten auch recht simpel dazu bauen. Aber genug geträumt

Was aber ganz klar ist: Die Stärke von Delphi war immer die Abwärtskompatibilität soweit möglich. Das ist ein guter Ansatzpunkt....