.NET Diskussion

[Jelly]

Dann häng ich den mal wieder hier dran:

Zitat von JasonDX:

Niemand zwingt dich, .NET zu nutzen. Du kannst gerne bein Win32 bleiben. Du kannst auf den .NET-Zug aufspringen oder davon überfahren werden. Its your choise.

So schnell stirbts sich nicht
Auf den Delphi Tagen wurde mal quer durch den Raum gefragt, wer von den Anwesenden aktiv .NET Applikationen schreibt. Von den 250 Teilnehmern waren das vielleicht mal gerade 10.

Es muss nicht immer alles in den Himmel gelobt werden, was neu und besser sein soll. Der Meinung von den Handymarketing Leuten nach brauchen wir ja alle Handys mit Kamera, Filmen, MP3 Playern und Fön. Aber ist das wirkich so. Ich nutze mein Handy zum Telefonieren und SMSen, das wars. Wär mir lieber es würd dafür ein paar mal weniger am Tag abstürzen, als diesen ganzen Kram mitzuschleppen, den ich nie brauche.

Ich sehe da ein Analogon zur ganzen .NET Thematik. Ist sicherlich ne feine Sache, und ich bin selbst auch als Entwickler dabei, mich intensiver damit auseinanderzusetzen. Aber ein gesundes Mistrauen ist imho immer bei allem angebracht.

Wir werden sehen was die Zeit bringt, und für den Fall, dass nachher wirklich alles auf .NET rausläuft, muss man einfach nur gewadmet sein.

Schaun mer mal.

Ich wollte einfach mal bischen die Gmüter beruhigen. Es gibt Pros und Contras sowohl zu Win32 als .NET. Lasst uns das erst mal akzeptieren.

[Christian Seehase]

Moin Zusammen,

also ich für meinen Teil sehe .NET auch als eine geschickte Strategie, von der, mittlerweile doch sehr gut dokumentierten API abzulenken.
Die "normale" Win32-API (gilt analog natürlich auch für Win64) wird uns wohl noch lange erhalten bleiben, mindestens so lange, bis der Nachfolger von Vista auf den Markt kommt, und selbst der, erwarte ich jedenfalls, wird wohl zumindest noch einen Emulator dafür haben.

Ein Grossteil der Win32-API wird ja vom .NET-Framework gekapselt, aber so manche interessante Funktion muss man sich schon selber importieren (oder ich bin nicht in der Lage sie zu finden )

[Christian S.]

Zitat von Jelly:

Auf den Delphi Tagen wurde mal quer durch den Raum gefragt, wer von den Anwesenden aktiv .NET Applikationen schreibt. Von den 250 Teilnehmern waren das vielleicht mal gerade 10.

Ohne mich am Rest der Diskussion beteiligen zu wollen (die gab es schon zu oft, als das mich das noch reizt), das ist nicht sehr repräsentativ. Mit Delphi kann man nicht soooooo toll .NET entwickeln (alleine schon, weil kein .NET 2.0 unterstützt wird), da wundert mich die geringe Rate nicht.

[Elvis]

Zitat von Christian S.:

Zitat von Jelly:

Auf den Delphi Tagen wurde mal quer durch den Raum gefragt, wer von den Anwesenden aktiv .NET Applikationen schreibt. Von den 250 Teilnehmern waren das vielleicht mal gerade 10.

Ohne mich am Rest der Diskussion beteiligen zu wollen (die gab es schon zu oft, als das mich das noch reizt), das ist nicht sehr repräsentativ. Mit Delphi kann man nicht soooooo toll .NET entwickeln (alleine schon, weil kein .NET 2.0 unterstützt wird), da wundert mich die geringe Rate nicht.

Der Hauptgrund wird die doch sehr nette Art sein, durch die Delphi OO wurde. Delphi wird in den Borland NGs nicht ganz ohne Grund als einzige "native c#-like language" bezeichnet.
Die VCL mag ein anderer Grund sein. Sie ermöglicht zu einem gewissen Grad ähnlich produktiv zu entwickeln wie es mit .Net möglich ist.
Auf den ersten Blick sehen es viele nicht ein, einen zweiten Blick zu riskieren.
Noch ein Grund dürfte Delphi.Net ein, welches soviele versteckte Quirks enthält um unter .Net noch ein D32-Verhalten vorzutäuschen. Da die Sprache nicht wirklich an .Net angepasst wurde stösst man sich oft die ellbogen an den neuen Geflogenheiten in dieser neuen Welt.
Wer .Net mit D.Net kennenlernt dürfte also noch ein paar willkommene Gründe vorfinden, warum er keinen 3. Blick riskieren will.

Für mich bedeutet .Net hauptsächlich GoodBye Units, Good Bye DCUs und eine riesige in sich konsistente Klassenbibliothek.

Letztlich gab es hier einen Thread über den schnellsten MD5 Algo. Nunja, der in System.Security.Cryptography ist sackschnell, genau wie Sha, AES, Rinjdael und Co.

Für native Spielereien nehme ich gerne Alzis Hashlisten, in .Net habe ich generische Dictionaries, SortedDictionaries, TreeSets,...
Alle implementieren Interfaces wie IDictionary<K, T>, so dass auch eine eigene Implementierung mit den restlichen Klassen kompatibel bleibt.
Wo wir bei Interfaces sind: .Net ist von vorne bis hinten interfacebasiert
IEnumerable ermöglicht foreach/for in, zusammen mit IList und IBindingList sollte sich das Interface aber schon rumgesprochen haben...
Es gibt aber mehr:
Du nimmst eine bestehende Klasse, verpasst ihr IComponent und kannst sie auf den Designer ziehen. (WinForm, WebForm, Service, WebService und Component)
Du implmentierst IListSource und du kannst sie als DatenQuelle im Designer an Controls binden. Du implementierst ITypedList und hast 100% Kontrolle was wie gebunden werden kann[1].
IBindableComponent lässt dich Daten an Properties deiner Klasse binden...
IEditableObject lässt dich darauf reagieren wenn der User in einem an deine Property gebundenen Control Esc drückt oder die in SWF integrierte Validierung fehlschlägt.

Zu D32 konnte ich mich nie mit dem DB-Aware Dingsens anfreunden, DataBinding in .Net möchte ich nicht mehr missen.
Kurz gesagt: Es ist einfach ungeheuer mächtig.
Bei weiteren Fragen konsultieren sie einfach ihre lokale .Net SDK Doku.

Ich bin echt froh, dass ich mich damals so dermaßen über D8 geärgert habe[2].
Wäre es benutzbar gewesen, hätte ich .Net wohl nie _richtig_ kennen und schätzen gelernt...

[1]auf die Art übersetzt z.B. ein DataSet den object array an Daten in einer DataRow in Properties, die man irgendworan binden kann.

[2]Ich war sooo bescheuert und hatte ein Upgrade von D7Pro auf D8Arch gekauft
Thx for the Road show

[Bernhard Geyer]

Zitat von JasonDX:

Niemand zwingt dich, .NET zu nutzen. Du kannst gerne bein Win32 bleiben. Du kannst auf den .NET-Zug aufspringen oder davon überfahren werden. Its your choise.

Cooler Spruch Auch wenn der .NET-Zug zwar als Transrapid (was die Verbreitung betrifft) vom Marketing versprochen wurde aber aktuell noch eher einer älteren Diesellock gleicht. Evtl. wird ja mit Vista und Avalon der Turbo gezündet.

Zitat von ultrasombrero:

Stimmt, nicht NUR das macht DotNET schlecht, auch die langsamere Ausführungsgeschwindigkeit,

Wäre mir neu . In 95% der Fälle kommt man mit Delphi nicht an die Ausführungsgeschwindigkeit von .NET. Das einzige was jetzt noch "nervt" ist das auf vielen Rechnern beim ersten Start einer .NET-Anwendung das Framework gestartet werden muß. Aber das "Problem" wird MS sicherlich auch bald für XP/2000 in den allgmeinen Windows-Start verlagern.

Zitat von ultrasombrero:

die Abhängigkeit von einer riesigen Runtime-Library,

Und wovon hängt deine Delphi-Anwendung ab? Von einer sehr großen Bibliothek (VCL) und einem riesigen Win32-API

Zitat von ultrasombrero:

und die Vereinfachung des Crackens.

Und wieso das. Wegen einfachen herausfinden des Quellcodes aus Assemblies. Wozu gibt es Obfuscator?

Zitat von ultrasombrero:

Mit DotNET hat Microsoft eine Seuche geschaffen, die fast so schlimm wie Java ist, sich aber wohl leider noch deutlich weiter ausbreiten wird

M$ mußt etwas machen um nicht den Anschluß zu verlieren. MFC/ATL sind sowas von kompliziert und unproduktiv zu verwenden und die MS-Java-Version wurde ja per Gericht gestoppt. Also hat man man einige Kluge köpfe zusammengesetzt um eine neue produktivere Klassenbibliothek zu schaffen um auch den eigenen Wildwuchs von Klassenbibliotheken etwas auszudünnen.

[Boombuler]

Hi

.NET ist in meinen Augen der einzig richtige Schritt, denn W32-API wird auf dauer aussterben. Ich bin zwar noch auf dem W32 Zug. Das liegt aber nicht an mir sondern an Cheffe Das wird sich aber auch bald ändern. Mir persönlich ist es relativ egal welche "Sprache" ich nun schreibe ob es D.NET oder D-W32 ist... wenns sein muss würd ich den Prozessor auch direkt mit OP-Codes füttern.
Nur irgendwie trauer ich jetzt schon meinem W32-API-Wissen nach

Zusammenfassend und auf lange Zeit gesehn kann man .Net mit den Worten beschreiben: Do or Die

(Kommt mir das nur so vor oder is mein Betrag relativ zusammenhangslos??)

Greetz
Boombuler

[Daniel]

Wenn man sich als ITler gegen .NET sperrt, so ist man entweder in gänzlich anderen Gefielden unterwegs oder man betreibt karrieretechnischen Selbstmord.

Die Win32 wird uns noch ein paar Jahre ernähren und wir werden in dieser Zeit weiterhin unsere Win32-Anwendungen anbringen können. Aber irgendwann ist eben Schluss - und dieser Prozess ist doch schleichend. Mehr und mehr Produkte von Drittanbietern werden die Win32-Unterstützung aufgeben und auch in der Wahrnehmung der Kunden (diese Wahrnehmung wiederum entscheidet mit über unsere Knete) werden Win32-Anwendungen in einer Handvoll Jahren veraltet sein.

A propos "veraltet": Es ist mir schleierhaft, warum die Frage der Objektorientierung in regelmäßigen Abständen wieder hochkommt. Das Thema hat nichts mit Delphi, Windows oder .NET zutun, sondern es ist eine Frage der Software-Architektur. Wenn man sich mal umguckt, wird man feststellen, dass die OO einen etablierten Platz in der Software-Entwicklung eingenommen hat und das nicht zu unrecht. Murks kann man immer machen - aber das ist doch gar nicht die Frage.


Ich überlege, ob diejenigen, die sich gegen .NET sperren, sehr jung oder schon recht alt sein mögen. Wer jung ist, in der Branche bleiben will und sich gegen neue Technologiene wie .NET sperrt, handelt naiv. Wer bereits das eine oder andere Dutzend an Jahren Berufserfahrung gesammelt hat, der sollte wiederum schon den einen oder anderen Framework-Wechsel miterlebt haben und auch wenn die jeweils eigenen Projekte nicht umgestellt wurden, so sollte doch der Gedanke nichts Neues sein, sich jede Dekade in eine neue Technik einarbeiten zu müssen.

[alcaeus]

Moin moin,

naja, die WinAPI wird so schnell nicht aussterben, allerdings ist sie eben "deprecated". Ich sehe eindeutig einen Vorteil in Sprachen wie Java, C#, usw. Das Wort "Plattformunabhaengigkeit" sollte wohl alles sagen. Damit muss ja nicht unbedingt eine Unabhaengigkeit zwischen Linux und WIndows gemeint sein; nein, auch eine Unabhaengigkeit zwischen einzelnen Windows-Versionen waere schon was. So weiss man wenigstens, dass wenn man eine App fuer .NET 1.1 kompiliert, sie auch dort laufen wird. Wenn ich eine Win32-App kompiliere, dann ist dies nicht gegeben.

Von der .NET-Programmierung zu unterscheiden ist aber die objektorientierte Programmierung. Wer stur gegen OOP ist, no matter what, der hat den Zug definitiv verpasst und sollte entweder ueber Rente oder Umschulung nachdenken. Es ist ein Programmierkonzept, das sich durchgesetzt hat, weil es gut ist. Nicht weil wir gerne Punkte machen, nicht weil wir Funktionsaufrufe extrem lang machen wollen, nein, ganz einfach weil es (mir zumindest) logisch einleuchtet. Wenn ich einen Integer habe, dann sollte dieser seine Konvertierungsroutinen mitbringen. Wenn ich eine Struktur XYZ habe, waere es dann nicht einleuchtender, die Funktionen, die eine Struktur erfordern, direkt in die Struktur einzubauen? Also anstatt:

Code:

DoSomeThingWithMyStructure(MyStructure, Param1)

ganz einfach

Code:

MyStructure.DoSomeThing(Param1)

Joa, ist sogar kuerzer...solange nicht weissgottwieviele Unterklassen da sind wird es das auch bleiben. Aber darueber wurde schon oft diskutiert, und nie kamen wir zu einem gruenen Zweig. Es laesst sich nur eines sagen: das perfekte Programmierkonzept gibt es einfach nicht.

Greetz
alcaeus

[Phoenix]

Zitat von alcaeus:

Das Wort "Plattformunabhaengigkeit" sollte wohl alles sagen. Damit muss ja nicht unbedingt eine Unabhaengigkeit zwischen Linux und WIndows gemeint sein; nein, auch eine Unabhaengigkeit zwischen einzelnen Windows-Versionen waere schon was. So weiss man wenigstens, dass wenn man eine App fuer .NET 1.1 kompiliert, sie auch dort laufen wird. Wenn ich eine Win32-App kompiliere, dann ist dies nicht gegeben.

/signed
Allerdings muss ich aus Erfahrung sagen, die Unabhängigkeit tatsächlich schon in sehr grossen Teilen auch Unabhängig vom Betriebssystem ist. Bisher konnte ich jede - und damit meine ich wirklich jede - .NET 1.1-Applikation die ich geschrieben habe (mehr mit Delphi.NET als mit C#) so wie sie aus dem jeweiligen Compiler herauskam auf ein Linux-, MacOS und auch Solaris-system kopieren - und sie lief. Die Mono bzw. dotGNU runtime vorausgesetzt.

Gut, die zwei WindowsForms Applikationen zählen eigentlich nicht wirklich, weil ich da nur eine Handvoll Standard-Komponenten verwendet habe, aber - und gerade das kommt ja auch immer mehr auf Firmen zu - die ASP.NET Anwendungen und Webservices liefen auch, und zumindest einer von denen war arg hochgezüchtet

Natürlich hat Win32 noch seine Existenzberechtigung - das will ich auch keinem Absprechen. Aber man sollte sich ernsthaft die Frage stellen, was von einem zukünftigen, neuem Produkt erwartet wird. Dies ist schon jetzt und wird auch weiterhin so sein:

• Zukunftssicherheit
• leichte Wartbarkeit
• leichte Erweiterbarkeit
• Sicherheit

Punkt 1 bietet zur Zeit ausschliesslich .NET. So wie der Win16/Win32 - Wechsel werden Win32-Anwendungen irgendwann nur noch emuliert und dann später gar nicht mehr laufen. .NET ist ja gerade entwickelt worden, um eine Schicht zwischen Anwendungen und OS zu haben, die diese Hürde überbrückt.

2 und 3 sind eine Frage der Architektur. Viele Programme sind leicht Wartbar und leicht Erweiterbar, viele sind es nicht. .NET liefert mit seiner Struktur aber das Handwerkszeug gleich mit, um auch neue Projekte ohne grösseren Aufwand leichter Wartbar und Erweiterbar zu machen.

Sicherheit: Auch hier sage ich nur CAS. Wenn eine Applikation nunmal nicht auf das Filesystem darf, dann kann ein bösartiger Angriff, selbst wenn er einen unter .NET so gut wie ausgeschlossenen Buffer-Overflow-Angriff fährt, eben keinen Code ausführen, der auf das Filesystem zugreift. Was das Framework auch so an Sicherheitsmechanismen mitbringt ist nicht zu verachten: Ver- und entschlüsselung, Hashing, Authentication (besonders im ASP-Bereich), Sessionhandling (auch hier ASP). Das sind alles Dinge die man schon von Haus dabei hat, die man in Win32-Applikationen entweder teuer zukaufen oder aber selber schreiben muss, und gerade letzteres ist sehr fehleranfällig und damit Sicherheitskritisch.

Alles in allem sehe ich persönlich .NET als einen richtigen Schritt in die Zukunft. Neue Projekte beginne ich nur noch unter .NET. Ob sich die Portierung alter Projekte lohnt sei mal dahingestellt und ist vom Einzelfall abhängig.

[Jasocul]

Also mit fast 42 Jahren (Hey ich bin bald die Antwort auf die Frage ), gehöre ich wohl schon zu den Älteren. Ich habe schon ein paar Wechsel mitgemacht und mache auch den .NET-Wechsel mit. Ich müsste nicht, da ich damit nicht mehr mein Geld verdiene, aber ich halte .NET für eine konsequente Weiterentwicklung der OO-Konzepte.
Borland hat OOP übrigens maßgeblich voran getrieben (TP5, wenn ich nicht irre). Die damalige Oberfläche (Turbo-Vision) hat dem Programmierer irre viel Steuerungsarbeit erspart. Und es war OO!
Mit Einführung von Programmiersprachen für Windows wurde das konsequent fortgeführt. Bestimmt nicht, weil es schlecht war.
Wenn man dann mal sieht, wer an der Entwicklung von .NET beteiligt war (Name ist mir entfallen, aber es war ein wichtiger Entwickler von Borland), muss man sich nicht wundern, dass .NET OO ist.
OOP hat sich über viele Jahre bewährt. Es ist daher fast zwangsläufig, dass irgendwann sowas wie .NET kommen würde.

Anfangs konnte ich mich auch nicht richtig damit anfreunden. Der Grund war Delphi. Nicht weil die IDE schlecht war/ist, sondern weil es imho nicht konsequent genug umgesetzt wurde. Dazu kommt die Trägheit von Borland (-> .NET 2.0) und die wirklich schlechte Hilfe-Funktion.

Alles was ich jetzt neu anfange, mache ich mit C#. Als IDE benutze ich SharpDevelop und bin sehr zufrieden. D2006 ist mir einfach zu teuer und unterstützt ja immer noch nicht .NET 2.0. Einige Dinge, die ich mal eben schnell machen muss, mache ich noch unter Win32 mit Delphi, weil ich da mit meiner Erfahrung einfach schneller bin. Aber das wird nicht so bleiben.