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.

[Insider2004]

Zitat:

Zitat von Meflin (Beitrag 1083302)

Zitat:

Zitat von Insider2004 (Beitrag 1083299)

Die einzige zuverlässige Konstante in den letzten 15 Jahren war die Windows-API.

Wer in dieser Branche auf zuverlässige Konstanten setzt macht meiner Meinung nach ja schon grundlegend was falsch ;)

Emba muss gerade teuer dafür bezahlen. J# wird von MS eingestellt und jetzt müssen Teile der Delphi-IDE umgeschrieben werden. Mahlzeit!

[Stevie]

Zitat:

Zitat von Mithrandir (Beitrag 1083297)

Zitat:

Zitat von Stevie (Beitrag 1083293)

Ich drücks mal bewusst provokativ aus:
Standard ORM in Delphi? Nicht vorhanden. Braucht man das? Nö, kannst auch ne Dataset auffe Form packen ...
Workflow Engine und MVVM? Wieso, bei mir kommt der Sourcecode ins Button Click Event, wo dann auf mein Dataset zugegriffen wird ...

Ich formuliere es mal vorsichtig, bezogen auf meine Aussage von vorhin: Es ist tatsächlich so, dass es auch eine Frage des Alters ist. Jemand, der die 50 Jahre schon überschritten hat, wird sich lieber auf Altbekanntes berufen, als irgendetwas Neues zu lernen. Ich erlebe das gerade, und ich sags ohne Umschweife: Wenn man in der Position des Jüngeren ist, ist das manchmal echt fürn Arsch...

Stimmt, der Unterschied ist aber, dass .Net und die dementsprechende IDE (Visual Studio) solche Werkzeuge schon mitbringt. Bei Delphi ist sowas quasi nicht existent und muss wenn überhaupt entweder für teures Geld zugekauft werden oder ein hoffnungslos veraltetes open source framework (wenn ich mir z.B. diverse ORM Dinger für Delphi anschaue) genutzt werden.
Und das ist es, was für mich die Weiterentwicklung von .Net so vielversprechend macht.

Zitat:

Zitat von Insider2004 (Beitrag 1083304)

Zitat:

Zitat von Meflin (Beitrag 1083302)

Zitat:

Zitat von Insider2004 (Beitrag 1083299)

Die einzige zuverlässige Konstante in den letzten 15 Jahren war die Windows-API.

Wer in dieser Branche auf zuverlässige Konstanten setzt macht meiner Meinung nach ja schon grundlegend was falsch ;)

Emba muss gerade teuer dafür bezahlen. J# wird von MS eingestellt und jetzt müssen Teile der Delphi-IDE umgeschrieben werden. Mahlzeit!

Jau, J# war ja auch seinerzeit ne megaverbreitete Sprache und ... oh halt, war sie nicht!
Das ist echt ein Beispiel, sich erstmal Gedanken zu machen, bevor man etwas einsetzt und auf diese Technologie baut. Soll aber nicht heißen, dass man alles Neue gleich als Unfug und gabs schon und taugt eh nix abtut.

[Meflin]

Zitat:

Zitat von Daniel (Beitrag 1083303)

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 :stupid:

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

[Assarbad]

Zitat:

Zitat von Meflin (Beitrag 1083307)

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 :stupid:

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 :zwinker:

[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 :oops:

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

[MGC]

Es ist faszinierend wie schnell ich hier innerhalb sehr kurzer Zeit einen recht umfassenden Eindruck von momentanen Vorgängen in der IT-Welt kurzgefasst vorgefunden habe.
Ich habe auch festgestellt, dass ich mich in den letzten Jahren zusehr auf meine eigenen betriebsinternen kleinen Projekte konzentriert habe und daher kaum etwas von den Umbrüchen, die ich bei Vista noch nicht so deutlich wahrgenommen habe, mitbekommen habe, die anscheinend jetzt durch Win 7 forciert werden.

Da ich von Zeit zu Zeit auch mal kleine Seitenabstecher mit betriebsexternen Projekten habe (bei denen ich bisher nur Zuarbeit im Kleinen zu erledigen hatte), sehe ich nun durch diese Diskussion bei mir sehr großen Nachhol- und Weiterbildungsbedarf.

Um mir endlich mal einen Eindruck von den Unterschiedenen zwischen Delphi für .NET und Prism zu verschaffen, lade ich mir mal die Trial runter und probier einfach mal ein wenig herum.
Ausserdem scheint es für mich auch mal an der Zeit zu sein meine Heimtechnologie ein wenig aufzurüsten (Werde aber die Altrechner für Testzwecke am Leben erhalten).

Zitat:

Zitat von Assarbad (Beitrag 1083018)

Zitat:

Zitat von MGC (Beitrag 1083013)

[...] dann kann ich mir nicht vorstellen, dass vollberufliche Entwickler nur an einer Sprache oder Plattform "kleben".

Doch, auch die gibt es. Es gibt auch das genaue Gegenteil: jene die immer dem neuesten Trend hinterherlaufen ohne die Vor- und Nachteile abzuwägen.

Aber die neuesten Buzzwords finden sich eben auch in Zeitschriften die von "Entscheidern" gelesen werden, so daß man ggf. beim Bullshit Bingo gewinnen kann :zwinker:

Die "aufgeschlossenen Technologiestürmer" kenne ich, habe zeitweilig in jüngeren Jahren mal selbst dazugehört und bin dabei in einige Sackgassen geraten, die mich zum Umdenken gezwungen haben.
Doch die andere Seite? Gut, es gibt immer mal die ein oder andere Sprache die man lieber auswählt, da sie einem möglicherweise vertrauter ist, doch sollte man auch ehrlich zu sich selbst sein und die Anforderungen an ein zu entwickelndes System prüfen bevor man eine Sprache wählt.
Die Sache mit den "Entscheidern" kenne ich da schon eher wieder, wobei (muss ich mal Kleinlaut zuegeben) manchmal auch tatsächlich Leute mit einem guten Händchen und Feingefühl dabei sind.

Zitat:

Zitat von Assarbad (Beitrag 1083018)

Zitat:

Zitat von MGC (Beitrag 1083013)

Und der letzte Clou ist dann die GC, die es auch dem unerfahreneren Proggern (zu denen ich mich auch dazuzähle) erlaubt sich mal einen Lapsus zu gönnen und ein schönes Speicherleck zu produzieren, das dann lächelnd von der GC beseitigt wird und das System nicht bis zum Neustart zumüllt.

Das kommt auf den GC-Typ an. Allerdings ist es ein Mythos (wenn auch ein sehr beliebter), daß GC einen davon befreit sich um Speicher Gedanken zu machen ...

Natürlich befreit einen die GC nicht vom Freigeben des Speichers, es sei denn man möchte es sich gern in einem größeren Projekt mal richtig mit den anderen Teilnehmern oder dem Auftraggeber verscherzen.
Ein Problem der GC ist vielleicht eher, dass man seine Fehlerchen bei Unachtsamkeit erstmal gar nicht recht bemerkt, bis einem mal jemand bescheid gibt, warum nicht mehr benötigte Objekte noch elends lang im System herumgeistern oder sogar erst freigegeben werden, wenn das Programm beendet wird. Dabei mal von anderen sicherheitsrelevanten Speichernutzungen ganz abgesehen, die man ohnehin vollkommen anders behandelt.

[Insider2004]

Soviel ändert sich gar nicht, wie man meint. Schaut euch mal Windows 2000 an. 12 Jahre alt. So viel Interfaceänderungen zu Windows 7 z.b. hat es gar nicht gegeben. Ich sehe zwischen den beiden OSen kaum einen Unterschied. Klar, Quickie-Bunti hat sich verändert, aber der technische Rest unter der Haube ist fast gleich geblieben.

Genauso mit Delphi. Seit Delphi 2 bis Delphi XE hat sich kaum was getan. Z.B. ist in Delphi XE immer noch der gleiche Floating-Point-Generator drin wie schon bei Delphi 2. Der Code ist der gleiche. Auch das Win32-Backend ist nahezu identisch. Im Prinzip alles nur Kosmetik. Einen Schub wird natürlich Delphi Win64 bringen.

[MGC]

Zitat:

Zitat von Insider2004 (Beitrag 1083692)

Einen Schub wird natürlich Delphi Win64 bringen.

Ahhh... Du meinst also das neue Delphi NotDead anstelle von Delphi DotNet...:sharkylinchen:

Ich hoffe das uns Delphi Win32 (schon aufgrund meiner Projekte, die ich vorerst nur noch warten und nicht mehr umheben möchte) noch lange erhalten bleibt und ich bin auch offen für Delphi Win64, auch wenn ich durch diese Diskussion sehr neugierig auf .NET-Sprachen geworden bin und mal reinschnuppern werde.

[Assarbad]

Zitat:

Zitat von Insider2004 (Beitrag 1083692)

Soviel ändert sich gar nicht, wie man meint. Schaut euch mal Windows 2000 an. 12 Jahre alt. So viel Interfaceänderungen zu Windows 7 z.b. hat es gar nicht gegeben.

Is nicht dein Ernst, oder?

Hier ein paar Stichworte:

• Session Separation
• Integrity Levels
• UAC
• Second User Logon (implementiert über RDP)
• Neue Taskbar (inkl. der entsprechenden, komplett geänderten Interfaces)
• Direct2D
• Transaktionen (KTM, TxF)
• Common Log File System (CLFS)
• Restart Manager
• Multilingual User Interface (MUI)
• NUMA Support

Das kratzt zwar nur an der Oberfläche, ist aber auch nur was mir so einfiel. Versuch mal eine GINA oder einen Mirror-Treiber zu schreiben der auf all diesen Betriebssystemen läuft. Dir könnte mit Schrecken auffallen, daß es GINAs nicht mehr gibt seit Vista und das bei den Treibern ein wenig mehr Vorkehrungen notwendig sind als deine Äußerungen vermuten ließen.

Über die Details am Kernel die sich sonst noch so geändert haben, bzw. dazugekommen sind, wollen wir mal nicht weiter reden, denn dort sind die Änderungen zum Teil noch gravierender. Und nur um mal ein schönes Beispiel zu geben: MmGetSystemRoutineAddress war unter Windows 2000 verbuggt. Auch wenn die zurückgegebene Adresse nicht aufrufbar war, wurde manchmal nicht NULL zurückgegeben. Solcherlei APIs sind es die man nur bedingt verwenden kann wenn der Treiber auf verschiedenen Systemen laufen muß.

Zitat:

Zitat von Insider2004 (Beitrag 1083692)

Ich sehe zwischen den beiden OSen kaum einen Unterschied. Klar, Quickie-Bunti hat sich verändert, aber der technische Rest unter der Haube ist fast gleich geblieben.

Dann hast du leider nicht genau genug hingeguckt.

Fazit: nur weil du nicht in der Lage oder gewillt bist dir die Änderungen "unter der Haube" anzuschauen, verschwinden diese Änderungen nicht einfach :zwinker:

Ich kannte bis Windows 2003 die meisten APIs aus dem Bereich user32, kernel32, advapi32, shell32 und diversen anderen Bereichen, sowie diverse Interfaces nahezu auswendig. Vielleicht muß man dann erstmal die Liste der mit Vista und 7 hinzugekommenen Funktionen anschauen um zu begreifen wie weitgehend die Änderungen sind. Wohlgemerkt, die Grundlagen sind oft noch gültig - an sehr vielen Stellen haben sich aber auch einfach zusätzliche Einschränkungen ergeben. Es ist also wahrscheinlicher, daß ein Programm welches auf Windows 7 abzielt mit ein paar Vorkehrungen auch auf Windows 2000 läuft, umgekehrt aber vielfach fehlschlagen oder dank Application Compatibility Shims (sowas wie Krücken) am Laufen gehalten werden - das übrigens bereits seit XP.

Ignorance is bliss? Ich denke eher nicht :zwinker: