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

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?

kennerdertatsachen schrieb:

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

oder... schrieb:

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

Das sind genau die Kommentare, warum ich Foren liebe, in denen sich auch unregistrierte Personen beteiligen können (Das war jetzt wirklich nicht ironisch gemeint). Die bieten einem noch etwas zum Lachen während all der Arbeit.

DEvent schrieb:

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

Du bist wohl ein eher langsamer Typ, nicht? Microsoft versucht es ja nicht wirklich .NET als plattformunabhängiges Framework zu "verkaufen", es klingt natürlich besser, wenn es unter Umständen theoretisch plattformunabhängig sein könnte (;)), aber jeder, der .NET verwendet, weiß, dass er damit an Microsoft Windows gebunden ist. Du sagst es ja selbst: Es gibt Java, warum sollte als .NET auch plattformunabhängig sein müssen?

DEvent schrieb:

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

Irgendwie machst du es mir fast schon zu einfach an dieser Stelle .NET zu verteidigen (wohlgemerkt, ich bin nicht einmal ein .NET Programmierer). Lass dir an dieser Stelle ein besseres Argument einfallen ..

DEvent schrieb:

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

Das sich Interfaces für Callbacks als das non-plus-ultra erwiesen haben, sieht man ja zuletzt daran, dass der Ruf nach Closures für Java immer lauter wird. Falls du Closures nicht kennst: Das ist im Prinzip so etwas wie ein anonymes Delegate aus .NET 2.0.

DEvent schrieb:

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

Wir ersetzen den Google-Suchbegriff von vorher (also ""Java 7" Closures") durch einen neuen ""Java 7" Properties" und erfahren, dass auch hier diskutiert wird, ob man nicht auch Properties als Sprachmittel einführen soll. Auch andere auf der JVM-basierende Sprachen verfolgen mittlerweile das Konzept der Properties (z.B. Groovy), aber du bist ja anscheinend gegen generell jede Veränderung (ich sag nur WinAPI).

DEvent schrieb:

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

Ganz ehrlich, ob man nun primitive Datentypen als Außnahme behandelt oder es dem Entwickler erlaubt auch Wertetypen zu erstellen, ist ja nun wirklich egal. Der Unterschied ist so simpel, dass er absolut nicht zur Komplexität der Sprache beiträgt und gerade C++-Programmierer stehen es sich doch immer auf Typen mit Wertesemantik ..

Nächstes mal bitte vorher informieren.

this-*gt*that

Wenn man in der realen Welt lebt, kommt man nun mal mit einer rein ideologischen Denkweise nicht weit :>

this->that schrieb:

Wenn man in der realen Welt lebt, kommt man nun mal mit einer rein ideologischen Denkweise nicht weit :>

Das ist die typische Argumentationsweise eines weltfredmen MS-Fanboys.

Was hat den portabilität mit ideologie zu tun? Portabilität ermöglicht es ein weitaus breiteres Publikum zu erreichen. (In bezug auf java)

ps: nein ich bin kein java fan.

looool schrieb:

this->that schrieb:

Wenn man in der realen Welt lebt, kommt man nun mal mit einer rein ideologischen Denkweise nicht weit :>

Das ist die typische Argumentationsweise eines weltfredmen MS-Fanboys.

Was hat den portabilität mit ideologie zu tun? Portabilität ermöglicht es ein weitaus breiteres Publikum zu erreichen. (In bezug auf java)

ps: nein ich bin kein java fan.

EDIT: Und das kann sich nur positiv auf die Umsatzzahlen auswirken (wenn man garnet, bzw kaum am code etwas ändern muss, jedeoch auch Linux/BSD/MacOS/SDolaris nutzer anspricht)

Und was ich am lustigsten finde: Diese ganzen weltfremde MS-Fanboys und "alles_anderen_betriebssysteme"-hasser bezeichnen Win95, 98, ME, 2000, XP und Vista ernsthaft als verschiedene (LOL!) Plattformen, nur um deren kack auch als portabel bezeichnen zu können.

Undertaker

looooooooooool schrieb:

Und was ich am lustigsten finde: Diese ganzen weltfremde MS-Fanboys und "alles_anderen_betriebssysteme"-hasser bezeichnen Win95, 98, ME, 2000, XP und Vista ernsthaft als verschiedene (LOL!) Plattformen...

ehrlich gesagt, es sind 2 1/2 plattformen.
p1: 95, 98, me
p2: nt, 2000, xp
p2.5: vista

Ist ein Programm portabel, welches auf RechnerA (OS. WinXP) läuft und auch auf rechnerB (OS: WinXP) läuft? Sind ja ZWEi verschiedene rechner

Genau diese oben genannte Denkweise ist naiv und dumm.