Was ist eure Meinung zu MS .Net

[Phoenix]

Zitat von Medium:

Wenn es .NET mitsamt dem Toolset auch für iOS und Android gäbe, wäre ich schon fertig mit der Suche

Wurde schon erwähnt, ist aber nicht ganz billig, gibts von Xamarin. Es sind auch nicht gerade wenig Apps, von denen offiziell bekannt ist, dass sie damit erstellt wurden (http://xamarin.com/apps/all). Die Dunkelziffer ist um einiges höher.

[Medium]

Das ist ja auch mal sexy
Wie ist das bei deren Lizenzen zu verstehen - mit der 399$ Version darf ich Apps in den Store packen, aber nur mit der 999$ Version verkaufen?

[p80286]

Zitat von Medium:

Das ist ja auch mal sexy
Wie ist das bei deren Lizenzen zu verstehen - mit der 399$ Version darf ich Apps in den Store packen, aber nur mit der 999$ Version verkaufen?

Ja, weil die kleine Version ist für den Bastler im Keller, der den 3.785sten Taschenrechner programmiert hat.

Gruß
K-H

[daywalker9]

Zitat von Medium:

Das ist ja auch mal sexy
Wie ist das bei deren Lizenzen zu verstehen - mit der 399$ Version darf ich Apps in den Store packen, aber nur mit der 999$ Version verkaufen?

Nein, bei Enterprise kannst Du auch noch ohne App Store die Apps verteilen - sprich in house.

[implementation]

Meine Erfahrungen sehen wie folgt aus:

Ich habe frueher (in meiner Windows-Zeit, die noch nicht allzu lange her ist) etwa ein halbes Jahr lang C# benutzt (auf .Net 4.0). Es ist wirklich sehr schoen fluessig zu schreiben und ich habe meinen (persoenlichen, nicht beruflichen) Kram darin immer sehr schnell fertig bekommen. Insofern einige Daumen hoch! RAD ist wirklich drin. Ich war ziemlich gluecklich damit, und dachte, dass ich zu Pascal wahrscheinlich nie wieder zurueckkehren wuerde.
Bis mir dann irgendwann die Garbage Collection gegen den Strich ging. Und ich Klassenreferenzen vermisst habe. Da bin ich zum FPC zurueck - aber das waren mehr subjektive Gruende.

Nach einiger Zeit kam dann mein OS-Wechsel auf GNU/Linux - und natuerlich wollte ich meine Projekte portieren. Da fiel mir ein, dass Portabilitaet ja immer gern als Argument fuer .Net gepredigt wird, und dachte, dass der .Net-Kram wahrscheinlich am problemlosesten ginge. Weit gefehlt. Zunaechst mal war Mono zu dem Zeitpunkt noch nicht 4.0-kompatibel. Ich haette meinen gesamten Code neu schreiben muessen. Und dann kommt dazu, dass (verstaendlicherweise) nicht alle Teile der .Net-Standardbibliothek in Mono vorhanden sind.
Anders lief es mit den FreePascal-Projekten - die liessen sich groesstenteils mit einem einfachen Neukompilieren ohne jeglichen Aufwand weiterverwenden.

Problematisch sind leider auch Microsofts Patente auf Teile der Standardbibliothek:

Zitat von Wikipedia:

Die grundlegenden Technologien sind teilweise durch Microsoft bei Ecma International und der ISO standardisiert worden. Microsoft garantiert eine Lizenzierung der ECMA-Teile auf RAND-Basis. Andere Teile, wie zum Beispiel Windows Forms, ADO.NET und ASP.NET sind hiervon jedoch ausgeschlossen.

Die Community Promise ist, wie der Name schon sagt, nur ein Versprechen, ohne jeglichen Zwang fuer MS, sich daran zu halten.

Ich lasse einfach nur noch die Finger davon.


Aus Anwendersicht gingen mir Runtime-Environments damals gehoerig gegen den Strich, als ich mich noch auf Windows durch die Setups geklickt habe -- heute ist mir das relativ wurscht, da der Paketmanager sich sowieso allein drum kuemmert. Sonst muesste ich auch jede einzelne Skriptsprache verdammen, Perl, Python, Ruby, Tcl, Guile, Smalltalk, und was es nicht noch alles gibt. Ein paar Interpreter gehoeren IMHO sowieso zur Standardausstattung, daher macht mir einer mehr oder weniger nichts mehr aus. Aber wie gesagt, frueher hat es mich immer sehr gestoert, und ich kann jeden verstehen, den die Runtime-Landschaft ankotzt.


That's my two cents. Zusammenfassung: RAD ist drin, Portabilitaet nicht. Und eine potentielle Patentbombe, von der man nicht weiss, ob, wann und wie sie platzt, geschweigedenn, wie gueltig die Patente hierzulande sind.

[Phoenix]

Zitat von implementation:

Problematisch sind leider auch Microsofts Patente auf Teile der Standardbibliothek:

Zitat von Wikipedia:

Die grundlegenden Technologien sind teilweise durch Microsoft bei Ecma International und der ISO standardisiert worden. Microsoft garantiert eine Lizenzierung der ECMA-Teile auf RAND-Basis. Andere Teile, wie zum Beispiel Windows Forms, ADO.NET und ASP.NET sind hiervon jedoch ausgeschlossen.

Die Community Promise ist, wie der Name schon sagt, nur ein Versprechen, ohne jeglichen Zwang fuer MS, sich daran zu halten.

Das ist inzwischen schon lange überholt. Microsoft hat das komplette Entity Framework für den Datenbankzugriff und ASP.NET 4 unter der Apache 2.0 Lizenz open sourced. Damit hat sich die Patentproblematik hier vollkommen erledigt.

Das einzige was hier potentiell noch wäre, sind Windows Forms, aber da das eh nicht so wirklch X-Platformfähig ist und man X-Platform GUIs sowieso besser pro Plattform mit nativen Bindings (wie z.B. MonoMac für OS X oder Gtk# für Linux) baut damit das für den User auch tauglich ist, sollte das nicht wirklich ein Issue sein.

[Furtbichler]

Na ja, und WinForms ist ja nun nicht wirklich das Nonplusultra. Erinnert mich an die gute alte(!) VCL.

[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?

Mit Gruß

[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.