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

[Bernhard Geyer]

Zitat von MGC:

[Heißt also, dass ich ruhigen Gewissens auf Delphi Prism umsteigen könnte ohne Performanceverluste zu erleiden. Das klingt doch schonmal recht angenehm, ins besondere da einem dann sowohl VCL als auch FCL zur Verfügung stehen würde.

Nein. Unter Delphi.Prism steht dir nur FCL zur Verfügung. Die VCL.NET war nur in Delphi for .NET verfügbar und ist mit Delphi 2007 entgültig gestorben.

[MGC]

Zitat von Hisoka:

Also ein Java ist es nicht. Man kann nicht eben mal eine Anwendung mit GUI schreiben und sie läuft auf allen Systemen ohne Probleme. Die meisten .NET Anwendungen die ich bisher gesehen hab sind Plattform gebunden. Also sie laufen entweder auf Win oder unter Linux oder auf dem Mac. Einige wenige laufen mit erheblichen Aufwand und Win und OSX oder unter Lin und OSX. Anwendungen die gut unter allen Plattformen laufen sind selten.
Windows.Forms wird nicht auf jeder Plattform mitgeliefert, daher müssen die passenden Pakete extra ausgeliefert werden.

Also im Prinzip das gleich wie immer.
Eine Eierlegende-Wollmilchsau wird es leider wohl nie geben.

Aber da ich hauptsächlich für Windows-Plattfromen entwickle dürfte dies für mich eine eher untergeordnete Rolle spielen (ansonsten gibt es ja noch JAVA, mal ganz abgesehen davon, das sich Delphi ohnehin auch nicht für jedes eignet - egal ob W32 ode .NET).

Aber da meine Wurzeln bei Pascal liegen komme ich auch nicht einfach so von Delphi los.

[MGC]

Zitat von Bernhard Geyer:

Zitat von MGC:

[Heißt also, dass ich ruhigen Gewissens auf Delphi Prism umsteigen könnte ohne Performanceverluste zu erleiden. Das klingt doch schonmal recht angenehm, ins besondere da einem dann sowohl VCL als auch FCL zur Verfügung stehen würde.

Nein. Unter Delphi.Prism steht dir nur FCL zur Verfügung. Die VCL.NET war nur in Delphi for .NET verfügbar und ist mit Delphi 2007 entgültig gestorben.

Hm, das ist schade, diese Entwicklung ist mir leider ein wenig abhanden gekommen. Somit hätte sich eine Portierung von Altprojekten nach Prism für mich dann ohnehin erledigt.
Aber wenigstens erklärt das für mich jetzt den deutlichen Preisunterschied zwischen Prism und Delphi W32, da ja allem Anschein nach die Forms-Entwicklung zu MS ausgelagert wurde.

[Memnarch]

Wenn ich das was ich verstanden habe kurz zusammenfassen darf: .NEt bringt keine "AHA" vorteile. Je nach komplexität ist mein Programm wie immer an eine Plattform gebunden, "Portierungen" müssen selbst erledigt werden. Einige stellen sind schneller, einige stellen sind langsamer als beim NAtiveCode. Fragt sich welche? CPU lastige berechnungen für z.B Physic&Co (ati nutzer bleiben halt softwaregefangen)?

Hab ich was vergessen?


MFG
Memnarch

[stahli]

Ich denke, man muss die Entscheidung stärker auf seine Ansprüche beziehen.

Für Internetanwendungen halte ich ASPX (Delphi Prism) für interessant (habe mal ein kleines Projekt erstellt). Man braucht einen Server, der ASPX unterstützt, dann ist die Anwendung über den Browser ja "Plattformunabhängig".

Anders sehe ich das mit Desktopanwendungen (wenn diese nur unter Windows laufen müssen). Da scheint mir natives Delphi doch noch effektiver (zumindest konnte ich mich mit Prism da noch nicht recht anfreunden). Vorteile sehe ich in dem Bereich bei der Desktopentwicklung nicht.
Dabei ist mir die Ausführungsgeschwindigkeit eigentlich weniger wichtig (ein paar zehntel Sekunden sind schon mal übrig).
Wichtiger ist mir die Art der Entwicklungsarbeit.
.NET erschließt sich mir noch nicht ganz. Irgendwie wirkt das auf mich etwas "eigenartig" und eher geeignet für Datenbankanwendungen. (Ist nur so ein Eindruck.)

Für Desktopanwendungen greife ich lieber auf das bewährte Delphi zurück und sehe im .NET keine Vorteile.

Die verschiedenen .NET-Versionen wirken auch nicht sehr überzeugend auf mich. Also ich bin skeptisch...

[mkinzler]

Zitat:

Läuft Silverlight schon auf iOS, Android, Bada und WebOS? Oder nur für die "Randgruppe" Windows Phone7?

Vom Monoprojekt existieren offizielle Versionen für iOS und Android, für webOS gibt es eine "inoffizielle" Implementierung und in einem Blog erwähnt Miguel de Icaza webOS.

[MGC]

Zitat von stahli:

Ich denke, man muss die Entscheidung stärker auf seine Ansprüche beziehen.

(...)

Wichtiger ist mir die Art der Entwicklungsarbeit.
.NET erschließt sich mir noch nicht ganz. Irgendwie wirkt das auf mich etwas "eigenartig" und eher geeignet für Datenbankanwendungen. (Ist nur so ein Eindruck.)

Für Desktopanwendungen greife ich lieber auf das bewährte Delphi zurück und sehe im .NET keine Vorteile.

Die verschiedenen .NET-Versionen wirken auch nicht sehr überzeugend auf mich. Also ich bin skeptisch...

@Stahli:

Vielen Dank für Deine Beurteilung der Situation. Somit schlägt der Zeiger für mich gerade wieder eher gegen Delphi Prism aus, da ich allerhöchstens ein wenig Netzwerk-Kommunikation zu bewältigen habe udn das sehr gut auch mit herkömmlichen Mitteln und DCOM erledigen kann.

[Robotiker]

Das .net-Framework ist heute wesentlich mehr als Forms und Datenbankzugriff.

Was mich im Moment sehr beschäftigt, sind die Möglichkeiten zur parallelen Programmierung. Dazu gibt es auf dieser Seite einige Infos:
http://parallelpatterns.codeplex.com/

In den nächsten Versionen kommt unter anderem einiges zur asynchronen und verteilten Programmierung:
http://msdn.microsoft.com/en-us/vstudio/gg316360
http://msdn.microsoft.com/en-us/devlabs/gg585582
http://msdn.microsoft.com/en-us/devlabs/gg585581
http://msdn.microsoft.com/en-us/devlabs/gg585584

Auch gibt es einige Zusatzpakete aus dem Bereich Scientific Computing, die zeigen, was mit .net alles geht:
http://www.solverfoundation.com/
http://research.microsoft.com/en-us/projects/bio/

[generic]

Ein generelles Problem im dotnet sehe ich noch, dass die Firmengeheimnisse (Programmlogik) nur schlecht versteckt sind.

Die IL kann man prima lesen. Gerade wenn es um Lizenz/Kopierschutz geht, muss man hier auf externe Tools setzen.

x86 Assembler lässt sich halt schlechter lesen als IL.
(ist aber auch für geübte kein Problem)


Parallele Entwicklung mit Delphi auch kein Problem -> OmniThread-Lib (Ich werde da demnächst einen Artikel schreiben)

[mkinzler]

Hierfür gibt es Obfuscatoren