gruß
Martin

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

Was kann man den mit einem Kondensator bauen?

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.

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.

Einen defekten auf einer Platine austauschen...

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

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

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.

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

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?

Danke sehr

gruß
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

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

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

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

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

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.

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.

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)