Was ist eure Meinung zu MS .Net

[ATS3788]

Hallo
Was ist eure Meinung zu MS .Net ?

Würde mich mal interessieren.

[holliesoft]

Hallo,

ich habe bis vor 3 Jahren Delphi eingesetzt und bin dann zu .Net und C# gestoßen. Schon nach wenigen Wochen habe ich festgestellt, dass ich mit C# mindestens genauso schnell zum Ziel komme wie mit Delphi - nur mit weniger Code und vor allem mit eleganterem Code. Das .Net Framework bringt einige nette Sachen mit, die das Programmieren im Vergleich zu Delphi wesentlich angenehmer machen.
Das meiner Meinung nach beste Feature von .Net ist Linq. Statt eine Liste von Objekten mit foreach durchzugehen formuliere ich einfach mit Linq eine Abfrage. Das macht den Code übersichtlicher.

Gruß,
Patrick

[Medium]

Ich meine, dass wir dieses Thema, bei dem unsere üblichen Flame-Kandidaten nur wieder Gelegenheit sehen ihre Hasstriaden rauszuschmettern, und Fanbois mit aller Macht dagegenbrüllen, nicht ein weiteres Mal gebrauchen können. (Zudem ist die Frage irgendwie sehr allgemein gefasst, es wäre sinniger sich über Aspekte des Frameworks zu unterhalten. Dabei könnten dann auch fachlich interessante Diskussionen entstehen.)

[Popov]

Ich hab zwei Meinungen. Die Erste: nicht schlecht. Die Zweite: ich weiß nicht warum, aber es ist mir noch kein einziges Mal gelungen ein .NET Programm zu installieren, ohne dass ich gebeten wurde zuerst .NET zu installieren oder zu aktualisieren. Könnte aber auch an XP liegen.

[Furtbichler]

Zitat:

Zitat von Medium (Beitrag 1194596)

Ich meine, dass wir dieses Thema, bei dem unsere üblichen Flame-Kandidaten nur wieder Gelegenheit sehen ihre Hasstriaden rauszuschmettern...

Wie wäre es zur Abwechslung mit einer III.Reich-Metapher? Hatten wir lange nicht.

[MrSpock]

Bis jetzt läuft der Thread ja friedlich ab. Bitte sorgt dafür, dass es so bleibt. Dazu wäre es nötig, dass nur die User hier einen Beitrag schreiben, die über ihre positiven oder negativen Erfahrungen berichten. Alle anderen bitte ich um Zurückhaltung. :wink:

[WM_CLOSE]

Ich finde in .NET lernt man weniger wie etwas funktioniert. Man bekommt alles vorgekaut im Framework und man braucht nichts mehr selbst zu erfinden.

Andererseits ist das der größte Vorteil von .NET.
Es ist einfach produktiver, einfacher, strukturierter.

Als 1. Lernsprache würde ich trotzdem Object Pascal wählen.
Dazu war die Sprache ja auch ursprünglich gedacht.
Im professionellen Einsatz ist es jedoch mittlerweile unwirtschaftlich.

[cookie22]

.Net hat halt den Vorteil, daß schon alles im Framework ist, für das man bei Delphi Thirdparty-Kram braucht.

Zitat:

Im professionellen Einsatz ist es jedoch mittlerweile unwirtschaftlich.

Das kann man so wohl kaum verallgemeinern.

[mkinzler]

Das Framework hat ja nicht unbedingt mit der verwendeten Programmiersprache zu tun, Delphi.Prism aka Oxygene for Net ist ja ein ObjectPascal-Compiler für die .Net Platform.

[Medium]

Gut, wenn das klappt, dann will ich mich auch gern beteiligen :)

Beruflich lebe ich rein in Pascal. Ich habe meine Bachelorarbeit (die wohl letztlich deutlich über das übliche Maß hinaus ging, aber es hat so Spaß gemacht! :lol:) aber mit C#, also .NET realisiert. Dabei bin ich weniger mit den üblichen Annehmlichkeiten in Kontakt gekommen, da mein Projekt haputsächlich Numbercrunching war. Was mir aber stark auffiel ist, dass obgleich ich Pascal für die schönere Sprache halte, mir dort der Code irgendwie flüssiger von der Hand ging. Und das, obwohl ich in dieser Arbeit zum aller ersten Mal C# benutzt habe, und zeitgleich noch Direct3D inkl. HLSL lernen musste. (Und nie zuvor mehr als Übungsaufgaben in anderen C-likes gemacht habe.) Das hat mir imponiert, und hierüber ist mein Eindruck von .NET recht positiv gefärbt. Auch wenn es nicht in erster Linie .NET zu verdanken gewesen sein mag, sondern eher dem verfügbaren Toolset und Doku, aber beides zähle ich schon auch wieder irgendwie dazu. (Und ich hab sogar "nur" #Develop benutzt, nichtmals das VS.)

Das, sowie die Dinge, die man in diversen Blogs und Artikeln so liest, haben in mir den Drang wachsen lassen, meine beruflichen Projekte mittelfristig auch in diese Richtung zu treiben, was mangels Zeit bisher leider nicht möglich war. Die aktuelle Entwicklung lässt mich daran allerdings auch wieder ein wenig zweifeln, da es sich auch für uns ggf. lohnen könnte, auf den Mobile-Devices Zug aufzuspringen. Ob und was es dort aktuell an sinnvollen und managebaren Wegen gibt, die zu unserer Anwendung passen, versuche ich beiläufig zu ermitteln. Wenn es .NET mitsamt dem Toolset auch für iOS und Android gäbe, wäre ich schon fertig mit der Suche :)

Fazit: Nach meinem kurzen (mehrmonatigen...) Ausflug in die .NET Welt, bin ich sehr angetan, und halte es auch gerade dank der guten Tools für eine produktive und eingängige Art zu arbeiten. Und da wir Spezialsoftware erstellen, zu der wir auch fast immer die Rechner konfektionieren und liefern, ist die Notwendigkeit eines Frameworks für uns kein Thema: Der Kunde bekommt da eh nichts von mit.

[sh17]

Zitat:

Zitat von Medium (Beitrag 1194631)

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

MonoTouch/MonoDroid bzw das von RemObjects? Oder wie meinst Du das?

[Medium]

Ich glaub ich habe soeben Lesestoff gewittert! :D

[Popov]

Zitat:

Zitat von Medium (Beitrag 1194631)

Was mir aber stark auffiel ist, dass obgleich ich Pascal für die schönere Sprache halte, mir dort der Code irgendwie flüssiger von der Hand ging. Und das, obwohl ich in dieser Arbeit zum aller ersten Mal C# benutzt habe...

Was vielleicht zu erwähnen wäre - soweit ich mich erinnern kann hat Microsoft bei Delphi kräftig Entwickler abgeworben und einer davon soll der Projektleiter bei .NET gewesen sein. .NET hat also ein Hauch von Delphi abbekommen.

[mkinzler]

Ja, der "Erfinder" von Turbo Pascal, Delphi und der VCL Anders Hejlsberg ist auch der "Erfinder" von .Net

[Phoenix]

Zitat:

Zitat von Medium (Beitrag 1194631)

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 :shock:
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? :gruebel:

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

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.

[mkinzler]

Zitat:

Zitat von Phoenix (Beitrag 1194656)

Zitat:

Zitat von Medium (Beitrag 1194631)

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.

http://de.playstation.com/playstation-mobile/ basiert auf Mono. SONY wird hier sicherlich eine Vereinbarung mit Xamarian getroffen haben

[p80286]

Zitat:

Zitat von Medium (Beitrag 1194668)

Das ist ja auch mal sexy :shock:
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? :gruebel:

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

Gruß
K-H

[daywalker9]

Zitat:

Zitat von Medium (Beitrag 1194668)

Das ist ja auch mal sexy :shock:
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? :gruebel:

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

[Phoenix]

Zitat:

Zitat von implementation (Beitrag 1194673)

Problematisch sind leider auch Microsofts Patente auf Teile der Standardbibliothek:

Zitat:

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ß

[ATS3788]

Aha Danke
Doch bin ich von den Antworten überrascht.

Ich selber habe noch nie mit einer Net API programmiert,
(Bin aber auch nur ein einfacher Hobby Prog Man)
nur wenn ich mal ein Tool brauche installiere ich kein
Tool was Net benötigt. Ich habe keine Lust zig verschiedene
Net Varianten auf dem Rechner zu haben.

[cookie22]

Es heißt .NET (Dotnet) nicht Net. :-D

[Medium]

Ich halte mir einfach immer das aktuellste .NET (Windows Update hooray), und mache mir keinen Kopf darum, welche Programme es nachher auf meiner Kiste nutzen. Gleiches Spiel mit Java, wobei mir hier der Updater gerne mal ein Augenäderchen platzen lässt mit seiner Aufdringlichkeit :lol:

[Phoenix]

Zitat:

Zitat von progopa (Beitrag 1194738)

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.

[Popov]

Zitat:

Zitat von Medium (Beitrag 1194763)

Ich halte mir einfach immer das aktuellste .NET ...

Man sollte an der Stelle vielleicht erwähnen, dass .NET 4.5 nicht mehr kompatibel zu Windows XP ist.

[Furtbichler]

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

[Bernhard Geyer]

Zitat:

Zitat von Furtbichler (Beitrag 1194850)

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:

Zitat von Furtbichler (Beitrag 1194844)

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:

Zitat von implementation (Beitrag 1194853)

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:

Zitat von Furtbichler (Beitrag 1194844)

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:

Zitat von Furtbichler (Beitrag 1194850)

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:

Zitat von Phoenix (Beitrag 1194854)

Zitat:

Zitat von implementation (Beitrag 1194853)

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:

Zitat von implementation (Beitrag 1194860)

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:

Zitat von Phoenix (Beitrag 1194870)

Zitat:

Zitat von implementation (Beitrag 1194860)

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 :love:, aber für Außenstehende macht schon das wenige, was ich hier schrieb keinen Sinn. Also lass ich das mal einfach... :mrgreen: