SeppSchrot (und alle anderen) was findet ihr an .net so schlecht?

Ich kann nicht verstehen, was einige an .net so schlecht findet. Ich finde, es ist ein klasse Framework, was einem viel Arbeit erspart.

mad_martin

Wenn es dir gefällt, dann ist das gut. Bin mir sicher, dass viele Leute es ähnlich sehen.
Allerdings versuche ich .NET zu vermeiden, weil es für meine Probleme meistens bessere Lösungen gibt. .NET ist einfach zu monolithisch und aufgeblasen. Man kauft sich ja auch keinen Elektronikmarkt, wenn man einen Kondensator braucht.

gruß
Martin

mad_martin schrieb:

Man kauft sich ja auch keinen Elektronikmarkt, wenn man einen Kondensator braucht.

Was kann man den mit einem Kondensator bauen?

mad_martin

Einen defekten auf einer Platine austauschen...

Undertaker

ich finde .NET und C# im prinzip nicht schlecht. einziger nachteil ist, dass es zu windows-spezifisch ist.

find .net und c# eigentich auch ganz ok. muss ich mir irgendwann mal reinziehen bin aber eher der java typ

darthdespotism

Undertaker schrieb:

nachteil ist, dass es zu windows-spezifisch ist.

Das einziger würde ich ma weglassen da ich mich damit noch nicht näher beschäftigt hab.

Der Durchschnitt

Undertaker schrieb:

einziger nachteil ist, dass es zu windows-spezifisch ist.

Das kann man sehen, wie man will, denn das bringt ja auch Vorteile mit sich. Wenn man ohnehin schon viel Microsoft-lastige Technologie im Haus stehen hat (Navision, SharePoint, IIS, etc.) dann ist .NET sicher die erste Wahl für ein Softwareprojekt.

mad_martin schrieb:

Einen defekten auf einer Platine austauschen...

Macht im zusammenhang mit software noch mehr sinn. ein defektes if austauschen.

mad_martin

Schön, dass du schon soviel zum Thema geschrieben hast, dass du dich an Vergleichen hochziehen kannst.

Ist das eigentlich toll, wenn man als Unregistrierter hier so den Harten markieren kann?

mad_martin schrieb:

Schön, dass du schon soviel zum Thema geschrieben hast, dass du dich an Vergleichen hochziehen kannst.

Ist das eigentlich toll, wenn man als Unregistrierter hier so den Harten markieren kann?

Wirklich toll finde ich es ja, wenn man unschlüssige Argumentationen aufdecken kann, egal ob man dabei registriert ist oder nicht, und genau das hat KennerDämlicherVergleiche gemacht. Es ist ja eine Sache eine Diskussion auf einer nicht vorhandenen Argumentationsbasis zu führen, aber eine ganz andere, wenn man dann rumplärrt und beleidigt wirkt sobald die ersten Kritiken eintreffen.

mad_martin

Ersetze Elektronikmarkt durch .NET-Framework und Kondensator durch System.Windows.Forms.

Wenn ich nur diesen Teil der Klassenbibliothek benötige, ist der Rest reiner Ballast, um den ich aber nicht herumkomme, da das Framework als komplettes Paket kommt.

Warum sollte ich die Benutzer meines Programms nötigen, noch ein 30MB schweres Paket runterzuladen, wenn mein Programm davon nur einen Bruchteil wirklich benutzt? Und soweit verbreitet ist .NET NOCH nicht, dass man sagen könnte, es wäre Inhalt des Betriebssystems. Auch wenn Microsoft daran arbeitet, ist die Verbreitung m.E.n. noch nicht wirklich groß. Wenn ich im Gegensatz dazu ein Programm verteile, dass kein .NET benutzt und z.B. die GUI per WinAPI darstellt und noch einige Boostklassen benutzt, hab ich nur das an Board, was das Programm auch wirklich benötigt.

Außerdem ist die Bindung an Microsoft immer noch zu groß, auch wenn es mittlerweile standartisiert ist. Z.Z. fehlen einfach noch die (wirklich funktionierenden) Alternativen. Aber vielleicht ändert sich das noch. Und die Platformunabhängigkeit ist bisher mehr theoretischer Natur.

gruß
Martin, definitiv nicht "rumplärrend", sondern auch etwas sagend

mad_martin schrieb:

Ersetze Elektronikmarkt durch .NET-Framework und Kondensator durch System.Windows.Forms.

Das aber System.Windows.Forms vielleicht eher ein ganzer "Schaltkreis" ist, der auf weitere Elemente des .NET-Frameworks aufbaut, ist dir nicht in den Sinn gekommen? Durch derartige Indirektionen wird aus einem "Bruchteil" ganz schnell mal ein ausschlaggebender Anteil. Das nennt sich Transitivität und würde sich auch nicht durch einen modulareren Aufbau vermeiden lassen. Stattdessen dürfte man sich dann nur mit unaufgelösten Abhängigkeiten ärgern.

mad_martin schrieb:

Warum sollte ich die Benutzer meines Programms nötigen, noch ein 30MB schweres Paket runterzuladen, wenn mein Programm davon nur einen Bruchteil wirklich benutzt?

Es gibt da mittlerweile so "optische Datenträger", die mehr Speicherkapazität als 1.44MB aufweisen. Solltest du mal ausprobieren, wenn du Software ausliefern willst. Apropos, nein, auch ein 56k-Modem ist nicht mehr der aktuelle Stand der Dinge. Aber um die Provokationen mal sein zu lassen, es gibt auch ein nettes Setup-Tool von Microsoft, bei dem das .NET-Framework nur bei Bedarf installiert wird. Ihr tut ja immer so, als würde durch das Framework jedes Programm mindestens 30 MB größer. Langfristig gesehen werden die Programme dadurch sogar kleiner, weil nicht jeder sein Boost, Qt, etc. selbst mitliefert, wobei man das ohnehin relativieren muss. Das sind völlig unrealistische Dimensionen, von denen wir da sprechen. Ich kann mir nicht vorstellen, dass man einen Taschenrechner für den PC oder ähnliches in der Größenordnung so gewinnbringend verkaufen kann ..

mad_martin schrieb:

Wenn ich im Gegensatz dazu ein Programm verteile, dass kein .NET benutzt und z.B. die GUI per WinAPI darstellt und noch einige Boostklassen benutzt, hab ich nur das an Board, was das Programm auch wirklich benötigt.

Außerdem ist die Bindung an Microsoft immer noch zu groß, auch wenn es mittlerweile standartisiert ist. Z.Z. fehlen einfach noch die (wirklich funktionierenden) Alternativen. Aber vielleicht ändert sich das noch. Und die Platformunabhängigkeit ist bisher mehr theoretischer Natur.

Mal abgesehen davon, dass man sich vielleicht an Microsoft binden will, hast du natürlich absolut Recht. Das .NET-Framework ist mir auch in jederlei Hinsicht zu proprietär, da greif ich doch lieber deinen Vorschlag auf und verwende die hersteller- und plattformunabhängige WinAPI! Da hab ich ja zusätzlich auch noch den Vorteil, dass ich im Falle des Falles auf eine Konkurrenzimplementierung anderer Hersteller umsteigen kann. Ich glaub Novell hat eine Implementierung der WinAPI-Spezifikation bereitgestellt, oder?

mad_martin

Verdammt, jetzt hast du es doch tatsächlich geschafft, mich mit unter Provokationen gut versteckten Argumenten zu überzeugen, dass meine Meinung kaum durchdacht war.

Danke sehr

gruß
Martin

mad_martin schrieb:

Verdammt, jetzt hast du es doch tatsächlich geschafft, mich mit unter Provokationen gut versteckten Argumenten zu überzeugen, dass meine Meinung kaum durchdacht war.

Danke sehr

gruß
Martin

Hör nicht auf den Idioten. Der ist nur ein verklemmter MS-Fanboy ohne Realitätsbezug. Sollen doch die .NET verwenden, die es mögen. Aber dann sollen die uns (die es nicht mögen) auch in Ruhe lassen. mad_martin hat vollkommen recht!

Wozu ein riesiges Framework mitleifern wenn et mal 5% davon genutzt werden.
ich meine: Du nimmst Frauen und Kind auch net mit, wenn du in den Puff gehst...

Apollon

Jo. Man schleppt ja auch kein Sand mit an Strand.

Man nimmt auch kein Essen mit ins Restaurant.

... schüttet zum Zelten mitgenommenes Wasser in den vorbeifließenden Bach.

DEvent

Ich finde .net einfach sinnlos. Eine plattformunabhaengige Bibliothek gibt es schon, nennt sich Java SE. Wozu dann eine zweite?

Dann bleibt noch die Windows-programmierung. Aber wozu hier eine weitere Bibliothek, wo es doch die WinAPI gibt?

Dann die Sprache C#: Gefaellt mir auch nicht. Ist zu aufgeblasen.

Wozu deligates und events? In Java loest man das bequem mit EventListenerList oder einfacher mit List<DeinListener>.

Wozu getter und setter bei Attributen?
Es reicht doch einfach getXXX() und setXXX() Methoden zu schreiben.

Wozu struct? Es gibt doch so wieso einen GC, damit gewinnt man doch perfomance maessig nichts.

Dann, wieso Methoden explizit virtual machen? Man hat doch eh einen GC...

this-*gt*that

Ich finde .NET is seit Jahren das Beste, was einem Windowsprogrammierer passieren konnte. Das Argument "ich will meinem Benutzer keine 30 MB zumuten" is angesichts der Tatsache, dass es bei allen neuen WindowsVersionen eh schon dabei ist und heutigen Festplattengrößen ziemlich lächerlich.

Ich finde .net einfach sinnlos. Eine plattformunabhaengige Bibliothek gibt es schon, nennt sich Java SE. Wozu dann eine zweite?

Weil sich damit eleganter für Windows entwickeln lässt. Schon mal AWT/Swing mit WinForms verglichen?

Dann bleibt noch die Windows-programmierung. Aber wozu hier eine weitere Bibliothek, wo es doch die WinAPI gibt?

LOL. Du scheinst offenbar noch nie wirklich die WinForms benutzt zu haben.

Dann die Sprache C#: Gefaellt mir auch nicht. Ist zu aufgeblasen.

Wenn C# aufgeblasen ist, was ist dann C++? IMO ist C# die schönste Sprache, die ich seit langem gesehen habe. Ein wirklich gelungene Mischuns aus C++ und Java, in der das entwickeln richtig Spaß machen kann.

Wozu deligates und events?

Was die Vorteile von typsicheren und elegant benutzbaren Funktionspointern sind, muss ich ja wohl nicht erklären.

Wozu getter und setter bei Attributen?
Es reicht doch einfach getXXX() und setXXX() Methoden zu schreiben.

Weil es eine elegante Methode ist, ein immer wieder auftretende Arbeit zu erledigen. Desweiteren wird die Benutzung leichter, ohne auf Kapselung zu verzichten.

Wozu struct? Es gibt doch so wieso einen GC, damit gewinnt man doch perfomance maessig nichts.

Erstens mal aus Kompatibilitätsgründe zu Unamanged Code und zweitens kann es manchmal einfach erwünscht sein, einen Value Type zu benutzen.

Dann, wieso Methoden explizit virtual machen? Man hat doch eh einen GC...

Was haben denn bitte virtual functions mit GC zu tun?

Sry, aber die meisten der Contra .NET Argumente sind eher lächerlich und sind wohl eher ideologisch motiviert als auf rationellen Gründen basierend

@this->that:

Du hast de Plan.

Wann lernt ihr endlich, dass es selbstmord ist, sich an ein Unternehmen zu binden?