Was ist eure Meinung zu MS .Net

[Bernhard Geyer]

Zitat von Furtbichler:

XP ist aber auch nicht mehr kompatibel zur (PC-)Welt.

Es gibt genügend Mrd.-$-Unternehmen die erst vor kurzen neue angeschaffte PC's nicht mehr mit Windows 2000 installieren.
XP ist noch "voll im Saft". Fast kein Hersteller kann es sich leisten XP nicht mehr zu unterstützen

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

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

[Popov]

Zitat von Furtbichler:

XP ist aber auch nicht mehr kompatibel zur (PC-)Welt.

a.) es war nur ein Hinweis

b.) es sind noch mehr XP Rechner im Einsatz als es MS lieb ist

c.) man wird nicht reicht in dem man Wünsche der Kunden erfüllt, sondern die Kunden zwingt das zu kaufen was man hat

d.) Windows 7 ist zugegebenermaßen nicht schlecht. Allerdings bietet es X Vorzüge im Vergleich zu meinem XP und Y Nachteile. Zur Zeit ist Y < X für mich.

Schon gewusst, dass die nächste Windowsversion (die eine Art modifiziertes Windows 8 werden soll) die letzte Windowsversion sein wird? Danach wird es keine neuen Windowsversionen mehr geben. Danach soll es nur noch Servicesacks geben für die man allerdings bezahlen soll. Wie es letztendlich aussehen wird, man kauft sich das Servicesack und wenn man es nicht mehr macht, dann hat man ein veraltetes Windows, oder man bezahlt eine Art Jahresgebühr, das weiß ich auch nicht so recht.

[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

[Elvis]

Um das Offtopic gleich am Anfang loszuwerden:
EF stinkt viel zu sehr um es als Für oder Wider von irgendwas benutzen zu können.
EF ist nett wenn man ein ORM-noob ist, netter als gar nix oder Datasets.
Da EF aber kaum Extension points hat, wird man irgendwann an eine Wand rennen, um die man nicht elegant rum kann.
Passiert mit nHibernate nicht, da kann man so ziemlich jedes Stück selbst aufbohren oder umbiegen.
Wer also EF in ein kommerz. Projekt einschleppt sollte entweder gut argumentieren können warum das nicht passieren kann, oder warum er vorsätzlich Firmenkapital vernichtet...

Zum Thema:
Ich halte mich schon die ganze Zeit zurück hier etwas zu schreiben, aber naja...
Ich kann mit .Net Code schreiben, der so schön ist, dass einem da fast Tränen in die Augen kommen.
Damit meine ich nicht, dass ich es schaffe das Problem zu lösen, das kann ich in C# oftmals auf 100 Arten in der gegebenen Zeit. Aber wenn man eine so präzise und saubere Sprache wie C# mit Attributen, Tasks, Expression Trees und richtigen Generics (nicht den Krempel, den Java und Delphi so nennen) kombiniert, kommen Libraries dabei raus, die es sonst einfach nicht gäbe.

Als ich das erste Mal Moq benutzte, musste ich an all die Delphianer denken und wieviel Zeit, Geld und Nerven, die wohl beim Versuch verschwenden, ihren Code wenigstens halbwegs sinnvoll zu testen.

Ich habe auch oft LinqPad parallel zum VS auf. Denn damit kann ich ganz informell Scripte gegen meine Libraries rumprobieren während ich sie schreibe. (Linqpad sperrt die Assemblies nicht, lädt sie aber autom. wenn sie sich geändert haben, inkl. Code completion!)

Da nur zu MSIL kompiliert wird, sind Dinge wie Postsharp, oder auch Function exports möglich.

Mit Garbage Collection gibt es keine, für das eigentliche Programm, komplett sinnlose Ownership-Beziehungen.
Wenn man seit Jahren gewohnt ist, sich solchen Einschränkungen zu unterziehen, kann man wahrscheinlich nicht einmal erkennen, wie man sich dabei stets eine Hand an den Rücken fesselt. (schon mal gehört? "Blabla ...Funktionen sollen keine Objekte zurückgeben... blabla")

Ich könnte den ganzen Tag rumschwärmen , aber für Außenstehende macht schon das wenige, was ich hier schrieb keinen Sinn. Also lass ich das mal einfach...