Was ist eure Meinung zu MS .Net

[Phoenix]

Zitat von progopa:

Was ich noch nicht ganz einordnen kann, ist Prism bzw. Oxygene.
Hat wer Erfahrungen damit oder ist man bei Net so dicht an C#, das man dieses besser gleich nutzt?
Was mich interessiert ist die Möglichkeit für net und Java VM zu kompilieren.
Gibt es eigentlich ein brauchbares Tool um eine VCL Form (.dfm) in Winforms zu konvertieren?

Oxygene ist Sprachlich viel weiter als C#.

Was bei C# erst mit .NET 4 dazu kam, sind z.B. Class Contracts. Die sind schon seit der ersten Version von Oxygene (hiess damals noch Chrome) drin gewesen und dort zudem deutlich eleganter umgesetzt. In .NET wurden hier ungeschickte Krücken gebaut.

Alles was Aspektorientierte Programmierung (AOP) betrifft, muss in C# mit extra Tools gemacht werden, die nach der eigentlichen Kompilierung nochmal über die eigentlich schon fertigen Assemblies laufen müssen (z.B. PostSharp). Bei Java genauso. Oxygene hat mit Cirrus AOP direkt im Compiler eingebaut und kann das in einem Schritt machen. Zudem bietet Cirrus nicht nur reine AOP, sondern zudem auch eine Plugin-Schnittstelle in den Compiler. Damit lässt sich zur Compilezeit code ausführen und auch Code generieren, der am Schluss im Programm landet.

Es gibt noch mehr Besonderheiten: Dadurch, dass mit Java und Cocoa zusätzliche Plattformen als Ziele für Oxygene nativ unterstützt werden, fliessen von dort natürlich einzelne Features in die Sprache, die plötzlich überall zur Verfügung stehen. Ein kleines Beispiel: Da Java keine Events und Delegaten kann, wie man sie als Delphianer oder .NETler versteht, sondern alles über Interfaces realisiert, kennt Java das Konzept von Inline Interfaces. Diese stehen damit auch in .NET und Cocoa zur Verfügung.

Alles in allem ist Oxygene also deutlich fortgeschrittener, aber natürlich derzeit eine sehr kleine Nische. Man bekommt auf dem freien Markt defakto keine Oxygene-Entwickler, das heisst die Teamaufstpckung gestaltet sich schwierig. Wobei man dazu sagen muss, dass man einen .NET'ler / Java / Cocoa-Entwickler nur auf eine andere Synatx (Object-Pascal) hieven und ein paar Specialties zu den Sprachfeatures erläutern muss. Das Wissen um die jeweilige Plattform und die verwendeten Bibliotheken (z.B. Hibernate bei Java, Entity Framework bei .NET, Core Data bei Cocoa) lassen sich ja durch die jeweils native Plattformunterstützung 1:1 weiter anwenden.

[Furtbichler]

Also ich finde nicht, das etwas, was sich alle Features von überall zusammenklaubt, unbedingt fortschrittlicher ist. Außer, man versteht unter 'Fortschritt', das etwas 'fort' (also von einem weg) schreitet. Nicht umsonst gilt: 'Weniger ist oft mehr'.

Es kann in meinen Augen nicht gutgehen, auf zuvielen Hochzeiten zu fahren. Das lädt doch geradezu dazu ein, die Stile und Möglichkeiten ohne klare Linie zu mischen.

Desweiteren würde ich im Leben nicht auf ein Nischenprodukt setzen, für das ich keine/kaum Unterstützung auf dem freien Markt finde. Natürlich kann man umlernen, aber -ehrlich gesagt- da verzichte ich doch lieber auf das 1034.te tolle neue Feature und bleibe beim total veralteten C#, zumal ich hier wenigstens weltweiten Support bekomme, jederzeit.

Wie sieht es bei Prism eigentlich aus mit:
* Unterstützung durch Refactoring-Tools,
* EF-Code-Generierung
* Zusammenspiel mit 3rd Party Komponenten und deren Demos, Templates, Codegeneratoren

Ich hab so meine Probleme mit Non-Standard-Lösungen, auch wenn sie scheinbar modernertollerbesser sind. Leider isses so: Halte dich an den Standard oder gehe in Schönheit ein.

Aber gut, darum gehts ja hier nur am Rande.

[implementation]

Zitat von Furtbichler:

Desweiteren würde ich im Leben nicht auf ein Nischenprodukt setzen,

Teufelskreis? Wenn keiner drauf setzt, bleibt es ein Nischenprodukt. Wenn sich Leute ueberwinden, es einzusetzen, bald nicht mehr.
Wenn man immer so denken wuerde, waere heute keine Sprache/Bibliothek/Produkt verbreitet.

Ich wuerde auch nicht drauf setzen, aber das liegt eher daran, dass es dafuer keinen freien Compiler gibt, und ich mich nicht von einem Hersteller abhaengig machen moechte. Das geht schliesslich regelmaessig schief.

[Phoenix]

Zitat von implementation:

Ich wuerde auch nicht drauf setzen, aber das liegt eher daran, dass es dafuer keinen freien Compiler gibt, und ich mich nicht von einem Hersteller abhaengig machen moechte.

Der Compiler ist (und war schon immer) frei (wie in Freibier, also Kostenlos).
Siehe hier http://www.remobjects.com/downloads.aspx in dem Oxygene-Bereich ganz unten rechts.

Lediglich die IDE-Integration ist das eigentliche Produkt, und kostenpflichtig.

Was die Abhängigkeit von einem Hersteller angeht: .NET im Allgemeinen: Microsoft. Java: Oracle. Cocoa / Objective C: Apple. Irgendwo hängt man immer mit drin, ausser man gibt sich mit reinen Community-Lösungen zufrieden - aber hier fehlt dann in aller Regel wieder der kommerzielle Support bzw. sind auch keine 3rd Party Tools/Komponenten verfügbar.

[implementation]

Zitat von Phoenix:

Zitat von implementation:

Ich wuerde auch nicht drauf setzen, aber das liegt eher daran, dass es dafuer keinen freien Compiler gibt, und ich mich nicht von einem Hersteller abhaengig machen moechte.

Der Compiler ist (und war schon immer) frei (wie in Freibier, also Kostenlos).

Wie in Freibier bringt aber nichts. Es geht nicht um die Zahlbereitschaft. Sondern um die Herstellerabhaengigkeit, die daher ausgeht, dass man sich im Notfall nicht einfach einen Fork erstellen kann.

Ein Projekt, das ich mit einem freien (as in freedom) Compiler kompilieren kann, ist fuer die Ewigkeit sicher. Wenn der Compiler irgendwann eingestellt wird, entsteht ein Fork, und jemand anders entwickelt ihn weiter, oder vertreibt zumindest noch die alte Version.
Wenn ich aber auf einen proprietaeren Compiler setze, fuer den es keine freie Alternative gibt, und dieser irgendwann eingestellt wird - dann steh ich doof da.

[cookie22]

Im Windows-Umfeld funktioniert aber "freie" Software ala Linux nicht und das ist auch gut so.

So einfach kannst du auch einen Compiler nicht Forken, denn dafür brauchst du schon ne Menge Knowhow.

[Phoenix]

Zitat von implementation:

Wenn ich aber auf einen proprietaeren Compiler setze, fuer den es keine freie Alternative gibt, und dieser irgendwann eingestellt wird - dann steh ich doof da.

Da Marc Hoffman zugesichert hat den Oxygene-Compiler zu open sourcen, sollte das Produkt oder gar die Firma jemals eingestellt werden, besteht die Gefahr hier nicht.

[sh17]

Zitat von Phoenix:

Zitat von implementation:

Wenn ich aber auf einen proprietaeren Compiler setze, fuer den es keine freie Alternative gibt, und dieser irgendwann eingestellt wird - dann steh ich doof da.

Da Marc Hoffman zugesichert hat den Oxygene-Compiler zu open sourcen, sollte das Produkt oder gar die Firma jemals eingestellt werden, besteht die Gefahr hier nicht.

Da war einer schneller

Man kann auch von allen anderen werkzeugen abhängig sein,
Ich denke nicht,dass man mit einem produkt in delphi so schnell nach fpc wechseln kann,sollte emba mal weg sein

[Assarbad]

Zitat von Phoenix:

Zitat von implementation:

Wenn ich aber auf einen proprietaeren Compiler setze, fuer den es keine freie Alternative gibt, und dieser irgendwann eingestellt wird - dann steh ich doof da.

Da Marc Hoffman zugesichert hat den Oxygene-Compiler zu open sourcen, sollte das Produkt oder gar die Firma jemals eingestellt werden, besteht die Gefahr hier nicht.

Wenn zwei Partnerfirmen ein Escrow-Abkommen haben, ist das deutlich sicherer. Ich denke wenn eine Firma pleite geht, ist es nicht unbedingt die Priorität Code zu FLOSS zu machen, Versprechen hin oder her.

In Sachen .NET habe ich eine gespaltene Meinung. Es ging ja um Meinungen ...

1. für Anwendungen im Geschäftsumfeld fast perfekt. Große Entwicklergemeinde, viele Tools, gute Sprachunterstützung (ganz zu schweigen von mehreren Sprachen), schnelles Prototyping.
2. für mich liegt ein Manko in der Tatsache, daß selbst mit P/Invoke diverse Dinge in .NET noch immer komplizierter sind als sie eigentlich sein müßten. Ein anderes Manko ist der Ressourcenhunger (CPU+Speicher), der natürlich seit Vista clever versteckt wird und dem "System" zugerechnet wird.

[Phoenix]

Zitat von Furtbichler:

Wie sieht es bei Prism eigentlich aus mit:
* Unterstützung durch Refactoring-Tools,
* EF-Code-Generierung
* Zusammenspiel mit 3rd Party Komponenten und deren Demos, Templates, Codegeneratoren

1.) Das ist tatsächlich ein Manko. Die Hersteller erhalten einfach (noch) nicht genug Anfragen dafür. Wenn die Verbreitung größer wäre, würden die nachziehen.
2.) Die Designer-Unterstützung ist auf C# und VB hart codiert. Da ist sogar Microsoft's eigenes F# aussen vor. Aber da es seit EF 4.1 Code-First Unterstützung gibt und das EF auch open sourced wird ist das kein wirkliches Problem. Inzwischen passiert das Mapping vollautomatisch bzw. maximal über annotations. Den EF-Designer nutzt keiner mehr Ernsthaft.
3.) Ich kenne keine einzige 3rd Party Komponente, die nicht mit Oxygene funktioniert. Die Demos und Vorlagen der meisten Anbieter sind inzwischen in aller Regel ausschliesslich auf C# beschränkt und supporten auch kein VB.NET mehr (geschweige denn F#).