Diskussion über das CCC von ATi wegen .NET

[Leonidas]

Deine Argumente sind genau so dumm wie man es von dir üblich gewohnt ist. Microsoft.NET erleichtert Millionen von Entwicklern die Software-Entwicklung, ob dir das nun passt oder nicht interessiert überhaupt niemanden.



Komische Argumentation. Du willst mir verbieten, NET schlecht zu finden, mit dem Argument, daß meine Meinung nicht interessiert. Wie wäre es, wenn ich es anderes herum sehe und allen Kritiker an meiner Meinung diese Argumentation so vor die Füße werfe?!

[Leonidas]

Es ist nicht deine Aufgabe zu entscheiden wer gefördert werden soll oder nicht. Du hast neutral über Entwicklungen zu berichten und darin bist du leider nicht sehr gut.



Ich war nie ein Anhänger des vollkommen neutralen Journalismus. Vollkommen neutraler Journalismus hat dazu geführt, daß ein George W. Bush dreiste Lügen in die Kamera sprechen kann, ohne daß ihm der Saft abgedreht wird oder ein "Journalist" auf die Idee käme, da etwas korrigierendes dazuzusagen. Und aus den Lügen sind dann letztlich reale Kriege mit realen Toten geworden ... nur weil Journalismus heutzutage zu einer Hofberichterstattung verkommen ist, die möglichst nicht mehr anecken will.

[McTristan]

Bitte? Was hat denn das mit dem ATI Control Center und deiner Meinung zum Thema .NET zu tun? Gute Berichtserstattung ist nun mal objektiv und nicht subjektiv. Dennoch muß man Lüge von Wahrheit unterscheiden können - das macht einen guten Journalisten aus.

[grakaman]

Ich war nie ein Anhänger des vollkommen neutralen Journalismus. Vollkommen neutraler Journalismus hat dazu geführt, daß ein George W. Bush dreiste Lügen in die Kamera sprechen kann, ohne daß ihm der Saft abgedreht wird oder ein "Journalist" auf die Idee käme, da etwas korrigierendes dazuzusagen. Und aus den Lügen sind dann letztlich reale Kriege mit realen Toten geworden ... nur weil Journalismus heutzutage zu einer Hofberichterstattung verkommen ist, die möglichst nicht mehr anecken will.


Jetzt scheinst du ja vollkommen abzudrehen, Microsoft.NET mit GW Bush zu vergleichen. Du hast null Ahnung von Softwareentwicklung, vor allem was Microsoft.NET kann, inwieweit es alte Microsoft Technologien ablöst und inwiefern es sich von anderen Plattformen wie z.B. Java unterscheidet. Aber unreflektiert emotional argumentieren, ist freilich bequemer als auf Basis von Fakten. Aber schon alleine die Tatsache, dass du ja sowieso nicht weißt, wovon du redest, disqualifiziert dich eh schon meilenweit.

[grakaman]

Komische Argumentation. Du willst mir verbieten, NET schlecht zu finden, mit dem Argument, daß meine Meinung nicht interessiert. Wie wäre es, wenn ich es anderes herum sehe und allen Kritiker an meiner Meinung diese Argumentation so vor die Füße werfe?!

Fakt ist, dass Millionen Menschen schon mit Microsoft.NET programmieren und somit Millionen Menschen mehr technisches Verständnis haben, als du es je haben wirst. Es interessiert schlicht nicht, was der USA Hasser und Pseudogerechtigkeitskämpfer Leonidas wieder für geistigen Unsinn unter dem Deckmantel Journalismus betreibt.

[Aqualon]

Erstens finde ich die Aussagen von Leonidas in den News nicht wirklich schlimm. Was daran geistiger Unsinn sein soll, kann ich beim besten Willen nicht erkennen.

Mit der Aussage, dass einige Leute Vorbehalte gegenüber .NET haben, hat er sicherlich Recht, aber das ist auch die Schuld von Microsoft. Anstatt die wirklichen Vorteile von .NET als zukünftige Standard-Entwicklungsumgebung für Windowssoftware zu vermitteln, sind sie eher mit datenschutzrechtlich besorgniserregenden Anwendungsmöglichkeiten wie Passport und Hailstorm aufgefallen.

Da ist meiner Meinung nach das Marketing von Microsoft selbst die Ursache, dass alles mit .NET im Namen von vielen erst einmal kritisch beäugt wird.

Desweiteren hat diese Seite ihren Schwerpunkt nicht darin, die Vor- und Nachteile von Programmierumgebungen zu analysieren. Es heisst ja schließlich 3DCenter und nicht IDEcenter.

Aqua

[Phoenix03]

Ich persönlich hab keine Meinung zu .NET ist wir weder negative noch positive aufgefallen.

Ne guter Freund von der Besitzer einer 9700proUltimate ist hat das .NET mit Center installiert und war aussersich vor wut, als ich vorbei kamm der war so sauer ich konnt ihn gerade noch bremsen seine Grakar gegen die Wand zuschmeißen:ubash3:, und der ist normal ne ruhiger Typ.

Also wenn das .NET bei den usern veruhrsacht kann ich drauf verzichten hoffentlich kommt nVidia nicht auf den Bolzen sowas zu machen.
Ich kann also durch aus Leo verstehn nach dem ich mein Freund so abging.

[grakaman]

Ich persönlich hab keine Meinung zu .NET ist wir weder negative noch positive aufgefallen.

Ne guter Freund von der Besitzer einer 9700proUltimate ist hat das .NET mit Center installiert und war aussersich vor wut, als ich vorbei kamm der war so sauer ich konnt ihn gerade noch bremsen seine Grakar gegen die Wand zuschmeißen:ubash3:, und der ist normal ne ruhiger Typ.

Also wenn das .NET bei den usern veruhrsacht kann ich drauf verzichten hoffentlich kommt nVidia nicht auf den Bolzen sowas zu machen.
Ich kann also durch aus Leo verstehn nach dem ich mein Freund so abging.

Und ATI darf jetzt nicht mit .NET entwickeln, weil dein Freund psychischen Problemen unterliegt?

[q@w]

ATi darf entwickeln mit was und für was sie wollen - ist ja schließlich deren eigenen GuV-Rechnung.

Was mich etwas Wunder nimmt, sind allerdings drei Tatsachen:

1)
Man wollte lt. ATi das Control-Panel nicht unnötig verkomplizieren - so die Begründung GEGEN einen Schalter, der die Optimierungen der Texturfilterung komplett abschaltbar macht.
Nun soll es aber einen extra-Schalter für einen Ersatz-Shader in Doom3 geben??? WTF?

2)
Man verweigerte strikt jedwedem Shaderreplacement die Absolution - solange es die Konkurrenz tat. Als man im 3DMark03 dann selbst erwischt wurde, wich man zwar von diesem Statement nicht ab, änderte aber den nachfolgenden Treiber ein wenig.
Nun kommt das böse böse Shaderreplacement doch wieder extra für Doom3?

3)
Man sieht sich ausserstande, so ATi, bsw. Supersampling im Treiber anzubieten - der Aufwand hierfür wäre angesichts der Nachfrage zu hoch.
Nun gibt es ein 'schickes' neues CCC - wer hat davon erhöhten Nutzen?

Sorry, aber irgendwie sehe ich der kompletten Firmenpolitik immer mehr Widersprüche.

[Exxtreme]

Quasar,

es hat alles nur mit Marketing zu tun. ;( Ein schickes neues CP kann man viel besser an die große Glocke hängen als das lahme und veraltete SSAA. ;)

[Phoenix03]

Und ATI darf jetzt nicht mit .NET entwickeln, weil dein Freund psychischen Problemen unterliegt?

find ich ja lustig, was du rein interpretierst hab ich das gesagt? nein ! hab nur geschildert was ich mittbekommen habe.
Und schön das du ihn hier als Psycho hin stellst, das sollte der mal hören :ulol2: :ulol3: :ulol4: :ulol5:

[grakaman]

find ich ja lustig, was du rein interpretierst hab ich das gesagt? nein ! hab nur geschildert was ich mittbekommen habe.
Und schön das du ihn hier als Psycho hin stellst, das sollte der mal hören :ulol2: :ulol3: :ulol4: :ulol5:

Welche adäquate Antwort glaubst du denn sonst auf diese recht subjektiv/polemische Äußerung zu bekommen?

[Exxtreme]

Welche adäquate Antwort glaubst du denn sonst auf diese recht subjektiv/polemische Äußerung zu bekommen?
Errmm, wie man in den Wald hineinruft, so schallt es heraus. Sorry, aber zumindest ich sehe deinen Diskussionsstil als sehr aggressiv an. Du bezichtigst andere Leute der Unwissenheit etc.

[Gaestle ohne Keks]

Jetzt scheinst du ja vollkommen abzudrehen, Microsoft.NET mit GW Bush zu vergleichen. Du hast null Ahnung von Softwareentwicklung, vor allem was Microsoft.NET kann, inwieweit es alte Microsoft Technologien ablöst und inwiefern es sich von anderen Plattformen wie z.B. Java unterscheidet. Aber unreflektiert emotional argumentieren, ist freilich bequemer als auf Basis von Fakten. Aber schon alleine die Tatsache, dass du ja sowieso nicht weißt, wovon du redest, disqualifiziert dich eh schon meilenweit.

Ich kann Leonidas nur zustimmen. Mal abgesehen davon, dass die Installation von zusätzlichen Routinen nicht gerade dazu beiträgt, dass der User nachvollziehen kann, was in/auf seinem Rechner abgeht, sind außerdem die langfristigen Folgen der Microsoft-Politik für den User nicht ausnahmslos positiv. So sind z.B. viele Virenprobleme, in der Form wie sie heute auftauchen, ohne die Microsoft-Politik der Vergangenheit nicht denkbar. Dadurch, dass ein Betriebssystem nahezu auf allen Rechnern läuft, ist es viel einfache große Schäden zu produzieren, weil man nur für ein System schreibt. Außerdem hat es MS immernoch nicht hinbekommen, seine Programme sicher vor unerwünschten Zugriffen aus dem Netzwerk zu machen.
Aber in dem man Tools verwendet die von MS angeboten werden stärkt man die Position von MS, da MS aber sowieso schon das Monopol hat und teilweise große Sicherheitsprobleme wissentlich zulässt, ist es letztlich für den User ungünstig, dass die Monopolstellung von MS weiter ausgebaut wird, weil damit auch die Chance sinkt, dass sich z.B. neue Ideen und Sicherheitskonzepte durchsetzen können. Denn alles, was nicht von MS unterstützt wird, landet (oft ungerechtfertigt) in der Ecke für die Freaks und sei es auch noch so toll.

Außerdem ist IMHO der Journalist in der PFLICHT, kritisch zu hinterfragen, sonst braucht man nämlich keine Pressefreiheit mehr (wenn du das willst, dann geh' zu zdnet oder zu tomshardware, computerbild wäre diesbezüglich auch zu empfehelen). Alles hat mindestens zwei Seiten, und wenn man ein Produkt einführt und ein entsprechendes Pressebriefing durchführt, wird immer nur eine Seite aufgezeigt. Außerdem ist der Vergleich zu Bush vielleicht inhaltlich überzogen, aber strukturell m.E. absolut zutreffend.

Und last but not least möchte ich Dir noch schreiben, dass ich Deinen offensichtlichen Mangel an grundlegendem Respekt vor dem Diskussionspartner und damit einhergehend die eklatanten Mängel bezüglich Deiner Wortwahl zum KOTZEN finde.

Grüße

___
Rock and Roll aint noise pollution...

[grakaman]

Errmm, wie man in den Wald hineinruft, so schallt es heraus. Sorry, aber zumindest ich sehe deinen Diskussionsstil als sehr aggressiv an. Du bezichtigst andere Leute der Unwissenheit etc.

Natürlich ist mein Diskussionstil aggressiv, mir hängt langsam dieses übliche Geschwall zum Halse heraus. Wer ein wenig im Politikforum mitliest, erkennt, dass immer die selben Leute den selben linken Verschwörungsmüll erzählen. Achso, und ja, ich bezichtige Leonidas der Unwissenheit. Oder willst du etwas das Gegenteil behaupten?

[McTristan]

Mal abgesehen davon und von den ganzen aggressiven Äußerungen, muß ich doch feststellen, dass man einfach keine vernünftigen Diskussionen über Microsoft-Produkte führen kann. Immer wieder wird die Monopolstellung (die in meinen Augen nicht mehr wirklich existiert) von Microsoft hervorgehoben, dass man bloß nicht auf die Idee kommen sollte dieses Monopol auch noch zu unterstützen. Da wird auf Sicherheitslücken in Microsoftprodukten verallgemeinert, davon geredet das der vom .NET-Framework installierte User ja ach so suspekt und gefährlich ist ...

Nee ich kann's nicht mehr hören. Erinnert mich ein wenig an das gebashe im heise.de-Forum. Ok, man kann einem Ottonormalbenutzer nicht vorwerfen das er keine Ahnung von der dahinterliegenden Technologie hat. Und ja, es ist natürlich dumm wenn man erst noch einen ganzen Packen an Systemdateien installieren muß um ein simples Kontrollpanel für eine Grafikkarte zu benutzen. Aber ooh je, es gibt doch wohl noch andere Programme die das .NET-Framework benutzen.

Die Leute, welche das .NET-Framework programmieren wissen nur allzu gut wieviel Arbeit es einem abnehmen kann, wenn man damit schneller und womöglich sicherer ans Ziel kommt, kann man ATI nur zu dieser Entscheidung beglückwünschen. Das Geld was man da bei der Entwicklung eingespart hat, kann man sicher an anderer Stelle sinnvoller einsetzen. Ob's dem Kunden schmeckt oder nicht - eine Firma muß in allererster Linie wirtschaftlich agieren.

Just my 0.02€

[grakaman]

Ich kann Leonidas nur zustimmen. Mal abgesehen davon, dass die Installation von zusätzlichen Routinen nicht gerade dazu beiträgt, dass der User nachvollziehen kann, was in/auf seinem Rechner abgeht, sind außerdem die langfristigen Folgen der Microsoft-Politik für den User nicht ausnahmslos positiv.



Das ist natürlich eine vollkommen unbedachte Behauptung. Gerade die .NET Policies ermöglichen es erst dem Benutzer .NET Software viel granulater zu steuern, was denn wie auf dem Rechner "abgeht".


Außerdem hat es MS immernoch nicht hinbekommen, seine Programme sicher vor unerwünschten Zugriffen aus dem Netzwerk zu machen.


Du wirst mir sicherlich gleich erzählen, wie das geht?


Aber in dem man Tools verwendet die von MS angeboten werden stärkt man die Position von MS, da MS aber sowieso schon das Monopol hat und teilweise große Sicherheitsprobleme wissentlich zulässt, ist es letztlich für den User ungünstig, dass die Monopolstellung von MS weiter ausgebaut wird, weil damit auch die Chance sinkt, dass sich z.B. neue Ideen und Sicherheitskonzepte durchsetzen können.


Erst einmal liegt es im Ermessen des Entwicklers, für welche Plattform er entwickelt. Hier bietet .NET viele neue Funktionalitäten, die es woanders nicht gibt. Und die Entscheidung treffen gesunde Menschen auf Grund von Fakten und keinen bornierten Ideologien.


Denn alles, was nicht von MS unterstützt wird, landet (oft ungerechtfertigt) in der Ecke für die Freaks und sei es auch noch so toll.


Du solltest schon genaue Bsp. liefern, wo das denn zutrifft.


Außerdem ist IMHO der Journalist in der PFLICHT, kritisch zu hinterfragen, sonst braucht man nämlich keine Pressefreiheit mehr (wenn du das willst, dann geh' zu zdnet oder zu tomshardware, computerbild wäre diesbezüglich auch zu empfehelen). Alles hat mindestens zwei Seiten, und wenn man ein Produkt einführt und ein entsprechendes Pressebriefing durchführt, wird immer nur eine Seite aufgezeigt. Außerdem ist der Vergleich zu Bush vielleicht inhaltlich überzogen, aber strukturell m.E. absolut zutreffend.


Dieses kritische Hinterfragen muss trotzdem auf Fakten basieren und keinen bloßen Behauptungen. Hier ist die Lage aber glas klar, dass sich der Autor keinefalls mit dem Thema auseinandergesetzt hat.

[Gast]

...die Chance sinkt, dass sich z.B. neue Ideen und Sicherheitskonzepte durchsetzen können...

Das .NET Framework HAT neue Ideen und ein Sicherheitskonzept und all die Probleme die du aufgezählt hast werden damit angegangen.

Denn alles, was nicht von MS unterstützt wird, landet (oft ungerechtfertigt) in der Ecke für die Freaks und sei es auch noch so toll.

Und wieder falsch. Denn gerade in diesem Fall ist es umgekehrt: Alles was MS hervorbringt wird von den Freaks prinzipiell abgelehnt. :))

Leonidas hinterfrägt nicht kritisch, er hat so gut wie kein Wissen über das ganze (wie wir in dieser Diskussion gesehen haben) und transportiert einfach nur seine anti-M$ Haltung ohne genau diese Haltung im Bezug auf .NET mal kritisch zu hinterfragen.

[Gaestle ohne Keks]

Das ist natürlich eine vollkommen unbedachte Behauptung. Gerade die .NET Policies ermöglichen es erst dem Benutzer .NET Software viel granulater zu steuern, was denn wie auf dem Rechner "abgeht".

Naja, da kommst jetzt drauf an, wenn du mit "Benutzer" meinst. Wenn du den Entwickler meinst, dann ist das sicherlich richtig, wenn du aber den Anwender bzw. Konsumenten meinst, wäre ich mir der Sache nicht so sicher. Denn als Anwender (mit begrenztem Einblick - davon sollte man IMHO ausgehen) stellt sich z.b. die Frage, warum zwei Sachen installiert werden müssen, wenn ich nur ein Programm benutzen will (nämlich das CCC).


Du wirst mir sicherlich gleich erzählen, wie das geht?

Nunja, man könnte beispielsweise zumindest dafür sorgen, dass die Rechte für die Ebene "Arbeitsplatz" zum einen nicht versteckt sind, und zum zweiten sich nicht per default auf admin-ähnlichem Niveau liegen. Man könnte auch dafür Sorgen, dass nicht per default alle ports der Netzwerkverbindung offen wie ein Scheunentor sind. Allerdings kann ich an diesem Punkt keinen Code für diese oder andere Probleme liefern, da ich meine Brötchen mit anderen Sachen (u.A. als Anwender von MS-Software) verdiene.
Sicher ist es so, dass jedes Sicherheitssystem geknackt werden kann, aber man sollte doch wenigstens das Bemühen erkennen lassen von sich aus (und nicht ausschließlich als Reaktion auf Druck der Öffentlichkeit) Sicherheitsprobleme zu lösen.


Erst einmal liegt es im Ermessen des Entwicklers, für welche Plattform er entwickelt. Hier bietet .NET viele neue Funktionalitäten, die es woanders nicht gibt. Und die Entscheidung treffen gesunde Menschen auf Grund von Fakten und keinen bornierten Ideologien.

Sicher bietet .NET eine Reihe von Vorteilen, die bestimmte Sachen für den Entwickler einfacher machen. Das möchte ich auch nicht in Abrede stellen.
Wenn MS es schaffen würde, sein Produkt ständig sinnvoll zu verbessern, und nicht nur alles bunter (und eine bißchen anderes) machen würde, würde ich es auch gut finden. Aber ich weiß - das ist wieder bornierte Ideologie - danke für die Blumen übrigens.
Das Problem für mich ist nicht der Name Microsoft, sondern die Monopol-Situation an sich (und deren Verfestigung).
Mir ist es prinzipiell egal, wie die Firma oder das System heißt, welche das Monopol hat. Ich bin nur davon überzeugt (und es gibt ja auch nicht wenige Beispiele dafür), dass eine Monopol-Situation für den Vebraucher immer weniger bringt, als eine Wettbewerbs-Situation. Beispiel gefällig? Die Briefpreise der Deutschen Post sind so hoch (und gemessen am notwendigen Einsatz durch die Post überteuert), dass dadurch sehr niedrige Paketpreise quersubventioniert werden können. Durch diesen -letztlich unfairen- Preiskampf werden die Mitwettbewerber auf dem Paketmarkt geschädigt und die Kunden auf dem Briefmarkt extrem geschröpft. Schaden für die Gesamtwirtschaft: keine Ahnung... bin ja kein VWLer, schätze ihn aber trotzdem ziemlich hoch.



Du solltest schon genaue Bsp. liefern, wo das denn zutrifft.

Naja, ein Beispiel, was mir spontan einfällt ist z.B. OpenOffice (bzw. früher StarOffice), was IMHO ein gutes Programmpaket ist, sich aber aufgrund des MS Monopols bei Office-Anwendungen nicht durchsetzen konnte. Und nochwas zum kaufen wäre z.B. das Office-Paket von Corel, was auch nicht so schlecht war, aber ebenfalls bedingt durch die Monopol-Stellung eines anderen Wettbewerbers nicht zum zuge kam.



Dieses kritische Hinterfragen muss trotzdem auf Fakten basieren und keinen bloßen Behauptungen. Hier ist die Lage aber glas klar, dass sich der Autor keinefalls mit dem Thema auseinandergesetzt hat.
Nur leider hab' ich von Dir bislang auch noch keine Fakten gelesen die aufzeigen, dass Leonidas Äußerungen bloße Behauptungen sind, die auf keine faktischen Grundlage stehen. Aufgrund des Monopol-Problems kann ich die Aussagen Leonidas nachvollziehen. In Deinen Aussagen kann ich keine FAKTEN entdecken (die von Dir immer wieder gefordert werden), die das Gegenteil aufzeigen, vor allem in Relation zu dem Monopol-Problem.

Du bist dran.

Grüße
___
Rock and Roll aint noise pollution...

[Crushinator]

(...) Die Leute, welche das .NET-Framework programmieren wissen nur allzu gut wieviel Arbeit es einem abnehmen kann, wenn man damit schneller und womöglich sicherer ans Ziel kommt, kann man ATI nur zu dieser Entscheidung beglückwünschen. Das Geld was man da bei der Entwicklung eingespart hat, kann man sicher an anderer Stelle sinnvoller einsetzen. Ob's dem Kunden schmeckt oder nicht - eine Firma muß in allererster Linie wirtschaftlich agieren. Es wird allerdings abundzu auch ein Schuh draus. Denn so ähnlich wie Du's ATi zuschreibst dachten wir letztes Jahr auch, als wir unheimlich stolz auf uns in sehr kurzer Zeit mit .NET eine kundenspezifische Prozeßsteuerung realisierten. Als der Kunde daraufhin drohte abzuspringen, weil ihm die Software zu hohe Anforderungen an die vorhandenen PCs stellte, ruderten wir zurück und realisierten ihm das Ganze auf herkömmliche Art, nämlich mit nativen und statisch gelinkten (VCL-)Bibliotheken. Dabei stellten wir fest, daß der Aufwand für Letzteres aufgrund unserer umfangreich angesammelten Klassen sogar niedriger lag wie bei der C# Lösung, während die Anwendung ihre Arbeit praktisch auf jedem am Prozeßablauf teilnehmenden Uralt-PC unabhängig vom jeweiligen Win32-Betriebssystem zur vollsten Zufiredenheit verrichtete. Erst dann wurde uns übrigens bewußt, daß .NET in vielerlei Hinsicht ein Selbstzweck darstellt, weil es doch sehr oft Dinge ermöglicht, die ohne sich selbst gar nicht notwendig wären.

Da ich mir nicht vorstellen kann, daß man im Hause ATi erst seit kurzem angefangen hat Software zu entwickeln, würde mich der Gedanke, daß sie eine solche Anwendung wie das Control Center nur unter Einsatz von .NET Entwicklungsumgebungen sehr schnell entwicklen könnten, dann doch sehr nachdenklich stimmen.

[McTristan]

Lieber @Gaestle_ohne_Keks (or whatever), bezüglich deiner Aussage zum Thema OpenOffice hast du leider nicht ganz recht, Microsoft hat gerade erst zugegeben, dass der Bereich Office an Umsatz einiges verloren hat, gerade wegen kostenloser oder preiswerter Office-Lösungen (hier wurde bspw. OpenOffice von Microsoft angeführt).

Für mich ist OpenOffice übrigens keine wirkliche Alternative da es mir immer mal wieder gerne das Layout verhunzt, beim Excel Im- bzw. Export herumzickt und es weder eine Outlook noch eine Access-Alternative gibt ... auch beim Daten umher schieben (Drag&Drop) und markieren von Spalten (inkl. Verschieben) hat mir das Excel-Derivat aus dem OpenOffice nicht so recht zugesagt. Wenn ich dann überlege, dass ich das ganze mit Support auch für Geld haben kann, reißt mich das immer noch nicht vom Hocker.
Microsoft hat hier einfach einmal die Nase vorn - gerade was Integration ihrer verschiedenen Lösungen betrifft. Ich sag nicht (!) das OpenOffice schlecht ist - für viele nur eben nicht ideal.

Das Office-Produkte nicht nur auf den Windows-PC begrenzt sind, sieht man sehr gut am Office für Apple - die Zusammenarbeit mit den Windowsprogrammen ist einfach perfekt - sowohl bei Exchange als auch bei Excel oder Word.

[McTristan]

@Crushinator:

So unterschiedlich können die Erfahrungen sein. Habe von Serveranwendungen, über Webservices, Webanwendungen und Clientsoftware bis jetzt nur gute Erfahrungen gemacht mit .NET. Großen Ressourcenhunger konnte ich nicht feststellen bzw. meist schnell optimieren. Andererseits hängt es bei vielen Anwendungen auch vom verwendeten Betriebssystem ab - das .NET-Framework + der IIS 6 im Windows 2003-Server sind beispielsweise für Webanwendungen wesentlich besser geeignet als ein Windows 2000/XP Client oder Server. Unserer Webapplikation läuft trotz gleicher Hardware auf einem Windows 2003-Server bis zu 40% schneller und verbraucht weniger Ressourcen.

[Crushinator]

(...) Unserer Webapplikation läuft trotz gleicher Hardware auf einem Windows 2003-Server bis zu 40% schneller und verbraucht weniger Ressourcen. Ich würde sogar soweit gehen zu behaupten, daß auch nicht .NET basierende Webapplikationen unter Windows 2003-Server bzw. dem dortigen IIS um einen ähnlichen Faktor schneller liefen, was mich aber wieder zum Begriff Selbstzweck bringen würde. ;)

[grakaman]

Ich würde sogar soweit gehen zu behaupten, daß auch nicht .NET basierende Webapplikationen unter Windows 2003-Server bzw. dem dortigen IIS um einen ähnlichen Faktor schneller liefen, was mich aber wieder zum Begriff Selbstzweck bringen würde. ;)

Wenn du dich mit der Funktionalität von ASP.NET genauer auseinandergesetzt hättest, wüsstest du, dass das rein gar nichts mit Selbstzweck zu tun hat. Diese Technologie ist schlicht bei .NET einzigartig und JSF ist eine recht schlechte Kopie.

[Crushinator]

Wenn du dich mit der Funktionalität von ASP.NET genauer auseinandergesetzt hättest, wüsstest du, dass das rein gar nichts mit Selbstzweck zu tun hat. Diese Technologie ist schlicht bei .NET einzigartig und JSF ist eine recht schlechte Kopie. Wenn Du schon mit diesem Ton anfängst, möchte ich Dir auf selbiger Weise mitteilen, daß wenn man sich mit dem jeweiligen Bedarfsfall genauer auseinandersetzen würde, man weder ASP.NET noch sonstige propritäre Techniken bräuchte, um zum selben Ziel bei gleichem Aufwand unter höchstmöglichem Investitionsschutz zu kommen. DAS meine ich mit Selbstzweck!

[grakaman]

Wenn Du schon mit diesem Ton anfängst, möchte ich Dir auf selbiger Weise mitteilen, daß wenn man sich mit dem jeweiligen Bedarfsfall genauer auseinandersetzen würde, man weder ASP.NET noch sonstige propritäre Techniken bräuchte, um zum selben Ziel bei gleichem Aufwand unter höchstmöglichem Investitionsschutz zu kommen. DAS meine ich mit Selbstzweck!

Das ist natürlich nicht wahr und gelogen, aber das weißt du ja allerdings selbst.

[Crushinator]

Achso! Na dann, ist ja alles in Ordnung. http://www.mainzelahr.de/smile/crazy/1910.gif Wie wäre es denn mal mit nur einem Beispiel, was nur mit ASP.NET und möglichst auch nur mit Windows gar in der 2003er Server-Version in vertretbarer Zeit zu lösen sei?

[grakaman]

Achso! Na dann, ist ja alles in Ordnung. http://www.mainzelahr.de/smile/crazy/1910.gif Wie wäre es denn mal mit nur einem Beispiel, was nur mit ASP.NET und möglichst auch nur mit Windows gar in der 2003er Server-Version in vertretbarer Zeit zu lösen sei?

Für gewöhnlich ist es so, dass der, der die Behauptung aufstellt, Beweise erbringen muss. Hier sind einige Features, die die Entwicklung immens vereinfachen:

- SessionState (State Server/Datenbank/InPoc) -> eine Option in der config Datei
- Authentication/Autorisation - > bequem per config Datei, automatisches Redirect zur Login und von dort zur requestet Datei, desweiteren kannst du leicht den Benutzer impersonieren, um z.B. durch den jeweils einzelnen Identity Flow eine höhere Sicherheit zu garantieren
- volles serverseitiges Objektmodell -> extrem flexibel bei dynamischen zusammensetzen der Seite, essentiell für flexible Seitenvorlagen
- Servercontrols -> extrem flexibel/erweiterbar, spart immens Zeit durch Wiederverwendung
- Eventmodell erleichtert extrem den Zugriff auf Controls von der Seite
- viele Validierungsmöglichkeiten -> spart extrem viel Zeit
- ViewState -> speichert Inhalt der Controls, kann auch benutzt werden um eigene Objekte in der Seite zu speichern
- Lokalisierung

Hinzu kommt die erhöhte Performance. In ASP.NET 2.0 geht es sogar soweit, dass du gar keine aspx Seite mehr deployen musst, sondern nur noch die Assembly, da alles komplett kompiliert ist.

[Gast]

Achso! Na dann, ist ja alles in Ordnung. Wie wäre es denn mal mit nur einem Beispiel, was nur mit ASP.NET und möglichst auch nur mit Windows gar in der 2003er Server-Version in vertretbarer Zeit zu lösen sei?

Schwachsinnige Fragestellung. Die Frage ist ob man Spezialisten beschäftigen muß oder ob eine Laufzeit bzw Entwicklungsumgebung eine einfache Lösung von Problemen erlaubt. Man kann sicher vieles auch mit nicht proprietären Techniken lösen aber unter welchem Aufwand.

[McTristan]

Grakamans Ausführungen sind schon nicht schlecht und ASP.NET 2.0 ist wirklich genial ... Die Frage war auch für mich nie ob man nicht eine Webapplikation in einer anderen Sprache entwickeln kann da dieses Projekt ganz einfach schon immer auf Windows Technologie aufgesetzt hat und alles andere außer vielleicht Java unter Windows eh nicht wirklich geeignet ist ... PHP, Perl etc. laufen nunmal viel besser auf einem Linux/Unixserver. Programmiere selbst immer noch in PHP, würde aber mal behaupten, dass ich in ASP.NET meist wesentlich schneller am Ziel bin bzw. wesentlich einfacher bzw. logischer Kontrolle über einzelne Komponenten habe.

Das heißt nicht, dass andere Technologien schlecht sind - für mich heißt das einfach nur, dass ich mit ASP.NET & C# schneller am Ziel bin. Wenn die Programme dann auf einem Server auch noch wesentlich schneller laufen können, freut mich das doppelt.

[Crushinator]

@grakaman

Danke für das hervorragende Beispiel. Denn es ist genau so eines, welches ich erwartet hatte. =) Ich persönlich würde nämlich just in dem Augenblick, wenn eine Komplexität erkennen würde, welche Deine o.g. Features benötigte gar keine Webapplikation mehr erstellen, sondern mir überlegen, ob ich nicht lieber eine herkömmliche Anwendung über Terminalserver/Citrix/X-Sessions im Cluster freigäbe. Das hätte nämlich den Vorteil, daß selbst der kleinste NetPC mit Betriebssystemen weit entfernt von Windows in der Lage wäre, unter Nutzung all der Komfort-Funktionen des Hostbetriebssystems mit der Anwendung und seinen Controls zu kommunizieren. Diese Anwendung könnte intern dann von mir aus über SOAP mit anderen Dienstanbietenden Servern welcher Plattform auch immer angehörend kommunizieren.

Dabei würde der Kunde weder für teures Geld Windows Server Lizenzen neu-/nachkaufen müssen, noch bräuchte ich als Entwickler all das an Entwicklungstools bzw. Klassenbibliothelen wegwerfen, welche im Laufe der Jahre u.U. schon perfektioniert worden sind. Von der Performance ganz zu schweigen.

Selbstverständlich ist nichts dagegen einzuwenden, wenn man etwas unbedingt mit ASP.NET erschlagen möchte, nur soll man nicht behaupten, es ginge nur damit. ;)

[Crushinator]

Schwachsinnige Fragestellung. Die Frage ist ob man Spezialisten beschäftigen muß oder ob eine Laufzeit bzw Entwicklungsumgebung eine einfache Lösung von Problemen erlaubt. Man kann sicher vieles auch mit nicht proprietären Techniken lösen aber unter welchem Aufwand. Meine zuvorgehende Erläuterung, die am Endeffekt zu dieser von Dir angeführten Fragestellung führte, bezog sich eigentlich allein auf die zu erwartende Performancesteigerung unter Windows 2003-Server durch die Art der Integration vom IIS. Daß es sich zu einer Grundsatzdiskussion über ASP.NET entwicklete, war ursprünglich nicht meine Intention.

Nunja, wenn ich mich recht erinnere, waren wir eigentlich mitten in einer Diskussion um das berühmt berüchtigte Control Center von ATi, welches von der Komplexität her mit an Sicherheit grenzender Wahrscheinlichkeit mit ähnlichem Aufwand ohne das .NET Framework hätte erstellt werden können. Außerdem habe ich nicht den Eindruck, daß sich ATi nicht leisten könnte Spezialisten zu beschäftigen. :)

[McTristan]

Nun der entscheidene Faktor für eine Webanwendung ist aber, dass man sie überall abrufen kann - selbst ohne entsprechende Clientsoftware. Man benötigt nur einen Server und kann beliebige Clients verwenden. In etwa so wie du es für die Citrix/Terminalserver-Lösung beschreibst nur gänzlich ohne Clientsoftware (von einem Internetbrowser mal abgesehen), überall und ohne Einschränkungen. Man muß nicht umständlich Benutzerkonten anlegen, Ports in Firewalls freigeben etc. etc.

[Crushinator]

Nun der entscheidene Faktor für eine Webanwendung ist aber, dass man sie überall abrufen kann - selbst ohne entsprechende Clientsoftware. Man benötigt nur einen Server und kann beliebige Clients verwenden. In etwa so wie du es für die Citrix/Terminalserver-Lösung beschreibst nur gänzlich ohne Clientsoftware (von einem Internetbrowser mal abgesehen), überall und ohne Einschränkungen.
Laufen die angedachten Webapplikationen gänzlich ohne den neuesten IE? Vom benötigten Framework in vielen Fällen ganz zu schweigen. ;)

Die Clientsoftware gibt's übrigens auch als Browserplugin.

(...) Man muß nicht umständlich Benutzerkonten anlegen, Ports in Firewalls freigeben etc. etc. Man könnte ein einziges Benutzerkonto mit entsprechender Berechtigung für solche Fälle anlegen und auch ein Webserver sollte an entsprechenden Ports abgesichert werden, da ist der Aufwand absolut gleich.

[Gast]

Laufen die angedachten Webapplikationen gänzlich ohne den neuesten IE? Vom benötigten Framework in vielen Fällen ganz zu schweigen. ;)


Ja die laufen auch auf anderen Browsern. Und das Framework hat freilich rein gar nichts mit dem Client zu tun. Wieder ein hervorragendes Bsp. deiner Sachkenntnis.

[Gast]

Meine zuvorgehende Erläuterung, die am Endeffekt zu dieser von Dir angeführten Fragestellung führte, bezog sich eigentlich allein auf die zu erwartende Performancesteigerung unter Windows 2003-Server und dessen Integration vom IIS. Daß es sich zu einer Grundsatzdiskussion über ASP.NET entwicklete, war urspünglich nicht meine Intention.

Nunja, wenn ich mich recht erinnere, waren wir eigentlich mitten in einer Diskussion um das berühmt berüchtigte Control Center von ATi, welches von der Komplexität her mit an Sicherheit grenzender Wahrscheinlichkeit mit ähnlichem Aufwand ohne das .NET Framework hätte erstellt werden können. Außerdem habe ich nicht den Eindruck, daß sich ATi nicht leisten könnte Spezialisten zu beschäftigen. :)

Das ist natürlich an Idiotie nicht mehr zu überbieten. Am besten du verklickerst Amazon oder ebay, die sollen Ihre Frontends per Citrix zur Verfügung stellen.

[McTristan]

@Crushinator:

Selbstverständlich laufen die Sachen ohne Installation des Frameworks und ohne IE auf den verschiedensten Plattformen - deshalb ist es ja eine Webapplikationen.
Natürlich kann man auch alles so entwickeln das es nur mit dem IE funktioniert aber ich denke soetwas passiert heutzutage keinem ordentlichen Entwickler mehr ...

Das tolle am ATI CCC ist, dass es leicht sein dürfte ein Webfrontend dafür zu schreiben :P nicht, dass das jemand tun würde *grins* - im Prinzip läßt das .NET-Framework soetwas aber zu, 2 verschieden Frontends für eine Applikation.

[Crushinator]

Ja die laufen auch auf anderen Browsern. Und das Framework hat freilich rein gar nichts mit dem Client zu tun. Wieder ein hervorragendes Bsp. deiner Sachkenntnis. Also, ich habe selbst an mehreren Anwendungen unter Verwendung von ASP.NET mitentwickelt, mein lieber grakaman und kann Dir ein Lied davon singen, wie oft man in sicherheitskritischen Anwendungsfällen nicht drum herum kommt, das Framework oder eine schlimmstenfalls ActiveX-Komponente auf dem Client zu installieren und seine Dienste in Anspruch zu nehmen. Dreimal darfst Du raten, welcher Browser dann in Frage käme. Bei meiner Terminalserver-Lösung hätte der Server ohne weiteres Zugriff auf die relevanten Anschlüße.

[McTristan]

Leute die ASP.NET Anwendungen mit ActiveX-Controls entwickeln sind selber Schuld. Einzig für die Kommunikation mit Client-Hardware ist soetwas sinnvoll aber da nützt dir auch deine Terminalserver-Lösung nicht viel. Und ActiveX - soviel Schundluder damit auch getrieben wird - ist im Prinzip momentan die einzige Lösung für solche "Hardware"-Probleme oder kennst du PlugIns für Mozilla die mit Hardware kommunizieren und das an einen Webserver zurückgeben können? Hab soetwas jedenfalls noch nicht gesehen ...

[mbee]

Ich würde sogar soweit gehen zu behaupten, daß auch nicht .NET basierende Webapplikationen unter Windows 2003-Server bzw. dem dortigen IIS um einen ähnlichen Faktor schneller liefen, was mich aber wieder zum Begriff Selbstzweck bringen würde. ;)

Das dies keinesfalls stimmt, kannst Du leicht mit etlichen Beispielen oder einem LOAD-Simulator nachvollziehen. "Classic ASP" ist zwar auch auf dem IIS 6.0 leicht schneller, aber auf ASP.NET basierende Anwendungen sind spätestens nach dem ersten Aufruf durch die Laufzeitkompilierung (oder auch Vorkompilierung) um einiges schneller, was die serverseitige Verarbeitung angeht. Wenn man es geschickt anstellt, kann man auch beim Datenbankzugriff über ADO.NET noch etwas Performance herauskitzeln. Bei ungünstiger Programmierung, was den DB-Zugriff angeht, wird das ganze jedoch langsamer als über die alten ADO-Objekte im klassischen ASP. Das Ganze ist also z.T. auch ein wenig fehleranfälliger geworden.

[Crushinator]

Das ist natürlich an Idiotie nicht mehr zu überbieten. Am besten du verklickerst Amazon oder ebay, die sollen Ihre Frontends per Citrix zur Verfügung stellen. Gesagt, getan, lieber grakaman.... Ich fragte Amazon, sie sagten mir, daß sie nichts (http://www.heise.de/newsticker/meldung/43914) mit propritären Dingen zu tun und trotzdem überlebt hätten. ;)

Ich gebe allerdings zu, daß meine imaginäre Webapplikation nicht so simpel aussehen würde, wie ein Bestellsystem im Sinne eines Shops. Es ging mir um unternehmensweite Software mit komplexer Geschäftslogik und ggf. vielen Benutzerinteraktionen. Was im Hintergrund a la Transaktionssicherung passiert zählt für mich altmodischerweise zu der Kategorie serverseitiger Abhandlung, und da nehme ich mir die Freiheit, das einfachste für mich als Entwickler zu wählen, und das ist in meinem Falle Nutzung eigener bereits zigfach verwendeter Komponenten.

[Crushinator]

(...) oder kennst du PlugIns für Mozilla die mit Hardware kommunizieren und das an einen Webserver zurückgeben können? Hab soetwas jedenfalls noch nicht gesehen ... Selbst ist der Mann! Warum suchen, wenn man die Kommunikation mit der Hardware eh' selbst abhandeln muß? Ich habe jedenfalls ein Mozilla-Plugin für ein Telecash-Gerät (EC-Kartenzahlung) schreiben dürfen.

[grakaman]

Gesagt, getan, lieber grakaman.... Ich fragte Amazon, sie sagten mir, daß sie nichts (http://www.heise.de/newsticker/meldung/43914) mit propritären Dingen zu tun und trotzdem überlebt hätten. ;)

Ich gebe allerdings zu, daß meine imaginäre Webapplikation nicht so simpel aussehen würde, wie ein Bestellsystem im Sinne eines Shops. Es ging mir um unternehmensweite Software mit komplexer Geschäftslogik und ggf. vielen Benutzerinteraktionen. Was im Hintergrund a la Transaktionssicherung passiert zählt für mich altmodischerweise zu der Kategorie serverseitiger Abhandlung, und da nehme ich mir die Freiheit, das einfachste für mich als Entwickler zu wählen, und das ist in meinem Falle Nutzung eigener bereits zigfach verwendeter Komponenten.

Von verteilten bzw. n-tier Applikationen hast du anscheinend noch nichts gehört, sinnlos mit dir weiterzudiskutieren. Und ob Amazon propritäre Sachen benutzt oder nicht, spielt keine Rolle. Es ging um die Benutzung von Webfront-Ends, nicht um die zu implementierende Technologie. Und wenn du so unbedacht von Leichtigkeit und Transaktionen sprichst, hast du wohl von EnterpriseServices und .NET Attributen noch nichts gehört. Achja, und COM+ gibt es auch schon ewig unter Windows, soviel zu bewährt und verwendet.

[Crushinator]

Das dies keinesfalls stimmt, kannst Du leicht mit etlichen Beispielen oder einem LOAD-Simulator nachvollziehen. "Classic ASP" ist zwar auch auf dem IIS 6.0 leicht schneller, aber auf ASP.NET basierende Anwendungen sind spätestens nach dem ersten Aufruf durch die Laufzeitkompilierung (oder auch Vorkompilierung) um einiges schneller, was die serverseitige Verarbeitung angeht. (...) *hust* Also, nochmal ganz deutlich, damit es alle verstehen: Ich sprach davon, daß auch andere Dinge als nur .NET basierende unter dem IIS 6.0 um einen ähnlichen Faktor schneller liefen und setzte voraus, daß man über die Tatsache Bescheid weiß, daß der Core vom IIS bei Windows 2003 Server in den Kernelmode gewandert ist. Dort laufende Prozeße werden um einiges schneller abgearbeitet als jene im Usermode.

[grakaman]

*hust* Also, nochmal ganz deutlich, damit es alle verstehen: Ich sprach davon, daß auch andere Dinge als nur .NET basierende unter dem IIS 6.0 um einen ähnlichen Faktor schneller liefen und setzte voraus, daß man über die Tatsache Bescheid weiß, daß der Core vom IIS bei Windows 2003 Server in den Kernelmode gewandert ist. Dort laufende Prozeße werden um einiges schneller abgearbeitet als jene im Usermode.

Das ändert trotzdem nichts daran, dass ASP.NET Anwendungen kompiliert sind und deshalb rein technisch besser performen als PHP, ASP oder JSP.

[mbee]

*hust* Also, nochmal ganz deutlich, damit es alle verstehen: Ich sprach davon, daß auch andere Dinge als nur .NET basierende unter dem IIS 6.0 um einen ähnlichen Faktor schneller liefen und setzte voraus, daß man über die Tatsache Bescheid weiß, daß der Core vom IIS bei Windows 2003 Server in den Kernelmode gewandert ist. Dort laufende Prozeße werden um einiges schneller abgearbeitet als jene im Usermode.

husthust :D
Ne, das ist mir schon klar (bzw. habe ich das ja auch geschrieben). Auch statische HTML-Seiten werden dadurch schneller ausgeliefert. Der IIS 6.0 hat generell zugelegt.
Nichtsdestotrotz gilt weiterhin, was ich geschrieben habe: Die serverseitige Verarbeitung ist bei ASP.NET spürbar schneller als bei ASP (das selbstverständlich auch unter IIS 6.0 läuft). Kannst Du leicht testen, indem Du Dir z.B. eine Fibonacci-Reihe einmal mit ASP und einmal mit ASP.Net berechnen lässt bzw. gibt es da zig Beispiele für. Ist ja auch logisch aufgrund der Vorkompilierung/Laufzeitkompilierung.

[Crushinator]

Von verteilten Applikationen hast du anscheinend noch nichts gehört, sinnlos mit dir weiterzudiskutieren. Und ob Amazon propritäre Sachen benutzt oder nicht, spielt keine Rolle. Es ging um die Benutzung von Webfront-Ends, nicht um die zu implementierende Technologie. Ich habe zwar den Eindruck, daß Du noch nichts von etwas anderem als nur Microsoft und deren Eigenstandards gehört hast, aber wie Du wünschst. Ich verzichte auf eine Bepunktung Deinerseits wegen Beleidigung im ausgeloggten Zustand und gehe jetzt wieder meiner beruflichen Tätigkeit nach, bei der ich zwar elf Jahre lang u.A. für/auf massiv parallele(n) Maschinen und Cluster(n) Software entwickelt habe, welche aber scheinbar aufgrund ihrer Nichtherkunft aus Redmond nicht verteilt genug sind, um als solche bezeichnet zu werden.

EOD Meinerseits.

[edit aufgrund grakamans Edit]

(...) Und wenn du so unbedacht von Leichtigkeit und Transaktionen sprichst, hast du wohl von EnterpriseServices und .NET Attributen noch nichts gehört. Achja, und COM+ gibt es auch schon ewig unter Windows, soviel zu bewährt und verwendet. Meine Intuition (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=1408753#post1408753) sagt mir gerade, daß wir auf keinen gemeinsamen Nenner kommen werden, egal wie weit sich die Diskussion auch vertiefen würde.

[grakaman]

Ich habe zwar den Eindruck, daß Du noch nichts von etwas anderem als nur Microsoft und deren Eigenstandards gehört hast, aber wie Du wünschst. Ich verzichte auf eine Bepunktung Deinerseits wegen Beleidigung im ausgeloggten Zustand und gehe jetzt wieder meiner beruflichen Tätigkeit nach, bei der ich zwar elf Jahre lang u.A. für/auf massiv parallele(n) Maschinen und Cluster(n) Software entwickelt habe, welche aber scheinbar aufgrund ihrer Nichtherkunft aus Redmond nicht verteilt genug sind, um als solche bezeichnet zu werden.

EOD Meinerseits.

Soso, verteilte Applikationen ist jetzt plötzlich ein Microsoft Buzzword. Du disqualifizierst dich immer mehr...

[Crushinator]

(...) Das tolle am ATI CCC ist, dass es leicht sein dürfte ein Webfrontend dafür zu schreiben :P nicht, dass das jemand tun würde *grins* - im Prinzip läßt das .NET-Framework soetwas aber zu, 2 verschieden Frontends für eine Applikation. Ganz toll! Ehrlich! Auf diese Neuerung hat die Welt natürlich sehnsüchtigst gewartet, und deshalb wird sich CCC eine äußerst bachtenswerte Beliebtheit bei den Usern zusichern, und wir veranstalten hier so ein Theater, weil die Redaktion so blind war und diese Wohltat gänzlich übesehen hat? ;)

[Aqualon]

Ganz toll! Ehrlich! Auf diese Neuerung hat die Welt natürlich sehnsüchtigst gewartet, und deshalb wird sich CCC eine äußerst bachtenswerte Beliebtheit bei den Usern zusichern, und wir veranstalten hier so ein Theater, weil die Redaktion so blind war und diese Wohltat gänzlich übesehen hat? ;)
Warum denn nicht? Ati Remote Catalyst Control Center (ARCCC), powered by .NET(tm) Technology. Config@work, Play@home!

Ist doch die Bombenidee, als nächste Stufe gibt es dann ACVNC (ATI Catalyst Virtual Network Computing), damit man auch per Remote noch ein schnelles Spielchen wagen kann, ohne gleich seinen Rechner immer mitschleppen zu müssen ;)

Aqua

[McTristan]

Genau ... ich weiß ja gar nicht was ihr alle habt :D

[Crushinator]

Die Diskussion über Continuations möge bitte dort (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=168220) weitergeführt werden, danke.

*reopened*

[PH4Real]

Hmm... den Thread habe ich anscheinend verpasst ;)... aber ich gebe trotzdem mal meine Meinung dazu:

Obwohl ich .NET grundsätzlich befürworte, werden jedoch etliche es nicht installieren, weil es momentan einfach noch nicht genug Programme erfordern bzw. nicht im Betriebssystem erhalten ist.

Wenn ATI auf Java gesetzt hätte wäre das Geschrei wahrscheinlich genauso groß. Ich kenne auch eine Menge Leute die die JVM nicht installiert haben und sogar einen, bei dem die Installation Probleme machte (das liegt wahrscheinlich eher an seinem System, aber das ist ihm, als reiner Benutzer, erstmal egal, warum es nicht läuft).

Wenn also in Zukunft viele Hersteller nachziehen wird ATI als Vorreiter darstehen. Falls aber die Masse erst mit Longhorn umsteigen, dürfte es doch viele Benutzer nerven extra für ATI das .NET Environment zu installieren.

[mbee]

Mal abgesehen davon und von den ganzen aggressiven Äußerungen, muß ich doch feststellen, dass man einfach keine vernünftigen Diskussionen über Microsoft-Produkte führen kann. Immer wieder wird die Monopolstellung (die in meinen Augen nicht mehr wirklich existiert) von Microsoft hervorgehoben, dass man bloß nicht auf die Idee kommen sollte dieses Monopol auch noch zu unterstützen. Da wird auf Sicherheitslücken in Microsoftprodukten verallgemeinert, davon geredet das der vom .NET-Framework installierte User ja ach so suspekt und gefährlich ist ...

Nee ich kann's nicht mehr hören. Erinnert mich ein wenig an das gebashe im heise.de-Forum. Ok, man kann einem Ottonormalbenutzer nicht vorwerfen das er keine Ahnung von der dahinterliegenden Technologie hat. Und ja, es ist natürlich dumm wenn man erst noch einen ganzen Packen an Systemdateien installieren muß um ein simples Kontrollpanel für eine Grafikkarte zu benutzen. Aber ooh je, es gibt doch wohl noch andere Programme die das .NET-Framework benutzen.

Die Leute, welche das .NET-Framework programmieren wissen nur allzu gut wieviel Arbeit es einem abnehmen kann, wenn man damit schneller und womöglich sicherer ans Ziel kommt, kann man ATI nur zu dieser Entscheidung beglückwünschen. Das Geld was man da bei der Entwicklung eingespart hat, kann man sicher an anderer Stelle sinnvoller einsetzen. Ob's dem Kunden schmeckt oder nicht - eine Firma muß in allererster Linie wirtschaftlich agieren.

Just my 0.02€

Selten einen IMHO so objektiven Post in diesem doch recht "bunten" Thread gelesen. 100% ACK! :up:

[Klingone mit Klampfe]

[OT] Könnte mal ein Mod den Threadtitel anpassen? Zum Beispiel in "Diskussion zu .NET und CCC" oder ähnlich.

Der nichtssagende, populistische Threadtitel ist anbetracht der mittlerweile doch recht gediegenen Diskussion unpassend.

[grakaman]

Wenn also in Zukunft viele Hersteller nachziehen wird ATI als Vorreiter darstehen. Falls aber die Masse erst mit Longhorn umsteigen, dürfte es doch viele Benutzer nerven extra für ATI das .NET Environment zu installieren.

Ne, wieso sollte das für ATI ein Problem sein? Wenn der Installer die Runtime nicht erkennt, wird sie eben erst vor dem Programm installiert. Jeder Graka liegen doch eine Treiber CD bei, auf der auch genügend Platz für die Runtime ist.

[Crushinator]

[OT] Könnte mal ein Mod den Threadtitel anpassen? Zum Beispiel in "Diskussion zu .NET und CCC" oder ähnlich. *done* =)

[Gast]

*done* =)

<-- Threadstarter

Ich hab den Titel aber bewusst so gewählt. Mir gings nicht um ATIs CCC sondern um den subjektiven Lagerjournalismus gegenüber .NET.

[Klingone mit Klampfe]

Aber darum geht's in der Diskussion nicht mehr ;)

[Gast]

Aber darum geht's in der Diskussion nicht mehr ;)


geiles forum wo threadhijacker den titel ändern.

[Klingone mit Klampfe]

Deine Provokation wurde auf mindestens 5 Seiten ausführlich durchgekaut. Anschließend gab es einen fließenden Übergang zu einer sachlichen Diskussion zum Thema .NET.

Das rechtfertigt in meinen Augen eine Titeländerung durchaus. Du hast doch nicht ernsthaft erwartet dass hier das große Leo-Bashing losbricht...

[Gast]

Deine Provokation wurde auf mindestens 5 Seiten ausführlich durchgekaut. Anschließend gab es einen fließenden Übergang zu einer sachlichen Diskussion zum Thema .NET.

Das rechtfertigt in meinen Augen eine Titeländerung durchaus. Du hast doch nicht ernsthaft erwartet dass hier das große Leo-Bashing losbricht...

lol
Also ich lese ziemlich oft: "Ich muß dem Thread starter zustimmen.." etc
Zu einer Diskussion über .NET wurde es nur weil Leute (die meisten ohne einen blassen schimmer wie du) es dazu gemacht haben.
Das Thema war die subjektive und unsachliche Berichterstattung und nicht das Control Center von ATI.

[Klingone mit Klampfe]

War ist das Stichwort

[Korak]

lol
Also ich lese ziemlich oft: "Ich muß dem Thread starter zustimmen.." etc
Zu einer Diskussion über .NET wurde es nur weil Leute (die meisten ohne einen blassen schimmer wie du) es dazu gemacht haben.
Das Thema war die subjektive und unsachliche Berichterstattung und nicht das Control Center von ATI.

Das was du gelesen hast mag subjektiv und unsachlich sein, das was da wirklich stand ist es nicht.

[PH4Real]

Ne, wieso sollte das für ATI ein Problem sein? Wenn der Installer die Runtime nicht erkennt, wird sie eben erst vor dem Programm installiert. Jeder Graka liegen doch eine Treiber CD bei, auf der auch genügend Platz für die Runtime ist.

Ja klar, ähnlich wie bei Opera, da gibt es auch die "big" Version mit JRE (ca . 15 MB) und die ohne (ca. 3 MB).

Aber solange ATI noch ein Vorreiter ist, werden sich viele beschweren, da sie .NET eben (noch) nur für ATI brauchen.

[Gast]

War ist das Stichwort


Ok dann sollten wir den Thread titel nun wieder ändern auf:
"Anpassung der Threadtitel an den Inhalt der letzten 5 Posts: Gut oder Schlecht?"

Du erkennst hoffentlich die Ironie.

[Klingone mit Klampfe]

Ich weiß ja was du meinst.

Wenn jetzt aber jemand den ursprünglichen Titel liest weiß er überhaupt nix über den Inhalt. Hättest Du "Ihr Schweine habt was gegen .NET" genommen wäre wenigstens ein Bezug zum inhalt dagewesen.

Davon abgesehen ist die News schon längt im Archiv verschwunden (das sage ich wertungsfrei, ist halt weg)

[Black-Scorpion]

Aber solange ATI noch ein Vorreiter ist, werden sich viele beschweren, da sie .NET eben (noch) nur für ATI brauchen.
Dazu empfehle ich mal diesen Thread.
Da werden Anwendungen gesammelt die das Net Framework brauchen.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=167648

Es ist also nicht so das ATI ein Vorreiter ist, eher sind sie nur auf den Zug aufgesprungen.
Und es werden mit Sicherheit noch viele Anwendungen dazu kommen.

[PH4Real]

Dazu empfehle ich mal diesen Thread.
Da werden Anwendungen gesammelt die das Net Framework brauchen.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=167648

Es ist also nicht so das ATI ein Vorreiter ist, eher sind sie nur auf den Zug aufgesprungen.
Und es werden mit Sicherheit noch viele Anwendungen dazu kommen.

Ist Dir die Wortwahl "einer der Vorreiter" lieber ;) ?

Außerdem umfasst die Liste der Applikationen grob überflogen gerade mal 30 Einträge...

Das mit Sicherheit noch mehr Anwendungen dazu kommen bezweifel ich auch nicht. Aber der, ich nenne ihn jetzt mal "Standart-Otto-Normal-User-Gamer", wird wohl das erste Mal in Kontakt mit der .NET Runtime beim Installieren seiner ATI Karte kommen.

[grakaman]

Ja klar, ähnlich wie bei Opera, da gibt es auch die "big" Version mit JRE (ca . 15 MB) und die ohne (ca. 3 MB).

Aber solange ATI noch ein Vorreiter ist, werden sich viele beschweren, da sie .NET eben (noch) nur für ATI brauchen.

Versteh die Logik nicht. Das kann doch dem Benutzer vollkommen egal sein, was für Systemkomponenten installiert sind. Bei den meisten Updates hat der Benutzer sowieso weder Ahnung noch Lust, sich damit auseinanderzusetzen, was denn genau am System modifiziert wurde und wie es funktioniert. Letztendlich liest er beim Windows Updater nur, dass es ein Sicherheitspatch oder sonstwas gibt. Warum soll das bei .NET anders sein? Es gibt z.B. auch Software, die das SP4 von W2k voraussetzen und wenn man die entsprechenden Anforderungen nicht erfüllt, gibt es ganz einfach keinen Support.

[H5N1]

Ich wette, M$ hat dafür ein paar Dollar springen lassen, damit ".net" in Zukunft rege Verbreitung (zumindest in der ATI-Gemeinde) findet. Ich kenne bis jetzt NIEMANDEN, der sich ".net" freiwillig installiert hat. Immer nur, wenn es unbedingt nötig war...

[Exxtreme]

Ich wette, M$ hat dafür ein paar Dollar springen lassen, damit ".net" in Zukunft rege Verbreitung (zumindest in der ATI-Gemeinde) findet. Ich kenne bis jetzt NIEMANDEN, der sich ".net" freiwillig installiert hat. Immer nur, wenn es unbedingt nötig war...
Nicht unbedingt. Das, was ATi vorhat mit CCC, lässt sich kaum mit anderen Methoden in vernünftiger Art und Weise realisieren. ATi will ein leicht erweiterbares Controlpanel. Jetzt versuch das mal mit MFC *würg* oder Win32-API *nochmehrwürg* zu erreichen. :D Mit COM tät's gehen aber COM verursacht bei mir auch Brechreize. :D

[(del)]

Ich wette, M$ hat dafür ein paar Dollar springen lassen, damit ".net" in Zukunft rege Verbreitung (zumindest in der ATI-Gemeinde) findet. Ich kenne bis jetzt NIEMANDEN, der sich ".net" freiwillig installiert hat. Immer nur, wenn es unbedingt nötig war...
Ich hatte es freiwillig installiert, schon bevor das CCC erschen.

Warum? Standard der Zukunft.

Seht es ein: Das .NET Framework ist kein binär gewordener Terrorist. Sich dagegen zu widersetzen ist OK. Das liegt in der Natur der Menschen zu streiten und zu diskutieren, aber dann ständig subjektive Argumentationen hervorzuziehen ist armselig...

[Tigerchen]

Nicht unbedingt. Das, was ATi vorhat mit CCC, lässt sich kaum mit anderen Methoden in vernünftiger Art und Weise realisieren. ATi will ein leicht erweiterbares Controlpanel. Jetzt versuch das mal mit MFC *würg* oder Win32-API *nochmehrwürg* zu erreichen. :D Mit COM tät's gehen aber COM verursacht bei mir auch Brechreize. :D

Alles schön und gut. Aber wenn das CP dadurch so fett und träge ist daß mir schlecht wird dann pfeife ich auf .net!

[Gast]

Warum wird überhaupt soviel über die .NET Installation gestritten ? Wenn ich mich recht entsinne, ist es bei XP.SP1 und .XP2 eh dabei und sollte somit auf vielen Rechnern bereits vorhanden sein ^^

Sentinel

[deekey777]

Warum wird überhaupt soviel über die .NET Installation gestritten ? Wenn ich mich recht entsinne, ist es bei XP.SP1 und .XP2 eh dabei und sollte somit auf vielen Rechnern bereits vorhanden sein ^^

Sentinel


.Net ist von Microsoft. Microsoft = Evil.
Bei mir ist .Net schon seit der Release drauf - es nervte mich einfache, dass ich bei Windows Update darauf hingewiesen wurde. :D

[Aqualon]

Warum wird überhaupt soviel über die .NET Installation gestritten ? Wenn ich mich recht entsinne, ist es bei XP.SP1 und .XP2 eh dabei und sollte somit auf vielen Rechnern bereits vorhanden sein ^^

Sentinel
Nein, .NET muss man immer noch selbst installieren. Standardmäßig wird es wohl erst bei Longhorn dabeisein.

Aqua

[noid]

.NET klingt nur böse,wenn man jeden kontakt zum internet wegen raubkopie unterbinden will. welches framework verwendet wird ist doch egal, hauptsache es läuft gut.
man könnte sich ja auch aufregen, wenn zB gimp nicht ohne xy will.

[Leonidas]

.NET klingt nur böse,wenn man jeden kontakt zum internet wegen raubkopie unterbinden will.


Seltsam. Ich besitze keinerlei Raubkopien und will trotzdem kein NET.

[zeckensack]

Nicht unbedingt. Das, was ATi vorhat mit CCC, lässt sich kaum mit anderen Methoden in vernünftiger Art und Weise realisieren."Das was ATI vorhat" entspricht in keinster Weise meinen Bedürfnissen. Von daher ist es mir auch egal, wie das technisch gelöst ist.

Ich hoffe nur dass die "Tweak-Tool-Schrauber" *hinthint* einen vollwertigen Ersatz hinbekommen, bevor ATI das CP killt. Sonst stelle ich mich persönlich im Kaufberatungsforum auf, und warne vor ATI-Karten, wegen "beschissenen Treibern".

[Crushinator]

(...) Ich hoffe nur dass die "Tweak-Tool-Schrauber" *hinthint* einen vollwertigen Ersatz hinbekommen, bevor ATI das CP killt. Sonst stelle ich mich persönlich im Kaufberatungsforum auf, und warne vor ATI-Karten, wegen "beschissenen Treibern". Du wirst lachen, ich habe tatsächlich vor die Funktionalität des CCC nachzubauen, was bisher daran scheitert, daß ich das Ding nicht auf dem Rechner haben möchte, wo ich mit hauptsächlich in der Freizeit entwickle. Ein selbstgemachter Teufelskreis könnte man meinen. :D

[zeckensack]

Du wirst lachen, ich habe tatsächlich vor die Funktionalität des CCC nachzubauen, was bisher daran scheitert, daß ich das Ding nicht auf dem Rechner haben möchte, wo ich mit hauptsächlich in der Freizeit entwickle. Ein selbstgemachter Teufelskreis könnte man meinen. :DUnd du wirst hoffentlich auch nicht lachen, wenn ich dir sage dass ich quasi als Trotzreaktion daran gedachte habe, ein gewisses eigenes "control panel", das bisher als schmucklose 80kiB große native Win32-Applikation vorliegt, nach Java (Swing) zu portieren. Und ich denke immer noch ernsthaft darüber nach. Einfach um der Welt mal kontrastierend zu zeigen was RTEs bringen können, wenn man sie vernünftig einsetzt. Dabei spreche ich (noch) garkein Swing ...

€: Korrektur 50kiB => 80kiB.
In Java bin ich momentan bei 8,5kB. Tendenz weiter steigend, aber relativ klein bleibt das auf jeden Fall.
Bonus-Spam: Borland JBuilder rockt ...

[Crushinator]

Schönes Ding, Zecki! :up:

[Aqualon]

Wie schaut es bei ATI eigentlich mit der Speicherung der Einstellung aus? Müsste der Teil des Control Panels für jedes OS getrennt programmiert werden oder unterscheiden sich da die Treiber für Win btw. *nix nicht?

Aqua

[tb]

Ich finde das neue Control Panel optisch ganz okay, jedoch ist es mir viel zu langsam und es verschlingt mir zuviel Speicher, wenn ich es nicht verwende!
Ob es Java, .NET, MFC, Win32, ... verwendet ist mir als Endanwender egal. Vom Entwicklerstandpunkt gefällt mir das .NET Framework besser als Java, rein von der Konzeption der Klassen und dem Arbeitsaufwand den ich benötige um spezielle Aufgaben zu lösen.
Es ist mir vom Entwicklerstandpunkt her völlig egal, welche Technologie (Open Source, Closed Source) ich verwende, solange ich effizient entwickeln kann, dabei spielt es keine Rolle ob ich die jeweilige Firma oder deren Politik für sympatisch halte, oder nicht.

Thomas

[Leonidas]

Es ist mir vom Entwicklerstandpunkt her völlig egal, welche Technologie (Open Source, Closed Source) ich verwende, solange ich effizient entwickeln kann, dabei spielt es keine Rolle ob ich die jeweilige Firma oder deren Politik für sympatisch halte, oder nicht.




Und ich werfe meine Grundüberzeugungen nicht über Board, wenn ich plötzlich von der Zuschauer-Rolle in einer Macher-Rolle komme. Habe ich mit 3DC schließlich auch nicht getan, wenn es um Punkte wie ActiveX, Javascript etc. geht, welche mich als Zuschauer stören, als Macher jedoch Geld einbringen könnten.

[tb]

Und ich werfe meine Grundüberzeugungen nicht über Board, wenn ich plötzlich von der Zuschauer-Rolle in einer Macher-Rolle komme. Habe ich mit 3DC schließlich auch nicht getan, wenn es um Punkte wie ActiveX, Javascript etc. geht, welche mich als Zuschauer stören, als Macher jedoch Geld einbringen könnten.

Geändert habe ich meine Grundüberzeugungen nicht. Seit ich mich mit .Net beschäftigt habe, hallte ich die Bedenken dagegen für nicht untermauert. Es bringt schlicht mehr Vorteile für die Windowswelt, als Nachteile.
Gefallen muss mir die Technologie schon und da halt ich .Net für eine elegante Lösung in der Windowswelt. ActiveX und Javascript hingegen nicht. Mit effizient meinete ich eher entspannend für mich, nicht unbendingt Kosteneffizient.
Über kurz oder lang wird die Softwareentwicklung unter/für Windows zu .Net übergehen, schon allein deshalb, weil ab Longhorn keine andere API mehr zu Verfügung steht um alle Features von Longhorn zu nutzen.

Ginge es nach Sympathie, dürfte ich von kaum einer Aktiengesellschaft Waren kaufen :(

Thomas

[Crushinator]

(...) Über kurz oder lang wird die Softwareentwicklung unter/für Windows zu .Net übergehen, schon allein deshalb, weil ab Longhorn keine andere API mehr zu Verfügung steht um alle Features von Longhorn zu nutzen. (...) Die Frage, welche Features vom (i.Ü. noch ungelegten Ei) Longhorn nur noch über .Net Frameworks zu erreichen seien, spielt meiner Meinung nach eine sehr große Rolle in dieser Diskussion. Man wird wohl nicht davon ausgehen, daß kaum eine der bisherigen Win32-Anwendung mehr auf Longhorn laufen würde, oder? ;)

[zeckensack]

Wenn ich auch noch mal ein wenig philosophieren darf ...
Longhorn per se schwächt die Windows-Plattform. Da ist wieder ein riesen Bruch in der Kontinuität (wie damals bei Win95 vs Win3.11), Kompatibilitätsprobleme werden wohl tonnenweise auftreten müssen. Anderes Treibermodell, evtl anderes Dateisystem, etc sind erstmal die Wurzeln des Übels.

Schwäche einer Plattform ist aber immer auch gleichzeitig eine Chance für andere Plattformen. Ihr wisst was ich im Sinn habe. Das eigentliche Hauptproblem ist nämlich das "wir müssen unsere Software anpassen" auf Seiten der Entwickler (nicht umsonst Steve Ballmers Lieblingswort btw). Das kann leicht dazu führen, dass sie anstatt einfach draufloszutippen erstmal evaluieren ... andere System evaluieren, und auf Longhorn scheissen, möglicherweise, oder einfach nur nach Wegfall der alten Bindungen den Code gleich voll portabel machen, sodass er nicht nur für Longhorn passt.

Microsoft hat einige Werkzeuge an der Hand, deren einzige Existenzberechtigung genau das Verhindern dieser Evaluierungsphase ist.
DirectX
.NET

Diese Dinge sind a)technisch betrachtet unnötig, b)sie binden auf mehreren Ebenen Energie, die sonst für andere Zwecke verwendet werden könnte, c)sie erzeugen bei längerer Benutzung eine "Abhängigkeit" durch Gewöhnung, und das was man üblicherweise "kritische Masse" nennt, was letztendlich in einen Verdrängungswettbewerb mit den "vernünftigen" Pendants mündet. DirectX Graphics existiert um OpenGL zu verdrängen (und irgendwann früher mal, im genauen die Version 5, um das ebenso portable Glide zu verdrängen), um Entwickler an Windows zu binden, und um Treiberentwickler die Zeit zu nehmen, die sie für eine weitere Aufwertung der Alternative benötigen würden. Und das ganze ist mittlerweile natürlich weit fortgeschritten.

.NET existiert um Java zu verdrängen. Gleichzeitig bringen .NET-Anwendungen Longhorn einen Teil der verlorenen Kontinuität zurück.

Wer sich als Entwickler auf .NET einschiesst, begeht IMO ein paar schwere Sünden:
1)ihr verschwendet eure Zeit (erlernen, einarbeiten)
2)ihr verschwendet euer Geld (kompatible Entwicklungsumgebungen, und Zeit=Geld)
3)ihr stärkt ein Monopol und dessen Produkte
4)ihr schwächt das Original

Und du einzige substantielle Rechtfertigung dafür ist dass Microsoft für mehrere Sprachen .NET-Compiler anbietet. Ein "Zuckerl", das ihr wohl schon gefressen habt.

Nüchtern betrachtet sollte man sich für Java entscheiden. Es ist ausgereifter, es ist portabel, es hat die "kritische Masse" schon längst erreicht. Wenn Longhorn-Schachteln nur einen Springteufel enthalten, habt ihr eure Software nicht umsonst umgeschrieben, sondern könnt sie auf real existierende Systeme setzen. Und von jemandem der nur in VB programmieren kann will ich sowieso keine Software haben.

Die teils schockierenden Demonstrationen von Design-Unfähigkeit in diversen Microsoft-Kernprodukten habt ihr wohl auch noch nicht gesehen, oder verstanden.
</erregter Padawan>

[aths]

.NET existiert um Java zu verdrängen.Was aus meiner Sicht eher zu begrüßen ist. Ich spiele ernsthaft mit dem Gedanken mir C# zuzulegen.

Wer sich als Entwickler auf .NET einschiesst, begeht IMO ein paar schwere Sünden:
1)ihr verschwendet eure Zeit (erlernen, einarbeiten)Bei C# soll es (getestet hab ich das noch nicht) ähnlich einfach wie mit Delphi sein, Oberflächen zu erzeugen. MS Visual C++ halte ich ja für einen Irrweg (zu viel Tipparbeit.)

Java erlebe ich hier als indiskutable Variante. Ehe man sich eine brauchbare Arbeitsumgebung geschaffen hat ... einmal eingearbeitet mag man das als pillepalle empfinden. Für mich ist's eine Hürde.

(Einschießen bitte mit ß schreiben, bitte bitte.)

Und du einzige substantielle Rechtfertigung dafür ist dass Microsoft für mehrere Sprachen .NET-Compiler anbietet. Ein "Zuckerl", das ihr wohl schon gefressen habt.Ich kann weder Java, noch C, noch C++. (Für die kleinen Projekte im Studium reichts, aber nicht um Häuser zu bauen.) Java ist mir viel zu streng. Grafische Oberflächen etc. für Java? Da gibt es x unterschiedliche Möglichkeiten. Für .Net gibts .Net.


Wenn Longhorn-Schachteln nur einen Springteufel enthaltenhttp://www.aths.de/files/UD.gif

Die teils schockierenden Demonstrationen von Design-Unfähigkeit in diversen Microsoft-Kernprodukten habt ihr wohl auch noch nicht gesehen, oder verstanden.</erregter Padawan> Im Zusammenhang mit aTuner habe ich gesehen wie ätzend es ist, mit der Windows-API zu arbeiten. Alles so uneinheitlich, sieht aus wie Kraut und Rüben. Insofern erwarte ich von .Net eigentlich Vorteile.

[HellHorse]

Java erlebe ich hier als indiskutable Variante
Wenn du meinst, ein GUI-Bilder sei eine gute Sache: praktisch jede IDE hat einen.
Java ist mir viel zu streng.
Java ist halt statisch typisiert (und zieht das immer mehr auch durch).
Wenn dir das nicht passt: nimm eine dynamisch typisierte Sprache.

Grafische Oberflächen etc. für Java? Da gibt es x unterschiedliche Möglichkeiten. Für .Net gibts .Net.
Was ist daran schlecht, dass du eine Wahl hast?

[Exxtreme]

aths,

C# ist genauso wie Java, verkapptes C++. Die Syntax ist praktisch gleich etc. Also wenn du von Delphi umsteigst dann wird der Aufwand nicht wirklich geringer sein egal für was du dich entscheidest.

/me wird sich demnächst mit Java beschäftigen. Java ist nämlich auch in der Praxis plattformunabhängig. =)

[Crushinator]

(...) Java erlebe ich hier als indiskutable Variante. Ehe man sich eine brauchbare Arbeitsumgebung geschaffen hat ... einmal eingearbeitet mag man das als pillepalle empfinden. Für mich ist's eine Hürde. Da Du scheinbar gut mit der IDE von Delphi zurecht kommst, dürfte Dir der aktuelle JBuilder etwas entgegen kommen. Eine Flash-Tour durch die IDE findest Du zum offline schauen hier (http://dotnet.borland.com/bdntv/jbuilder/2005/tour/jb2005idetour.zip). Sie stammt von der Seite (http://bdn.borland.com/article/0,1410,32740,00.html) des Borland Developer Network.
(...) Im Zusammenhang mit aTuner habe ich gesehen wie ätzend es ist, mit der Windows-API zu arbeiten. Alles so uneinheitlich, sieht aus wie Kraut und Rüben. Insofern erwarte ich von .Net eigentlich Vorteile. Und Du bist Dir sicher, daß die API-Funktionen, welche Du benötigt hattest, durch das .Net Framework völlig überflüssig würden? ;)

[zeckensack]

Was aus meiner Sicht eher zu begrüßen ist. Ich spiele ernsthaft mit dem Gedanken mir C# zuzulegen.

Bei C# soll es (getestet hab ich das noch nicht) ähnlich einfach wie mit Delphi sein, Oberflächen zu erzeugen. MS Visual C++ halte ich ja für einen Irrweg (zu viel Tipparbeit.)

<schnipp>

Ich kann weder Java, noch C, noch C++. (Für die kleinen Projekte im Studium reichts, aber nicht um Häuser zu bauen.) Java ist mir viel zu streng. Grafische Oberflächen etc. für Java? Da gibt es x unterschiedliche Möglichkeiten. Für .Net gibts .Net.Du verwechselst die IDE mit den Fähigkeiten der Sprache bzw Runtime. Es gibt GUI-Zusammenklicker für alle dieser Plattformen.

MSVC6 enthält zB einen GUI-Bastler direkt für die Win32-API (wird als "Ressource" gespeichert, und erzeugt keinen Code).
Wenn du eine mächtige IDE inklusive GUI-Bastler für Java suchst, kann ich dir Borland's JBuilderX "Foundation Edition" ans Herz legen (kostenlos auch für kommerzielle Nutzung).
Visual Studio .NET enthält sicherlich einen GUI-Bastler für .NET. Würde mich auch wundern, wenn es nicht so wäre.

Du sprichst hier einen Nachteil an: es gibt keine (?) anderen Produkte zum GUI-Basteln für .NET außer MSVS. Ich verstehe nicht, warum du das für einen Vorteil hältst.
IMO wird Borland irgendwann etwas entsprechendes liefern, in Form einer neuen Delphi-Version (die .NET-Code erzeugen wird). Meine ich zumindest gelesen zu haben.

Im Zusammenhang mit aTuner habe ich gesehen wie ätzend es ist, mit der Windows-API zu arbeiten. Alles so uneinheitlich, sieht aus wie Kraut und Rüben. Insofern erwarte ich von .Net eigentlich Vorteile.Warum? .NET ist im GUI-Bereich auch kein Ersatz für die Win32-API sondern ein Aufsatz. Ebenso wie nativer Code, oder Java, muss sich .NET mit den Unzulänglichkeiten dieser API herumschlagen.
*hust* (http://java.sun.com/docs/books/tutorial/uiswing/learn/example1.html)The final bit of code in HelloWorldSwing—-and in all of our examples—-looks like this:
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
/* create and show the GUI */
}
});You can copy this code and use it as-is. It might look daunting, but we recommend it because it ensures that the GUI won’t have a thread-safety problem that could break the UI before it even appears onscreen.
Java erlebe ich hier als indiskutable Variante. Ehe man sich eine brauchbare Arbeitsumgebung geschaffen hat ... einmal eingearbeitet mag man das als pillepalle empfinden. Für mich ist's eine Hürde.Aber .NET kannst du einfach so? :conf2:

Nochmal: GUI zusammenklicken geht hüben wie drüben. Wenn du Programme machen willst die nicht nur eine Oberfläche haben, sondern auch noch irgendetwas tun, also mit der Logikimplementierung beginnst, wirst du feststellen dass die Syntax garnicht so unähnlich ist. Und Pascal-artig ist beides nicht ...

[Xmas]

Wer sich als Entwickler auf .NET einschiesst, begeht IMO ein paar schwere Sünden:
1)ihr verschwendet eure Zeit (erlernen, einarbeiten)
2)ihr verschwendet euer Geld (kompatible Entwicklungsumgebungen, und Zeit=Geld)
3)ihr stärkt ein Monopol und dessen Produkte
4)ihr schwächt das Original
Davon ist 3) ja wohl das einzige gültige Argument, denn 1) und 2) gelten für alle Plattformen, und das "Original" zu sein ist in den meisten Fällen kein Qualitätsmerkmal, auch hier nicht.

[zeckensack]

Davon ist 3) ja wohl das einzige gültige Argument, denn 1) und 2) gelten für alle Plattformen, <...>Sie gelten ganz besonders für Microsoft-Produkte. Erfahrungsgemäß braucht Microsoft mehrere Revisionen und API-Änderung, um irgendwas auch nur im Ansatz ordentlich hinzukriegen. Es mangelt einfach an Design-Kompetenz.

Wenn bei jeder größeren Revision Teile des bis dahin erlernten nutzlos werden, dann ist das sehr wohl Energieverschwendung.

Und wenn irgendwas dann mal akzeptabel wird, dann liegt das auch nicht unbedingt an Microsoft, sondern an all den "externen", die ihre Energie und Kompetenz dort eingebracht haben (ganz besonders deutlich zB bei DirectX Grapics; aber auch reine Nutzer, die einfach nur Feedback geben, leisten dadurch Entwicklungshilfe).
<...> und das "Original" zu sein ist in den meisten Fällen kein Qualitätsmerkmal, auch hier nicht.Man muss kein Genie sein, um das jeweilige Objekt der Verdrängungsabsicht erkennen zu können. Deswegen der Begriff "Original".
Ein Qualitätsmerkmal ist es natürlich nicht. Ebensowenig wie "ist von Microsoft" ein Qualitätsmerkmal ist.

[Exxtreme]

zecki,

laufen die Java Pseudo-Binaries aus'm JBuilder auch unter Linux?

[zeckensack]

zecki,

laufen die Java Pseudo-Binaries aus'm JBuilder auch unter Linux?IMO ja. Alles was Borland-spezifisch ist, sind Wrapper-Klassen und zT Beans, die es nur braucht damit der GUI-Bastler rund läuft. Borland empfiehlt in einigen Fällen selber, das nur während der Designphase zu nutzen, und dann in etwas portableres umzuwandeln (zB Borland XYLayout sollte man alleine schon wegen "LookAndFeel"- und Schriftgrößenüberlegeungen nach getaner Arbeit in zB ein GridbagLayout wandeln). Aber selbst das muss man nicht. Es geht auch so.

Man braucht jedenfalls den JBuilder nicht, um das Resultat auszuführen. Dazu reicht einfach die JRE (man kann sich auch aussuchen, welche JRE-Version die Zielplattform sein soll, btw). Die benötigten Teile werden einfach mit dem eigenen Code zusammen in ein JAR gepackt, wenn man das wünscht. Sollte man natürlich machen, wenn man plant das ganze weiterzugeben. Und es sind wirklich nur die tatsächlich genutzten Klassen, echten "bloat" handelt man sich dabei nicht ein.

Linux habe ich noch nicht angetestet, da läuft bei mir momentan sowieso nichts spannendes ab. Ich kann jedenfalls ohne Probleme auf einem Windows-Rechner, der noch nie ein Borland-Produkt gesehen hat, die Sachen mit
java -jar blablub.jar
ausführen, und sie tun was sie tun sollen.

[Exxtreme]

zecki, wenn du mal so ein Binary hast, schicke es mir bitte per Mail an nowak-aleksander2 at gmx dot de. =) Wenn ich es auch ausführen kann dann werde ich mir mal den JBuilder "antun". =)

[zeckensack]

Du hast Mehl.

[Xmas]

Sie gelten ganz besonders für Microsoft-Produkte. Erfahrungsgemäß braucht Microsoft mehrere Revisionen und API-Änderung, um irgendwas auch nur im Ansatz ordentlich hinzukriegen. Es mangelt einfach an Design-Kompetenz.
Ich glaube nicht dass das bei Microsoft ein besonders großes Problem ist im Vergleich zu anderen Software-Firmen. Microsoft hat aber die Marktmacht, bei groben Schnitzern den Fehler einzusehen und das bestehende umzukrempeln. Das machen andere Große allerdings auch. Bei den Kleinen ist das oftmals ein Risiko, das dann nicht eingegangen wird, obwohl es vielleicht besser wäre.

Wenn bei jeder größeren Revision Teile des bis dahin erlernten nutzlos werden, dann ist das sehr wohl Energieverschwendung.
Das haben die meisten Revisionen nun mal so an sich. Man sollte es mit der Abwärtskompatibilität auch nicht übertreiben.

Und wenn irgendwas dann mal akzeptabel wird, dann liegt das auch nicht unbedingt an Microsoft, sondern an all den "externen", die ihre Energie und Kompetenz dort eingebracht haben (ganz besonders deutlich zB bei DirectX Grapics; aber auch reine Nutzer, die einfach nur Feedback geben, leisten dadurch Entwicklungshilfe).
Natürlich leisten die Nutzer "Entwicklungshilfe". Jeder Entwickler der das Feedback nicht ausnutzt, wirft Potenzial zum Fenster raus.

Man muss kein Genie sein, um das jeweilige Objekt der Verdrängungsabsicht erkennen zu können. Deswegen der Begriff "Original".
Die meisten Produkte, die auf den Markt kommen, sollen ein Konkurrenzprodukt zumindest ein bisschen verdrängen. Um das zu schaffen müssen ja schon gewisse Qualitäten vorhanden sein, sonst wird das nichts.

[aths]

Da Du scheinbar gut mit der IDE von Delphi zurecht kommst, dürfte Dir der aktuelle JBuilder etwas entgegen kommen.ATM will ich einfach eine Textkonsolen-Anwendung schreiben: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=177432. HellHorses Postings helfen mir da allerdings nicht weiter. (Was er schreibt ist sicher nicht falsch, nur für mich leider zu hoch.)

In C# kann ich es leider nicht machen, da auf den Rechnern der Hochschule kein .Net installiert ist.

[Crushinator]

Wie Du jetzt anhand von Hellhorses Code sehen kannst, ist's nicht wirklich schlimm. ;)

[Leonidas]

Geändert habe ich meine Grundüberzeugungen nicht. Seit ich mich mit .Net beschäftigt habe, hallte ich die Bedenken dagegen für nicht untermauert. Es bringt schlicht mehr Vorteile für die Windowswelt, als Nachteile.




Das kann ich mir beim besten Willen nicht vorstellen. Allein der Nachteil "Microsoft" sollte ausreichend genug sein - und sich auch nicht durch genauere Beschäftigung mit dem Produkt in Luft auflösen lassen.

[Leonidas]

Microsoft hat einige Werkzeuge an der Hand, deren einzige Existenzberechtigung genau das Verhindern dieser Evaluierungsphase ist.
DirectX
.NET




... wenn ich ein klein wenig mehr Geld hätte, würde ich mit Erscheinen von WGF eine Initiative sponsoren, welche WGF (PS: Scheiss natürlich aufs Urheberrecht) auf Linux umsetzt.

[Exxtreme]

Das kann ich mir beim besten Willen nicht vorstellen. Allein der Nachteil "Microsoft" sollte ausreichend genug sein - und sich auch nicht durch genauere Beschäftigung mit dem Produkt in Luft auflösen lassen.
Leo, es ist vom diesen Standpunkt aus egal ob NET oder NjET. Sobald man auch nur für Windows entwickelt, stärkt man in gewisser Weise Microsoft. Ob man dazu dann NET nimmt oder nicht, ist im Endeffekt egal. NET bringt einfach viele Vorteile wenn man für Windows entwickelt.

Wenn man aber plattformunabhängig entwickeln will, dann führt in den meisten Fällen kein Weg an Java vorbei. Bei NET könnte es in der zukunft so sein, daß man diese Pseudo-Binaries auf anderen Betriebssystemen ausführen kann. Darauf verlassen würde ich mich aber nicht. Das aktuelle NET-Framework enthält halt ziemlich viel Windows-only-Zeugs. Dieses müsste man für andere Betriebssysteme nachprogrammieren.

[StefanV]

... wenn ich ein klein wenig mehr Geld hätte, würde ich mit Erscheinen von WGF eine Initiative sponsoren, welche WGF (PS: Scheiss natürlich aufs Urheberrecht) auf Linux umsetzt.
Naja, aber ob du damit so viel erfolg hättest?!

DirectX könnte man auch auf Linux bringen, nur scheint die Linuxgemeinde das nicht zu wollen...

[Exxtreme]

Naja, aber ob du damit so viel erfolg hättest?!

DirectX könnte man auch auf Linux bringen, nur scheint die Linuxgemeinde das nicht zu wollen...
Um DirectX auf Linux zu bringen müsste man den ganzen COM-Schrott komplett nachprogrammieren. Und den Stress gibt sich einfach keiner. Ausserdem gibt es schon OpenGL, welches schon funktioniert.

[myMind]

...
Und du einzige substantielle Rechtfertigung dafür ist dass Microsoft für mehrere Sprachen .NET-Compiler anbietet. Ein "Zuckerl", das ihr wohl schon gefressen habt.

Bitte ruhig mal überlegen, ob es nicht noch andere Gründe für .NET gibt. Hier mal eine Auswahl:

- Bestehender Code (C++, C) kann weitaus einfacher wiederverwendet werden, als bei Java. Gleiches gilt für COM-Komponenten. Damit verbunden sind deutlich geringere Migrationskosten.
- Entwickler, die das Arbeiten mit Visual Studio gewöhnt sind, brauchen nicht umzulernen.
- Weitaus bessere Betriebssystem-Integration.
- Einfache MS-Office-Automation ist möglich.
- In der Regel geringerer Resourcenbedarf als Java (es sei denn man programmiert so dilettantisch wie beim ATi-Control-Center).
- Einfachere Anbindung von Hardware.
- Einige APIs sind fortgeschrittener als bei Java (beispieslweise WMI).
- Nützliche Sprachfeatures wie Attribute oder Properties stehen zur Verfügung und werden konsequent unterstützt.
- Das Versionierungsproblem ist gut gelöst.
- Für die meisten Nutzer gewohnte GUI-Elemente (MFC-like) stehen zur Verfügung. Für die Entwickler ist das zwar ein Fluch, aber naja.

... und wenn man wirklich will, fällt einem da noch eine ganze Menge ein.

Damit will ich keinesfalls sagen, dass ich .NET in jedem Falle Java vorziehen würde. Das Gegenteil ist der Fall. Ich würde tendenziell eher zur stabilen, platformunabhängigeren Java-Platform raten. Aber es hängt einfach vom Anwendungsfall ab, welche Platform für das zu lösende Problem am besten paßt.

[tb]

Das kann ich mir beim besten Willen nicht vorstellen. Allein der Nachteil "Microsoft" sollte ausreichend genug sein - und sich auch nicht durch genauere Beschäftigung mit dem Produkt in Luft auflösen lassen.

Das geht dann aber schon mehr in die Richtung "Microsoft Produkte vermeiden" und hat nichts mehr mit .Net zu tun.
Sicherlich stimme ich mit Microsoft's Politik nicht überein, aber allein das .Net (Mono) auch unter Linux lauffähig ist stimmt mich schon wieder positiv, es auch einzusetzen.

Thomas

[Exxtreme]

Sicherlich stimme ich mit Microsoft's Politik nicht überein, aber allein das .Net (Mono) auch unter Linux lauffähig ist stimmt mich schon wieder positiv, es auch einzusetzen.

Thomas
Naja, es ist einiges an Hickhack nötig damit die Programme überhaupt starten. MONO kennt das ganze windowsspezifische Zeugs wie WindowsForms etc. nicht. Entweder man weicht auf GTK# aus oder man begnügt sich mit Konsolenanwendungen. GTK# ist problematisch da es AFAIK keine GUI-Builder dafür gibt.

[zeckensack]

Bitte ruhig mal überlegen, ob es nicht noch andere Gründe für .NET gibt. Hier mal eine Auswahl:

- Bestehender Code (C++, C) kann weitaus einfacher wiederverwendet werden, als bei Java. <...>Das ist das "Zuckerl", was ich oben ansprach. Genehmigt.
Ein paar Gegenfragen habe ich dazu noch:
1)Liegt das an .NET? Sprich, ginge das Kompilieren verschiedener Sprachen nicht grundsätzlich auch mit anderen RTEs?
2)Da wir uns einig sind, dass die Antwort auf #1 "ja" lautet, gibt's dafür womöglich gute Gründe? Willst du wirklich C- und Visual Basic-Code auf eine durch und durch objektorientierte und typsichere RTE aufsetzen, selbst wenn du es könntest? Macht das Sinn?
3)Ich behaupte mal dass Java (syntaktisch, konzeptionell) nicht schwierig zu lernen ist, wenn man halbwegs Erfahrung mit C++ hat. Globale Variablen fallen weg, dafür erlaubt die Sprache aber adäquaten Ersatz (Konstruktoren ausführbarer Klassen ahoi). Referenzen und Zeiger sind austauschbar, wenn man einen GC hat (und Java hat den). Und das war's auch fast schon.
Gleiches gilt für COM-Komponenten. Damit verbunden sind deutlich geringere Migrationskosten.
- Entwickler, die das Arbeiten mit Visual Studio gewöhnt sind, brauchen nicht umzulernen.
- Einfache MS-Office-Automation ist möglich.
- Einige APIs sind fortgeschrittener als bei Java (beispieslweise WMI).
- Für die meisten Nutzer gewohnte GUI-Elemente (MFC-like) stehen zur Verfügung. Für die Entwickler ist das zwar ein Fluch, aber naja.Warum überrascht es mich nicht, dass Microsoft-Compiler führend sind, wenn es darum geht pure Microsoft-Features zu unterstützen, und so auszusehen wie Microsoft-Produkte? Sorry, aber das finde ich albern.

Kann man mit Visual Studio .NET etwa StarBasic-Kruscht schreiben, um StarOffice zu automatisieren? IMO höchst unwahrscheinlich, und ebensowenig überraschend wie relevant.

Wer so an Microsoft-Produkte "gewöhnt" ist, dass er es nicht mehr schafft sich auf neue IDEs einzustellen, dem rate ich die nächsten zehn Jahre bei MSVC6 zu bleiben. Vielleicht ist es auch ein Zeichen dafür, dass man so langsam zu alt wird für Software-Entwicklung. Ich glaube nicht, dass du zB Borland's aktuelle IDEs mal benutzt hast, sonst würdest du das wohl kaum als Argument anbringen.

WMI ... omg.

Und neulich habe ich in Swing Listboxen, Edit-Boxen, Check-Boxen, Buttons, Radio-Buttons, Labels, beschriftete Rahmen uvam gesehen.
- Nützliche Sprachfeatures wie Attribute oder Properties stehen zur Verfügung und werden konsequent unterstützt.Syntaktischer Zucker. Ich kann dir garantieren dass die Runtime davon Null Ahnung hat. Dafür kann man sich auch Makros schreiben, wenn man sowas meint zu brauchen.
Ähm ... und "reflection".
- Das Versionierungsproblem ist gut gelöst.KA. Inwiefern? Insofern dass man für das CCC eigentlich nur .NET1 SPxy braucht, aber bei Problemen .NET2 beta helfen kann?
- Weitaus bessere Betriebssystem-Integration.Nullaussage. Mit dem Betriebssystem will ich garnicht integriert werden. Je sinnvoller sich eine GUI-API verhält, desto weiter muss sie Win32 vor dem Anwender verstecken.

So ein ähnliches Argument habe ich mal in Punkto DirectX Graphics gehört. Und letztlich läuft's darauf hinaus, dass DXG nicht besser mit dem System integriert ist, sondern im Gegenteil einfach an Win32 vorbei konstruiert wurde, den ganzen "Welchem Thread gehört welches Fenseter"-Blödsinn nicht nutzt, sondern komplett abschaltet.

Überraschung: Diesen Luxus der nur von gewissen APIs nutzbaren System-Idiotie-Umschiffung hat natürlich nur Microsoft selbst.
- In der Regel geringerer Resourcenbedarf als Java (es sei denn man programmiert so dilettantisch wie beim ATi-Control-Center).KA.
- Einfachere Anbindung von Hardware.Managed Code im Kernel-Modus, ja?
Aber vielleicht denke ich an die falsche Sorte "Hardware". Grafik? Musik? Eingabegeräte?
Mit "JNI" kannst du dich btw voll austoben, wenn du irgendwas extrem plattformspezifisches brauchst. Wenigstens ist der Mechanismus frei verfügbar, und man muss nicht erst darauf warten, dass Microsoft irgenwelche (natürlich nativen) Libs schreibt, um irgendwas machen zu können.

[tb]

Naja, es ist einiges an Hickhack nötig damit die Programme überhaupt starten. MONO kennt das ganze windowsspezifische Zeugs wie WindowsForms etc. nicht. Entweder man weicht auf GTK# aus oder man begnügt sich mit Konsolenanwendungen. GTK# ist problematisch da es AFAIK keine GUI-Builder dafür gibt.

Bis es nen GTK# Builder gibt, oder besser etwas XAML ähnliches für Mono + GUI Builder, kann man sich auch so helfen:

http://bdn.borland.com/article/0,1410,32073,00.html

Hier mal was zum Thema GUI....
http://usefulinc.com/edd/blog/2004/3/3#11:21

Thomas

[Andre]

Das kann ich mir beim besten Willen nicht vorstellen. Allein der Nachteil "Microsoft" sollte ausreichend genug sein - und sich auch nicht durch genauere Beschäftigung mit dem Produkt in Luft auflösen lassen.

Wie verbohrt muss man eigentlich sein, um bewusst und nur aus persönlicher Abneigung heraus alle Argumente für NET einfach ignorieren zu können? Selten so eine Sturheit gesehen.

[aths]

Wie verbohrt muss man eigentlich sein, um bewusst und nur aus persönlicher Abneigung heraus alle Argumente für NET einfach ignorieren zu können? Selten so eine Sturheit gesehen.Ganz unbegründet ist Leos Aversion imo nicht. Wenn ich mich recht entsinne, kam MS weiland auf die Idee, Java um Windows-spezifische Funktionen zu erweitern, um es inkompatibel zu machen. Sun wurde sauer und bewirkte dass MS das nicht tut. Aus Verbitterung versuchte MS dann, Java mit neueren Windows-Versionen gar nicht mehr zu unterstützen, was sie natürlich aufgegeben haben.

[myMind]

<Wiederverwendbarkeit alten Codes>
Das ist das "Zuckerl", was ich oben ansprach. Genehmigt.
Ein paar Gegenfragen habe ich dazu noch:
1)Liegt das an .NET? Sprich, ginge das Kompilieren verschiedener Sprachen nicht grundsätzlich auch mit anderen RTEs?

Möglicherweise. Dazu müsste an einigen vielen Stellen gebastelt werden. In .NET steht einiges an Instrumentarium bereit, damit man mit einem gekapselten unmanaged Bereich umgehen kann. Ich kann mir nicht vorstellen, dass man das noch nachträglich in eine bestehende Sprache mit bestehendem Zwischencode vernünftig hineingefrickelt bekommt. Machbar theoretisch vielleicht ja, aber wohl kaum mit vertretbarem Aufwand.

<Mehrsprachigkeit, Wiederverwendbarkeit>
2)Da wir uns einig sind, dass die Antwort auf #1 "ja" lautet, gibt's dafür womöglich gute Gründe? Willst du wirklich C- und Visual Basic-Code auf eine durch und durch objektorientierte und typsichere RTE aufsetzen, selbst wenn du es könntest? Macht das Sinn?

Ja, da man in kaum einem Unternehmen auf der grünen Wiese anfangen kann. Das man mit .NET bestehendes relativ einfach weiterentwickeln und weiterverwenden kann ist ein sehr starkes (Kosten-)Argument.

3)Ich behaupte mal dass Java (syntaktisch, konzeptionell) nicht schwierig zu lernen ist, wenn man halbwegs Erfahrung mit C++ hat. Globale Variablen fallen weg, dafür erlaubt die Sprache aber adäquaten Ersatz (Konstruktoren ausführbarer Klassen ahoi). Referenzen und Zeiger sind austauschbar, wenn man einen GC hat (und Java hat den). Und das war's auch fast schon.

Das gleiche gilt für C#. Der Unterschied zu Java ist minimal. Der Aufwand beim Lernen liegt hauptsächlich im Verstehen der riesigen Bibliotheken. Und die sind durchaus unterschiedlich zwischen C++, Java und C#.

<Bessere MS-Produktintegration, Office, Windows. Gleiche GUI wie C++/MFC.>
Warum überrascht es mich nicht, dass Microsoft-Compiler führend sind, wenn es darum geht pure Microsoft-Features zu unterstützen, und so auszusehen wie Microsoft-Produkte? Sorry, aber das finde ich albern.

Es ist ein Argument dafür, ob es einem gefällt oder nicht. Gleiches gilt auf der anderen Seite natürlich auch. Will man beispielsweise ein Programm komfortabel an eine Oracle-Datenbank anbinden, ist Java klar zu bevorzugen. Warum sollte man so ein Argument plötzlich für MS nicht zulassen?

Kann man mit Visual Studio .NET etwa StarBasic-Kruscht schreiben, um StarOffice zu automatisieren? IMO höchst unwahrscheinlich, und ebensowenig überraschend wie relevant.

Praktisch jedes größere Unternehmen automatisiert in irgendeiner Form die MS-Office-Anwendungen. Wenn das mit .NET einfacher, dann ist das ein Pluspunkt für die Sprache.

Wer so an Microsoft-Produkte "gewöhnt" ist, dass er es nicht mehr schafft sich auf neue IDEs einzustellen, dem rate ich die nächsten zehn Jahre bei MSVC6 zu bleiben. Vielleicht ist es auch ein Zeichen dafür, dass man so langsam zu alt wird für Software-Entwicklung. Ich glaube nicht, dass du zB Borland's aktuelle IDEs mal benutzt hast, sonst würdest du das wohl kaum als Argument anbringen.

Ich habe nicht behauptet, dass man sich nicht umstellen kann. Die Frage ist vielmehr wer die Umstellung bezahlen soll.
Es ist zudem weit einfacher, mit MSVC6 und den neueren Versionen des Studios parallel zu Entwickeln (alte Software will auch gepflegt werden), als gleichzeitig mit JBuilder und MSVC6 zu arbeiten.
Davon mal abgesehen, finde ich Borlands Produktpolitik beim JBuilder zum k...en. Alle paar Monate darf man - wenn es nach Borland ginge - für eine neue Version löhnen. Aber das nur nebenbei.

<Zusätzliche Sprachfeatures die es in Java (noch) nicht gibt oder erst spät eingeführt wurden.>
Syntaktischer Zucker. Ich kann dir garantieren dass die Runtime davon Null Ahnung hat. Dafür kann man sich auch Makros schreiben, wenn man sowas meint zu brauchen.

Attribute können zur Laufzeit ausgewertet werden. Beispielsweise lässt sich mit einem Attribut deklarieren welche Berechtigungen ein Programm benötigt. Das Programm selbst und die Laufzeitumgebung können diese Information auswerten.

<Versionierung>
KA. Inwiefern? Insofern dass man für das CCC eigentlich nur .NET1 SPxy braucht, aber bei Problemen .NET2 beta helfen kann?

Ich meinte die in .NET verfügbare Versionierungsunterstützung mit strong named Assemblies.

Nullaussage. Mit dem Betriebssystem will ich garnicht integriert werden. Je sinnvoller sich eine GUI-API verhält, desto weiter muss sie Win32 vor dem Anwender verstecken.

War vielleicht etwas missverständlich. Gemeint war, dass möglichst alle Mittel, die das Betriebssystem zur Verfügung stellt, auch unter der Platform in gut nutzbarer Weise zur Verfügung stehen sollten. Und hier ist .NET in vielen Bereichen heute schon weiter als Java. Wie lange hat Java gebraucht um beispielsweise Audio oder 3D-Grafik halbwegs brauchbar verfügbar zu machen? Oder Drucken mit Java -> Horror! 3 (oder 4) API-Varianten über die Zeit und eine mieser als die nächste. Das geht mit .NET relativ schmerzlos.

<Hardware>
Managed Code im Kernel-Modus, ja?
Aber vielleicht denke ich an die falsche Sorte "Hardware". Grafik? Musik? Eingabegeräte?
Mit "JNI" kannst du dich btw voll austoben, wenn du irgendwas extrem plattformspezifisches brauchst. Wenigstens ist der Mechanismus frei verfügbar, und man muss nicht erst darauf warten, dass Microsoft irgenwelche (natürlich nativen) Libs schreibt, um irgendwas machen zu können.

Wieso sollte man auf MS warten müssen? JNI kommt nicht einmal näherungsweise an das heran, was Microsoft anbietet, um selbst nativen C oder C++-Code einbinden zu können. Einfache Anwendungsfälle wie z.B. das Einbinden von COM-Komponenten oder das Aufrufen klassischer Bibliotheksfunktionen (Win32) funktionert ziemlich schmerzlos.

Ich möchte noch einmal betonen, dass meine Meinung zu dem Thema ist, dass man die Platform einsetzen sollte, die den meisten Nutzen bei möglichst geringem Aufwand bietet.

Es gibt auch bei .NET viele viele Schwachstellen. Angefangen beim verhältnismäßig schlechten Komponentendesign der Windows Forms bis hin zum nicht exisierenden Anwendungs- und alten Datenbankserver. Da wird wohl noch viel Wasser den Yukon runterfließen, bis man mit .NET auch Serverseitig was machen kann. Auf dem Desktop ist es meiner Meinung nach oft eher geeignet als Java.

Wenn man diesen Thread mal quer liest, sieht man, das im Grunde alle Bedenken gegen .NET entweder auf Unwissenheit oder auf Mistrauen gegenüber Microsoft beruhen. Ich kann das aufgrund Microsofts Ruf gut verstehen und auch nachvollziehen. Das es jedoch kaum fachliche Gegenargumente gegen .NET gibt, sagt einiges aus.

Daneben ist es doch ziemlich sonderlich, wenn man ein Betriebssystem von der Firma für teuer Geld kauft und sich dann anschliessend gegen eine kostenlose Erweiterungskomponente wehrt.
Das ist so ähnlich wie die Geschichte mit den alseits "beliebten" Bonussystemen (Payback etc.). Wenn man sich dagegen wehren möchte, darf man halt in den Geschäften nicht kaufen, die so etwas machen. Das verweigern der Boni bringt goa nix.

[zeckensack]

Möglicherweise. Dazu müsste an einigen vielen Stellen gebastelt werden. In .NET steht einiges an Instrumentarium bereit, damit man mit einem gekapselten unmanaged Bereich umgehen kann. Ich kann mir nicht vorstellen, dass man das noch nachträglich in eine bestehende Sprache mit bestehendem Zwischencode vernünftig hineingefrickelt bekommt. Machbar theoretisch vielleicht ja, aber wohl kaum mit vertretbarem Aufwand.Borland's nächste Delphi-Version wird .NET-Code erzeugen (http://www.borland.com/delphi/). C ist IMO bedeutend schwieriger, ja, aber diese Runtimes führen Bytecode aus. Wie der Bytecode erzeugt wurde, ist irrelevant. Bei .NET hast du momentan mehr Optionen.

Vielleicht gibt's auch einfach keinen Bedarf für VB => Java Bytecode-Compiler. Völlig andere Zielgruppen ...
Ja, da man in kaum einem Unternehmen auf der grünen Wiese anfangen kann. Das man mit .NET bestehendes relativ einfach weiterentwickeln und weiterverwenden kann ist ein sehr starkes (Kosten-)Argument.Ich verstehe den Nutzen nicht.
Wenn ich C-Code weiterverwenden will, warum sollte ich nicht einen nativen (C-)Compiler dafür nehmen, sondern einen .NET-Compiler?
In Bezug auf eine halbwegs moderne RTE, die ja unter anderem den Programmierer und das System davor schützen soll, sich in den Fuß zu schießen, sehe ich konsequente Unterstützung von C-Code eher als "Sand im Getriebe".
Es ist auf der einen Seite nett dass Microsoft sich die Mühe gibt, Unterstützung für C-Code in .NET hineinzubasteln. Auf der anderen Seite ist es falsch, und überflüssig. Für sowas muss eine RTE Kompromisse eingehen. Wenn diese Kompromisse auch auf der Seite der "sichereren" Kernsprachen wie C# zu Abstrichen führen, dann kann ich das nicht gut finden.

Und selbst wenn nicht, wenn ich C-Code habe, stehen die Chancen gut dass ich auch einen C-Compiler habe.
Das gleiche gilt für C#. Der Unterschied zu Java ist minimal. Der Aufwand beim Lernen liegt hauptsächlich im Verstehen der riesigen Bibliotheken. Und die sind durchaus unterschiedlich zwischen C++, Java und C#.Gaynau. Umlernen muss man sowohl für C# als auch für Java.
Für C++ muss man nicht umlernen. Es will mir aber auch kein schlagendes Argument einfallen, warum ich C++ nicht gleich in nativen Code kompilieren sollte.
Es ist ein Argument dafür, ob es einem gefällt oder nicht. Gleiches gilt auf der anderen Seite natürlich auch. Will man beispielsweise ein Programm komfortabel an eine Oracle-Datenbank anbinden, ist Java klar zu bevorzugen. Warum sollte man so ein Argument plötzlich für MS nicht zulassen?Solchen Argumenten sollte man IMO generell kritisch gegenüber stehen.
Es sollte einem Entwickler bewußt sein, dass er sich durch Plattformentscheidungen in solche Abhängigkeiten begeben kann. Und das ist zu evaluieren bevor es "zu spät" ist. Sowohl bei Microsoft als auch bei Oracle, und natürlich auch bei der Firma Sun. Der Unterschied ist dass Abhängigkeit von Oracle und/oder Microsoft Geld kostet. Abhängigkeit von Java ist völlig kostenfrei.
Praktisch jedes größere Unternehmen automatisiert in irgendeiner Form die MS-Office-Anwendungen. Wenn das mit .NET einfacher, dann ist das ein Pluspunkt für die Sprache.Abhängigkeit durch Gewöhnung und Weigerung umzulernen also.

Kurioserweise stehst nicht nur du auf dem Standpunkt dass die Welt ja sowieso Microsoft-Produkte benutzt und beherrscht, hier also keine Kosten auftreten. Microsoft selbst sagt das auch. Schulungskosten für Nutzer und Administratoren werden in offiziellen Produktvergleichen im Autrag dieses Hauses auch immer mit "Null" angesetzt, wenn es sich um ein Microsoft-Produkt dreht. Solltest du mal drüber nachdenken. Wer sowas glaubt, wurde schlicht und ergreifend erfolgreich verarscht. Wer sowas auch noch unreflektiert weiterverbreitet, gehört gewatscht.

Stellst du auch die Kosten in Frage, die Microsoft Office verursacht, einerseits direkt durch Lizenzen, andererseits indirekt durch Lernaufwand ... und Mängel?
Dass der Einsatz von MS Office "wenn es darauf ankommt" ein großes Risiko ist, ist IMO ausreichend dokumentiert. Das Stichwort "Makro-Virus" sollte IMO mal erwähnt werden. Mir selbst sind reichlich Fälle von Studenten bekannt, die zB eine Hausarbeit -- gerne auch mal die Diplomarbeit -- im Datennirvana verloren haben. Oder ein Vereinsvorstand, der seine gesamte EMail-Korrspondenz in den unendlichen Weiten von Access verloren hat. Aber du musst mir das nicht glauben. Auch die c't hat über die Jahre immer wieder haarsträubende Mängel dokumentiert. Und trotzdem steht MS Office heute, irgendwie, warum auch immer, als "Industriestandard" da.

Erst evaluieren, dann einschießen! Sich später hinzustellen und zu behaupten dass man es nicht mehr ändern kann, ist mir zu schwach.
Ich habe nicht behauptet, dass man sich nicht umstellen kann. Die Frage ist vielmehr wer die Umstellung bezahlen soll.
Es ist zudem weit einfacher, mit MSVC6 und den neueren Versionen des Studios parallel zu Entwickeln (alte Software will auch gepflegt werden), als gleichzeitig mit JBuilder und MSVC6 zu arbeiten.Alle modernen IDEs sehen gleich aus, und funktionieren gleich.
Du hast "Projekte", abstrakte hierarchische Container in die du Dateien einfügen kannst. Das findet man "links". Protokolle, Compiler-Fehler etc findet man "unten". Der restliche Bildbereich wird von einem Editor ausgefüllt, entweder als Text oder spezialisiert für Ressourcen, Icons, etc, je nachdem was für eine Datei man gerade editiert.

Wer mit diesem grundlegenden Prinzip erstmal vertraut ist, hat es sehr sehr einfach sich auf eine beliebige aktuelle IDE einzustellen.

Du tust wieder so, als ob jeder MSVS kennt und nutzt. Aber auch das muss man lernen, wenn man sich damit das erste mal befasst.
Viele Studenten und Neulinge arbeiten eben nicht mit MSVS, sondern zB mit DevCPP, oder mit SunOne Studio, weil das nichts kostet und auch funktioniert. Rechnest du dort auch Schulungskosten an, wenn diese Personen (die durchaus das Programmierhandwerk auf diese Weise erlernen können, btw) mit MSVS konfrontiert werden?
Davon mal abgesehen, finde ich Borlands Produktpolitik beim JBuilder zum k...en. Alle paar Monate darf man - wenn es nach Borland ginge - für eine neue Version löhnen. Aber das nur nebenbei.Das mag stimmen, wenn du die "Enterprise"-Version haben willst. Die kostenfreie Schiene bei Borland wird aber momentan bestens gepflegt.
Während du früher, ohne Geld zu bezahlen, von Borland "nur" den nackten (Kommandozeilen-)Compiler von C++ Builder 5.5 bekamst, bekommst du heute ein komplette Delphi-IDE ("Personal edition"), oder eben JBuilderX "Foundation edition". Letzteres ist auch nicht irgendein billiger Abfall, sondern durchaus mächtig. GUI-Designer, Refactoring, "live"-Kompilation mit sofortiger Fehler-Anzeige ("unten links"), automatische Backup-History inklusive "roll back", "code completion", "wizards", etc.

Das alte MSVS6 ist schonmal ein Scheiss dagegen. MSVS .NET hat auch noch Aufholarbeit zu leisten.

Wie gesagt, IMO würdest du das nicht sagen, wenn du's dir mal angesehen hättest. Das Ding kann echt viel.
Attribute können zur Laufzeit ausgewertet werden. Beispielsweise lässt sich mit einem Attribut deklarieren welche Berechtigungen ein Programm benötigt. Das Programm selbst und die Laufzeitumgebung können diese Information auswerten.Ok. Das geht dann doch eher in Richtung von Java's "Manifest".
Ich meinte die in .NET verfügbare Versionierungsunterstützung mit strong named Assemblies.Regel #4:
Verteile Code der nicht das tut was er soll nicht an deine Kunden.
Regel #17:
Eine Klasse die ein verändertes äußeres Verhalten hat, ist eine neue Klasse, und ist mit einem neuen Namen zu versehen.

"Designkompetenz" hatte ich IMO bereits erwähnt.
War vielleicht etwas missverständlich. Gemeint war, dass möglichst alle Mittel, die das Betriebssystem zur Verfügung stellt, auch unter der Platform in gut nutzbarer Weise zur Verfügung stehen sollten. Und hier ist .NET in vielen Bereichen heute schon weiter als Java. Wie lange hat Java gebraucht um beispielsweise Audio oder 3D-Grafik halbwegs brauchbar verfügbar zu machen?Keine Ahnung. Funktioniert aber nicht erst seit gestern. Da wird .NET noch eine Absichtserklärung gewesen sein, oder?
Oder Drucken mit Java -> Horror! 3 (oder 4) API-Varianten über die Zeit und eine mieser als die nächste. Das geht mit .NET relativ schmerzlos.Weiss ich nicht. Ich drucke nicht, sondern beschränke mich auf die Anzeigefähigkeiten meines Monitors :redface:
Wieso sollte man auf MS warten müssen? JNI kommt nicht einmal näherungsweise an das heran, was Microsoft anbietet, um selbst nativen C oder C++-Code einbinden zu können. Einfache Anwendungsfälle wie z.B. das Einbinden von COM-Komponenten oder das Aufrufen klassischer Bibliotheksfunktionen (Win32) funktionert ziemlich schmerzlos.JNI kommt an was nicht ran bitte? Mit JNI kannst du machen was du willst. Die Maschine neu booten, die Platte formatieren (Admin-Rechte erforderlich), oder .NET-Code ausführen, egal. Geht alles.

Und natürlich musst du auf irgendwen warten, der dir die "Bindings" für die API oder Plattform deines Begehrens baut. Das ist bei VB so, das ist bei Java so, das ist bei managed C# so.
Oder kannst du dir in diesen Sprachen Funktionszeiger direkt aus DLLs angeln, und benutzen? Wenn du das nicht kannst, hier die Preisfrage: kann man dann "Bindings" direkt in diesen Sprachen schreiben, oder denkst du nicht dass dafür evtl Code in einer maschinennäheren Sprache erforderlich ist?

Und nur so nebenher, 99% dieser Problemchen existieren auf Unices nicht, weil man dort einfach über das Dateisystem an die meisten Geräte drankommt. Was haben wir gelacht, als Microsoft den Kernel anpassen musste, um USB2.0 zu unterstützen.
Ich möchte noch einmal betonen, dass meine Meinung zu dem Thema ist, dass man die Platform einsetzen sollte, die den meisten Nutzen bei möglichst geringem Aufwand bietet.Und Risiken bitte nicht vergessen.
Wenn man diesen Thread mal quer liest, sieht man, das im Grunde alle Bedenken gegen .NET entweder auf Unwissenheit oder auf Mistrauen gegenüber Microsoft beruhen. Ich kann das aufgrund Microsofts Ruf gut verstehen und auch nachvollziehen. Das es jedoch kaum fachliche Gegenargumente gegen .NET gibt, sagt einiges aus.Nochmal:
.NET ist überflüssig.
.NET ist schlecht designt.
.NET kommt von einer Firma, die bisher noch nichts auf Anhieb schaffte, und idR fünf bis zehn Anläufe, Technologiezukäufe und API-"Neuanfänge" brauchte.
.NET schädigt das Ökosystem "PC".

Daneben ist es doch ziemlich sonderlich, wenn man ein Betriebssystem von der Firma für teuer Geld kauft und sich dann anschliessend gegen eine kostenlose Erweiterungskomponente wehrt.
Das ist so ähnlich wie die Geschichte mit den alseits "beliebten" Bonussystemen (Payback etc.). Wenn man sich dagegen wehren möchte, darf man halt in den Geschäften nicht kaufen, die so etwas machen. Das verweigern der Boni bringt goa nix.Und ich will dir auch noch zwei Dinge erzählen ...
1)Du kannst als Entwickler nichts tun was keine politische Dimension hat. Deswegen Augen auf beim Eierkauf, und währet den Anfängen. Sonst stehst du in zehn Jahren da, bist auf .NET angewiesen, und musst dann behaupten dass du das damals ja nicht hättest ahnen können.

2)Die Argumentation ist sowas von Quark. Wenn du in den Supermarkt gehst um Eier zu kaufen, sagst du dir bestimmt auch "Ach, jetzt kaufe ich sowieso schon hier ein. Ich konnte nicht widerstehen. Meine Niederlage ist damit komplett. Dann nehme ich auch noch zehn Liter Absinth mit, für heute Abend". Oder wenn dich jemand nachts am Bahnhof fragt "Brauchst du irgendwas?" antwortest du mit "Ja, klar, warum nicht, bin ja sowieso schon hier". Oder oder oder. Oder doch eher nicht?

Du musst nicht alles mitmachen, nur weil du "in der Nähe" bist. .NET ist Opium für Entwickler, und Drogen sind nicht gut für dich.

[Demirug]

Zeckensack, darf ich mal fragen wie weit du dich wirklich mit dem "Feind" beschäftigt hast?

Ich sehe da bei dir teilweise doch grössere Lücken was den Funktionsumfang von .Net und den Tools dazu angeht. OK, dem aktuelle VS.Net fehlen im Enterprise Bereich wirklich noch ein paar Dinge die Betas der nächsten Version sehen da aber vielversprechend aus. Ich sehe nur schon wieder einige schreien das MS den Markt für Zusatztools für das VS-Net kaputt macht.

Oder kannst du dir in diesen Sprachen Funktionszeiger direkt aus DLLs angeln, und benutzen?

Mit C# mache ich das öfter mal wenn ich auf eine vorhandene C-Funktion bzw Com-Object zugreifen will. Geht dank interop und Attribute ganz einfach. Diese Attribute sind übrigens nichts mit dem JAVA Manifest zu tun. Ein solches Manifest gibt es bei .Net auch.

Der .net fähige C++ Compiler ist eine Speziallösung um die schrittweise Portierung zu errleichert bzw um hochperformate Wrapper für Interop zu schreiben. In Verbindung mit WinFX ist er auch noch dazu da das die ganzen armen Entwickler keine neue Sprache lernen müssen wenn sie dafür geistig schon zu träge sind.

Eine Frage hätte ich noch. Warum ist .Net überflüssig? Weil es JAVA gibt? Ich dachte immer Konkurrenz belebt den Fortschritt und die Entwicklung.

[Exxtreme]

Ich habe nicht behauptet, dass man sich nicht umstellen kann. Die Frage ist vielmehr wer die Umstellung bezahlen soll.
Es ist zudem weit einfacher, mit MSVC6 und den neueren Versionen des Studios parallel zu Entwickeln (alte Software will auch gepflegt werden), als gleichzeitig mit JBuilder und MSVC6 zu arbeiten.
Eine kleine Vorbehaltsklausel... :D

Ich kenne MSVC6 und die neue Beta von MSVC2005 und IMHO haben beide IDEs kaum was gemeinsam. MSVC2005 ist eher ein verkappter C++-Builder und zwar in Hinblick auf Bedienung als auch Klassenbibliotheken. :) MSVC6 benutzt IIRC immer noch die MFC und diese sind gaaanz anders als die neuen .NET-Bibliotheken. Die neuen Klassenbibliotheken sind Borlands VCL sehr ähnlich. Ist ja auch kein Wunder denn MS hat von Borland Personal abgeworben.

Die Umschulungskosten fallen also genauso an als ob man auf den JBuilderX umsteigen würde.

[zeckensack]

Zeckensack, darf ich mal fragen wie weit du dich wirklich mit dem "Feind" beschäftigt hast?Offenbar noch zu wenig.
(Funktionszeiger holen und benutzen)

Mit C# mache ich das öfter mal wenn ich auf eine vorhandene C-Funktion bzw Com-Object zugreifen will. Geht dank interop und Attribute ganz einfach.Dann sortieren wird das doch gleich unter Designsünden ein:
GetProcAddress hat den Rückgabetyp void*. Unter C/C++ darf ich mir in den Fuß schießen, also kann ich aus einem void* machen was ich will.void (__cdecl *crash)(void);

crash=(void (__cdecl*)(void))1117;
crash();

Wenn ich mir auch weiterhin in den Fuß schießen können will, dann brauche ich die Sprache nicht zu wechseln. Es sein denn man "zwingt" mich zu einem Umstieg, indem man mir neue Bibliotheken, die ich unbedingt benutzen möchte, nicht mehr für C++ anbietet, obwohl man es könnte.

Ad COM: Microsoft schreibt selbst (http://msdn.microsoft.com/msdnmag/issues/01/08/interop/default.aspx) dass COM nicht "einfach so" funktioniert, sondern "The .NET Framework has made provisions for this interaction by implementing various wrappers for COM objects".
Also was denn nun?

Mir ist klar dass COM per se einen Mechanismus eingebaut hat, um Elemente einer Klasse zu enumerieren und abzufragen. Das macht das Wrappen von COM-Klassen natürlich leichter, aber eben nicht nur für .NET, sondern auch für andere Sprachen.
Diese Attribute sind übrigens nichts mit dem JAVA Manifest zu tun. Ein solches Manifest gibt es bei .Net auch.Die Nummer mit dem Manifest war auf die Rechtebeschränkung gemünzt.
Eigentlich verstand ich die Attribute (als ich die erste Antwort auf myMind gab) als rein syntaktischen Ersatz für getter/setter-Methoden, so wie man das aus anderen Sprachen kennt. "Properties" in C++ (die ich btw ganz und gar grauenhaft finde). Aber ich gab ja quasi noch nebenher die richtige Antwort: ein Pendant zu Reflections (http://java.sun.com/docs/books/tutorial/reflect/).

Was genau ein .NET-Attribut ist, wird mir jetzt nach deiner Antwort allerdings erst recht unklar. Ich habe natürlich gegoogelt. Wenn ich das gelesene recht verstanden habe, dann sind .NET-Attribute irgendein Zwischending aus "qualifiers" und einer Klassenhierarchiedeklaration. Java:class
SelectionCellRenderer
extends JLabel //Attribut?
implements ListCellRenderer //Attribut?
{
<...>
};Besonders amüsant fand ich btw das Attribut "Serializable".
Was mir allerdings nach wie vor absolut unklar ist, ist wie man damit Typsicherheit umgehen kann.
Der .net fähige C++ Compiler ist eine Speziallösung um die schrittweise Portierung zu errleichert bzw um hochperformate Wrapper für Interop zu schreiben. In Verbindung mit WinFX ist er auch noch dazu da das die ganzen armen Entwickler keine neue Sprache lernen müssen wenn sie dafür geistig schon zu träge sind.Also ein Werkzeug um .NET-Bytecode und nativen Code beliebig mischen zu können. Ich sag's nochmal: JNI.
Nur dass JNI nicht so tut als ob das alles ein Bündel Java-Code wäre. Es gibt eine klare Trennung zwischen Bytecode und nativem Code, über diese Trennung hinweg wird nur mit streng definierten Typen hantiert. So macht man das, wenn man es richtig machen will.

Dass .NET Bytecode und nativen Code zusammen in eine exe bündelt, finde ich grauenhaft. Wenn man natürlich "Programmierer" bedienen möchte, die nicht in der Lage sind DLLs uä zu erzeugen, dann gibt es wohl keinen anderen Weg. Ich habe aber lieber, wenn ich schon einen solch drastischen Schritt im Entwicklungs- und "Deployment"-modell vollziehen soll, eine "saubere" Plattform, die nicht durch solche Kompromisse verwässert wird.
Eine Frage hätte ich noch. Warum ist .Net überflüssig? Weil es JAVA gibt? Ich dachte immer Konkurrenz belebt den Fortschritt und die Entwicklung..NET per se macht nichts besser als die Java-Runtime per se. Und technologische Unfälle gehören in die Versenkung.

.NET wird -- bei seinem Erzeuger nicht ungewöhnlich -- nur durch die drumherumgebaute Dekoration attraktiv.
Umgebungen, Tools, Libs, Wrapper, und sonstige Stöpsel die in externen Code passen.
Microsoft hätte einen Großteil dieser Toolchain auch für Java schreiben können, wenn das einzige Interesse gewesen wäre, unabhängig von einer bestimmten ISA zu werden, und die Entwicklung für Windows leichter zu machen. Das mit dem C-Code hätte wohl weniger geklappt, okay, das ist aber auch gut so.
Haben sie aber nicht.

Stattdessen haben sie -- auch nicht ungewöhnlich für den Erzeuger -- was eigenes aus dem Boden gestampft, das für ein paar vordergründige Zuckerli das Klassenziel und Potential des gesamten Designansatzes "interpretierter typsicherer objektorientierter Bytecode" über Bord schmeißt.

Halbrhetorische Gegenfrage zur Verdeutlichung:
Was ist .NET, und was hätte .NET sein können?
De facto ist .NET ein Haufen neuer Werkzeuge und neuer Libs, die dich aber nirgendwo hinführen können, wo du nicht auch ohne .NET hingekommen wärst. .NET ist so prozessorunabhängig wie x86-Assembler. Es ist so OS-unabhängig wie die Win32-API. Es schützt dich vor Fußschüssen wie C++. Es schützt dich vor Deployment-Unfällen wie DLLs. Nämlich garnicht.

Für diese Ziele muss man nämlich einen konsequenten, glatten Schnitt machen, der nativen Code ausgrenzt. Und .NET macht diesen Schnitt nicht.
Bei JNI weiss ich zumindest jederzeit ganz exakt welchen Code ich bei einem ISA-Wechsel anzupassen habe. Ist ein eigenes Modul, wird von einem anderen Compiler übersetzt, und erzeugt eine separate Datei.

De facto ist .NET noch eine neue API mit der man auf eine völlig neue Art unter Windows Dialoge zaubern, Dateien löschen, und SQL-Anfragen absetzen kann. Und das finde ich überflüssig. Es gibt mindestens zwanzig andere Lösungen für diese Problemklasse.

[Xmas]

Sowohl bei Microsoft als auch bei Oracle, und natürlich auch bei der Firma Sun. Der Unterschied ist dass Abhängigkeit von Oracle und/oder Microsoft Geld kostet. Abhängigkeit von Java ist völlig kostenfrei.
Inwiefern ist das .NET RTE weniger kostenfrei als das Java RTE? Oder tust du jetzt das was du oben bei aths angeprangert hast und verwechselst IDE mit Runtime?

Regel #4:
Verteile Code der nicht das tut was er soll nicht an deine Kunden.
Regel #17:
Eine Klasse die ein verändertes äußeres Verhalten hat, ist eine neue Klasse, und ist mit einem neuen Namen zu versehen.
Ich muss also folglich davon ausgehen dass du bugfreie Software schreibst. Gratulation, das schaffen nur wenige...

Nochmal:
.NET ist überflüssig.
.NET ist schlecht designt.
.NET kommt von einer Firma, die bisher noch nichts auf Anhieb schaffte, und idR fünf bis zehn Anläufe, Technologiezukäufe und API-"Neuanfänge" brauchte.
.NET schädigt das Ökosystem "PC".
.NET ist in vielen Fällen ein gutes Werkzeug, und treibt auch die Entwicklung voran.
.NET ist nicht perfekt, hat einige Schwachstellen, ist aber trotzdem insgesamt durchdacht designt.
.NET schädigt das Ökosystem "PC" nicht.

Und ich will dir auch noch zwei Dinge erzählen ...
1)Du kannst als Entwickler nichts tun was keine politische Dimension hat. Deswegen Augen auf beim Eierkauf, und währet den Anfängen. Sonst stehst du in zehn Jahren da, bist auf .NET angewiesen, und musst dann behaupten dass du das damals ja nicht hättest ahnen können.
Wer sich für eine Plattform entscheidet, ist auf sie (oder einen Nachfolger mit Abwärtskompatibilität) angewiesen... das ist keine neue Erkenntnis. Wie leicht man am Ende der Lebenszeit auf eine neue Plattform migrieren kann, lässt sich kaum vorausahnen.

Du musst nicht alles mitmachen, nur weil du "in der Nähe" bist. .NET ist Opium für Entwickler, und Drogen sind nicht gut für dich.
Auf wieviele Plattformen kannst du diese Analogie wohl noch anwenden?

[Exxtreme]

Inwiefern ist das .NET RTE weniger kostenfrei als das Java RTE? Oder tust du jetzt das was du oben bei aths angeprangert hast und verwechselst IDE mit Runtime?
Ähem, .NET ist genauso "kostenlos" wie DirectX oder der WMP... du musst dir Windows kaufen um es halbwegs gescheit zu nutzen. Und Windows gibt's legal nicht für umsonst.

Das ist bei Java nicht der Fall.

[myMind]

Sorry, ich hab leider nicht die Zeit auf alles zu ausführlich zu Antworten. Aber ich versuche mal wenigstens die aus meiner Sicht falschen Aussagen zu kommentieren.

Offenbar noch zu wenig.
Dann sortieren wird das doch gleich unter Designsünden ein:
GetProcAddress hat den Rückgabetyp void*. Unter C/C++ darf ich mir in den Fuß schießen, also kann ich aus einem void* machen was ich will.void (__cdecl *crash)(void);

crash=(void (__cdecl*)(void))1117;
crash();

Wenn ich mir auch weiterhin in den Fuß schießen können will, dann brauche ich die Sprache nicht zu wechseln. Es sein denn man "zwingt" mich zu einem Umstieg, indem man mir neue Bibliotheken, die ich unbedingt benutzen möchte, nicht mehr für C++ anbietet, obwohl man es könnte.

Du kannst auf C++-Seite all das machen, was bisher auch ging. Der managed Bereich (C#, VB.NET etc.) ist davon sauberstens getrennt. Man hat das Beste aus zwei Welten. Will man die Fußangeln der C++-Programmierung umgehen, dann nehme man halt C#.

Ad COM: Microsoft schreibt selbst (http://msdn.microsoft.com/msdnmag/issues/01/08/interop/default.aspx) dass COM nicht "einfach so" funktioniert, sondern "The .NET Framework has made provisions for this interaction by implementing various wrappers for COM objects".
Also was denn nun?

Es gibt fertige Wrapper, die du benutzen kannst. Du kannst dir aber auch für beliebige - sauber programmierte - COM-Klassen durch die IDE automatisch einen Wrapper erzeugen lassen. Geht man bei COM ans eingemachte, dann muss man unter Umständen händisch nachhelfen. In der Regel funktioniert der Mechanismus aber erstaunlich gut.

Microsoft hat viel Arbeit in die Unterstützung bei der Umwandlung der Typen gesteckt, eines der Hauptprobleme beim Zusammenspiel verschiedener Sprachen.

Mir ist klar dass COM per se einen Mechanismus eingebaut hat, um Elemente einer Klasse zu enumerieren und abzufragen. Das macht das Wrappen von COM-Klassen natürlich leichter, aber eben nicht nur für .NET, sondern auch für andere Sprachen.

Nur muss man dort alles mühsam zu Fuß machen.

Die Nummer mit dem Manifest war auf die Rechtebeschränkung gemünzt.
Eigentlich verstand ich die Attribute (als ich die erste Antwort auf myMind gab) als rein syntaktischen Ersatz für getter/setter-Methoden, so wie man das aus anderen Sprachen kennt. "Properties" in C++ (die ich btw ganz und gar grauenhaft finde). Aber ich gab ja quasi noch nebenher die richtige Antwort: ein Pendant zu Reflections (http://java.sun.com/docs/books/tutorial/reflect/).

Was genau ein .NET-Attribut ist, wird mir jetzt nach deiner Antwort allerdings erst recht unklar. Ich habe natürlich gegoogelt. Wenn ich das gelesene recht verstanden habe, dann sind .NET-Attribute irgendein Zwischending aus "qualifiers" und einer Klassenhierarchiedeklaration. Java:class
SelectionCellRenderer
extends JLabel //Attribut?
implements ListCellRenderer //Attribut?
{
<...>
};Besonders amüsant fand ich btw das Attribut "Serializable".
Was mir allerdings nach wie vor absolut unklar ist, ist wie man damit Typsicherheit umgehen kann.

Nichts von obem aufgeführtem ist ein Attribut. In Java gibt es dies Konstrukt bisher nicht (bin mir nicht ganz sicher, ob mit 1.5 nicht etwas ähnliches eingeführt wurde).
Mit Attributen kann man bei einigen Sprachelementen (Membervariablen, Methoden, Properties etc.) die Deklaration um zusätzliche Informationen bereichern. Diese Informationen sind dann beliebig auswertbar.
Beispielsweise kannst du deklarieren, dass dein Code bestimmte Rechte benötigt (beispielsweise, weil er unmanaged Code einbindet). Die Laufzeit kann diese Information dann auswerten und darauf reagieren.
Oder du kannst beispielsweise deklarieren, welches Threadingmodell für über Wrapper eingebundene COM-Componenten benutzt werden soll. Die Anwendungsmöglichkeiten sind sehr umfangreich.

Also ein Werkzeug um .NET-Bytecode und nativen Code beliebig mischen zu können. Ich sag's nochmal: JNI.
Nur dass JNI nicht so tut als ob das alles ein Bündel Java-Code wäre. Es gibt eine klare Trennung zwischen Bytecode und nativem Code, über diese Trennung hinweg wird nur mit streng definierten Typen hantiert. So macht man das, wenn man es richtig machen will.

Und? Wie kommst du darauf, dass es bei .NET so eine saubere Trennung nicht gibt? Es gibt sie. Glaub es mir.

Dass .NET Bytecode und nativen Code zusammen in eine exe bündelt, finde ich grauenhaft.

Das gilt nur für unmanaged C++ gemischt mit managed C++. In der Runtime bleibt beides sauberstens getrennt.

Stattdessen haben sie -- auch nicht ungewöhnlich für den Erzeuger -- was eigenes aus dem Boden gestampft, das für ein paar vordergründige Zuckerli das Klassenziel und Potential des gesamten Designansatzes "interpretierter typsicherer objektorientierter Bytecode" über Bord schmeißt.

Das macht niemand.

Für diese Ziele muss man nämlich einen konsequenten, glatten Schnitt machen, der nativen Code ausgrenzt. Und .NET macht diesen Schnitt nicht.

Diese Aussage ist grundfalsch. Es gibt wohldefinierte Schnittstellen. Unmanaged-Code läuft aus Sicht des Managed-Codes in einer Sandbox.

Bei JNI weiss ich zumindest jederzeit ganz exakt welchen Code ich bei einem ISA-Wechsel anzupassen habe. Ist ein eigenes Modul, wird von einem anderen Compiler übersetzt, und erzeugt eine separate Datei.

Ist bei C++ mit managed Extensions nicht anders. Der C++-Compiler muss für gemischten managed/unmanaged-Code speziell angewiesen werden und er erzeugt eine separate DLL.

[myMind]

Ich verstehe den Nutzen nicht.
Wenn ich C-Code weiterverwenden will, warum sollte ich nicht einen nativen (C-)Compiler dafür nehmen, sondern einen .NET-Compiler?

Es geht idR darum C- oder C++-Bibliotheken oder COM-Komponenten in neuer .NET-Umgebung weiterzuverwenden.

Es will mir aber auch kein schlagendes Argument einfallen, warum ich C++ nicht gleich in nativen Code kompilieren sollte.

Hier liegt noch ein Verständnisproblem deinerseits. C++-Code wird immer nativ kompiliert. Jedoch können die mit den sog. "Managed-Extensions for C++" dekorierten Codeanteile von der .NET-Runtime verstanden und eingebunden werden.

Kurioserweise stehst nicht nur du auf dem Standpunkt dass die Welt ja sowieso Microsoft-Produkte benutzt und beherrscht, hier also keine Kosten auftreten.

Hab ich nie behauptet. Wie gesagt, es hängt vom Anwendungsfall ab. Wenn jemand schon MS-Office einsetzt und die Mitarbeiter auf MS-Office geschult sind, werde ich ihm kaum vorschlagen Java zur Automatisierung zu verwenden.

Microsoft selbst sagt das auch. Schulungskosten für Nutzer und Administratoren werden in offiziellen Produktvergleichen im Autrag dieses Hauses auch immer mit "Null" angesetzt, wenn es sich um ein Microsoft-Produkt dreht.

An diesem Entscheidungsprozess ist man als Entwickler wohl seltenst beteiligt. IdR wird MS-Office verwendet und Punkt.

Regel #4:
Verteile Code der nicht das tut was er soll nicht an deine Kunden.

LOL

Regel #17:
Eine Klasse die ein verändertes äußeres Verhalten hat, ist eine neue Klasse, und ist mit einem neuen Namen zu versehen.

Wo kommen denn diese lustigen Regeln her? Wenn jemand ständig die Dateien umbenennt und somit unter Umständen die Versionshistorie zerschiesst, den würde ich vierteilen.

Und natürlich musst du auf irgendwen warten, der dir die "Bindings" für die API oder Plattform deines Begehrens baut. Das ist bei VB so, das ist bei Java so, das ist bei managed C# so.
Oder kannst du dir in diesen Sprachen Funktionszeiger direkt aus DLLs angeln, und benutzen? Wenn du das nicht kannst, hier die Preisfrage: kann man dann "Bindings" direkt in diesen Sprachen schreiben, oder denkst du nicht dass dafür evtl Code in einer maschinennäheren Sprache erforderlich ist?


Ein Beispiel für den Import einer C++-Library-Funktion nach C#:
using System.Runtime.InteropServices;
[DllImport("user32.dll")]
public static extern int MessageBox(int hWnd, String text, String caption, uint type);

Jetzt kann man die Win32-Funktion "MessageBox" so benutzen, als wäre Sie in C# implementiert. Man beachte, dass die verwendeten Datentypen allesamt C#-Datentypen sind. Basisdatentypen werden automatisch konvertiert. Einfacher geht's nicht.
BTW: DllImport ist ein Attribut.

Und Risiken bitte nicht vergessen.
Nochmal:
.NET ist überflüssig.

Sehe ich nicht so. Java hat es nie wirklich auf den Desktop geschaft. .NET wird jetzt schon dort eingesetzt. Irren die sich deiner Meinung nach alle?

.NET ist schlecht designt.

Manche Teile ja. Andere nicht. In Java gab es auch schon etliche Redesigns: Drucken, AWT -> Swing, NIO etc.

.NET kommt von einer Firma, die bisher noch nichts auf Anhieb schaffte, und idR fünf bis zehn Anläufe, Technologiezukäufe und API-"Neuanfänge" brauchte.

Ich stimme in so weit zu, als das MS noch nie wirklich innovativ war. Auch .NET ist von der technischen Seite her im wesentlichen "zusammengeklaut".

Du musst nicht alles mitmachen, nur weil du "in der Nähe" bist. .NET ist Opium für Entwickler, und Drogen sind nicht gut für dich.
Es entscheidet letztlich der Kunde.

Ein Tipp: versuche das Ganze .NET-Thema mal frei davon zu betrachten, dass es von MS stammt. Bin leider die nächste Tage nicht zu Hause und kann daher vorerst nicht weiter antworten.

[HellHorse]

Mit Attributen kann man bei einigen Sprachelementen (Membervariablen, Methoden, Properties etc.) die Deklaration um zusätzliche Informationen bereichern. Diese Informationen sind dann beliebig auswertbar.
Tönt für mich wie Annotations.

Weiss ich nicht. Ich drucke nicht, sondern beschränke mich auf die Anzeigefähigkeiten meines Monitors :redface:
Auf den Bildschirm zeichnen und auf Papier zeichnen ist in Java eigentlich das Gleiche. D.h du hast das volle Java2D inkl AttributedString und was das Herz sonst noch alles begehrt.
Für mehrzeiligen Text hast du LineBreakMeasurer, TextLayout et cetera als Hilfsklassen.

[myMind]

Tönt für mich wie Annotations.

Ab Java 1.5 (Java5)?

Auf den Bildschirm zeichnen und auf Papier zeichnen ist in Java eigentlich das Gleiche. D.h du hast das volle Java2D inkl AttributedString und was das Herz sonst noch alles begehrt.
Für mehrzeiligen Text hast du LineBreakMeasurer, TextLayout et cetera als Hilfsklassen.
Funktioniert ab? Mit 1.3 (wegen Oracle 9i) habe ich mir noch tierisch was abgebrochen, um Text halbwegs vernünftig auszudrucken. Und selbst dann funktionierte es nicht mit jedem Drucker richtig.

[HellHorse]

Ab Java 1.5 (Java5)?
Yepp

Funktioniert ab?
K.A. Java2D kam mit 1.2 oder? LineBreakMeasurer und TextLayout haben zwar kein @since aber das von java.awt.font sagt auch 1.2.

Ich hab's allerdings mit 1.4 verwendet.

[Leonidas]

Naja, aber ob du damit so viel erfolg hättest?!

DirectX könnte man auch auf Linux bringen, nur scheint die Linuxgemeinde das nicht zu wollen...



Glaube ich nicht. Sicherlich, die Hartcore-Linuxer sind sogar stolz darauf, daß nicht jede Software, insbesondere Spiele, auf Linux läuft. Doch die Zeiten ändern sich und die Mehrheit der Linux-User dürfte inzwischen klar nicht mehr zur Hardcore-Klasse gehören.

Zudem geht es bei dieser Idee eher darum, potentielle Linux-User aus dem Windows-Lager anzusprechen. Ich persönlich würde sofort auf Linux wechseln, wenn ich bezüglich Spiele diesbezüglich keinerlei Nachteile hätte. Falls es DirectX auf Linux gäbe, könnte Linux innerhalb weniger Monate einen Millionen-Zulauf aus dem Windows-Lager bekommen.

[Leonidas]

Um DirectX auf Linux zu bringen müsste man den ganzen COM-Schrott komplett nachprogrammieren. Und den Stress gibt sich einfach keiner. Ausserdem gibt es schon OpenGL, welches schon funktioniert.



Das nützt niemand was. Die Spiele werden nun einmal für DirectX geschrieben. Und die Spiele-Hersteller zu einem OpenGL-Support zu bewegen, ist eine Illusion.

Natürlich würde ein DirectX-Wrapper genauso den Zweck erfüllen. Er müsste nur eben wirklich jedes Spiel darstellen können.

[Leonidas]

Wie verbohrt muss man eigentlich sein, um bewusst und nur aus persönlicher Abneigung heraus alle Argumente für NET einfach ignorieren zu können? Selten so eine Sturheit gesehen.


Wieso? Wenn ich Microsoft aus Prinzip ablehne, ist das doch ein (zumindestens für mich) absolut zwingendes Argument. Es muß eher die Frage erlaubt sein, wo Dein mathematischer Coprozessor abgeblieben ist, wenn Du diese absolut klare Logik nicht zu erkennen vermagst.

Das es für Dich eine andere Gleichung gibt, bezweifle ich nicht. Aber das war nicht das Thema. Für mich überwiegt halt der aus meiner Sicht gigantomane Nachteil "Microsoft" all die aufgezählten Vorteile von .NET.

[Leonidas]

Ganz unbegründet ist Leos Aversion imo nicht. Wenn ich mich recht entsinne, kam MS weiland auf die Idee, Java um Windows-spezifische Funktionen zu erweitern, um es inkompatibel zu machen. Sun wurde sauer und bewirkte dass MS das nicht tut. Aus Verbitterung versuchte MS dann, Java mit neueren Windows-Versionen gar nicht mehr zu unterstützen, was sie natürlich aufgegeben haben.



Das ist so ungefähr die unwichtigste Begründung No. 324 für meine Anti-MS-Haltung. Was ausdrückt, wieviel mehr und wieviel wichtigere Gründe ich noch sehe.

[Leonidas]

Wenn man diesen Thread mal quer liest, sieht man, das im Grunde alle Bedenken gegen .NET entweder auf Unwissenheit oder auf Mistrauen gegenüber Microsoft beruhen. Ich kann das aufgrund Microsofts Ruf gut verstehen und auch nachvollziehen. Das es jedoch kaum fachliche Gegenargumente gegen .NET gibt, sagt einiges aus.



Das mag sein, daß die fachlichen Gegenargumente gegenüber .NET nicht weltbewegend sind. Jedoch: Wieso sollen prinzipielle Nachteile wie der "Ruf von Microsoft" keinerlei Bedeutung gegenüber fachlichen Argumenten haben?

Was spricht dagegen, eine moralische Entscheidung zu treffen - und dabei womöglich fachliche Argumente hintenan zu stellen? Und ich muß mal ganz missionarisch fragen: Wieso ist die moralische Komponente nicht ganz automatisch die wichtigste und entscheidenste im Entscheidungsfindungsprozeß?

[Demirug]

Glaube ich nicht. Sicherlich, die Hartcore-Linuxer sind sogar stolz darauf, daß nicht jede Software, insbesondere Spiele, auf Linux läuft. Doch die Zeiten ändern sich und die Mehrheit der Linux-User dürfte inzwischen klar nicht mehr zur Hardcore-Klasse gehören.

Zudem geht es bei dieser Idee eher darum, potentielle Linux-User aus dem Windows-Lager anzusprechen. Ich persönlich würde sofort auf Linux wechseln, wenn ich bezüglich Spiele diesbezüglich keinerlei Nachteile hätte. Falls es DirectX auf Linux gäbe, könnte Linux innerhalb weniger Monate einen Millionen-Zulauf aus dem Windows-Lager bekommen.

Mit Cedega gibt es ja immerhin einen Versuch in diese Richtung. Den grossen Zulauf sehe ich aber nicht. Das könnte aber auch mit dem Geschäftsmodel hinter Cedega zusammen hängen.

[Exxtreme]

Den grossen Zulauf sehe ich aber nicht. Das könnte aber auch mit dem Geschäftsmodel hinter Cedega zusammen hängen.
So sieht's aus. Ausserdem ist Cedega nicht so gut wie manch einer denkt.

[Andre]

Wieso? Wenn ich Microsoft aus Prinzip ablehne, ist das doch ein (zumindestens für mich) absolut zwingendes Argument. Es muß eher die Frage erlaubt sein, wo Dein mathematischer Coprozessor abgeblieben ist, wenn Du diese absolut klare Logik nicht zu erkennen vermagst.

Das es für Dich eine andere Gleichung gibt, bezweifle ich nicht. Aber das war nicht das Thema. Für mich überwiegt halt der aus meiner Sicht gigantomane Nachteil "Microsoft" all die aufgezählten Vorteile von .NET.

Mag sein. Es zeigt aber trotzdem, wie fähig du bist, sachliche Argumente zu verstehen/einzubeziehen und zu differenzieren zwischen emotionalen und faktenbasierten Vorbehalten. Und das sollte man ab einem gewissen Alter schon drauf haben, vor allem, wenn man in gewisser Weise Journalismus betreiben will.

[Demirug]

Das mag sein, daß die fachlichen Gegenargumente gegenüber .NET nicht weltbewegend sind. Jedoch: Wieso sollen prinzipielle Nachteile wie der "Ruf von Microsoft" keinerlei Bedeutung gegenüber fachlichen Argumenten haben?

Was spricht dagegen, eine moralische Entscheidung zu treffen - und dabei womöglich fachliche Argumente hintenan zu stellen? Und ich muß mal ganz missionarisch fragen: Wieso ist die moralische Komponente nicht ganz automatisch die wichtigste und entscheidenste im Entscheidungsfindungsprozeß?

Ich sehe bei dieser rein technischen Fragestellung zwar keine moralische Komponente. Aber nehmen wir mal an das es sie gibt dann hätten wir sie bei jedem anderen MS Produkt auch. In letzter Konsequenz dürfte man dann aufgrund der gleiche Argumentation auch kein neue DirectX Version auf einem System haben. Denn das Argument "MS ist böse" gilt dann universel für alles was aus diesem Lager kommt.

[Demirug]

So sieht's aus. Ausserdem ist Cedega nicht so gut wie manch einer denkt.

Kann ich nicht beurteilen weil ich den Code davon nicht gesehen haben. Der Vorgänger (WineX) war aber was die Umsetzung von DX angeht wirklich eher schwach weil vieles nicht berücksichtigt wurde.

[Andre]

Ich sehe bei dieser rein technischen Fragestellung zwar keine moralische Komponente. Aber nehmen wir mal an das es sie gibt dann hätten wir sie bei jedem anderen MS Produkt auch. In letzter Konsequenz dürfte man dann aufgrund der gleiche Argumentation auch kein neue DirectX Version auf einem System haben. Denn das Argument "MS ist böse" gilt dann universel für alles was aus diesem Lager kommt.

Ich sag ja: Inkonsequent. Mal hüh, mal hott. Grade wie es passt und man es besonders gut selbstdarstellerisch verkaufen kann.

[Leonidas]

Mit Cedega gibt es ja immerhin einen Versuch in diese Richtung. Den grossen Zulauf sehe ich aber nicht. Das könnte aber auch mit dem Geschäftsmodel hinter Cedega zusammen hängen.


Ich kenne die nicht einmal. Was machen die?

[Leonidas]

Ich sag ja: Inkonsequent. Mal hüh, mal hott. Grade wie es passt und man es besonders gut selbstdarstellerisch verkaufen kann.


Nein. Ich nehme von MS, wozu ich gezwungen bin *. Und exakt aus diesem Grund wehre ich mich gegen Dinge, wo noch Auswahl besteht, dagegen, daß durch die Wahl von MS-Produkten diese Auswahlmöglichkeit in der Zukunft womöglich nicht mehr gegeben sein wird, weil MS dann auch diesen Teilmarkt monopolisiert hat. Hat nix mit "hüh und hott" zu tun.


* Wenn ich irgendwo inkonsequent bin, dann darin, daß ich für Dinge, die ich innerlich ablehne, immer noch fair Geld bezahle.

[Demirug]

Ich kenne die nicht einmal. Was machen die?

Cedega ist eine Erweiterung für Wine von Transgaming Technologies (http://www.transgaming.com/) die es möglich machen soll Windows DirectX Spiele unter Linux zu spielen.

[mapel110]

Cedega ist eine Erweiterung für Wine von Transgaming Technologies (http://www.transgaming.com/) die es möglich machen soll Windows DirectX Spiele unter Linux zu spielen.

Und hiess vorher WineX, das ist wohl bekannter. :)

[myMind]

Das mag sein, daß die fachlichen Gegenargumente gegenüber .NET nicht weltbewegend sind. Jedoch: Wieso sollen prinzipielle Nachteile wie der "Ruf von Microsoft" keinerlei Bedeutung gegenüber fachlichen Argumenten haben?

Was spricht dagegen, eine moralische Entscheidung zu treffen - und dabei womöglich fachliche Argumente hintenan zu stellen? Und ich muß mal ganz missionarisch fragen: Wieso ist die moralische Komponente nicht ganz automatisch die wichtigste und entscheidenste im Entscheidungsfindungsprozeß?
Wenn du das Verhalten Microsofts für so unmoralisch hältst, dass du keine Produkte mehr von ihnen kaufen magst, so kannst du das tun. Es ist für mich ein absolut gültiges Argument.

Im Ggs. zu den harten Fakten ist die Frage nach der Moral in vielen Fällen jedoch weich. Die Frage, ob man Microsoft-Technologie einsetzen soll oder nicht ist eine solche weiche Frage. Beispiele dazu:
- Soll eine Firma, die in der Vergangenheit nachweislich durch das Setzen auf MS erfolgreich war, jetzt wirklich den Kurs wechseln?
- Wie stellt sich deine Moral für den deutschen MS-Mitarbeiter, der möglicherweise entlassen wird, wenn die Produkte der Firma beukottiert werden, dar?
- Soll ich riskieren Geschäftpartner zu verlieren, indem ich meine Dokumente im OpenOffice-Format verschicke?
- Handelt die Firma Sun oder IBM moralischer als Microsoft?

[Quasar]

Nein. Ich nehme von MS, wozu ich gezwungen bin *.[...]

Du solltest Anzeige erstatten. In begründeten Fällen gewährt die Polizei auch Schutzhaft, solange, bis diejenigen, die dich gegen deinen Willen zu etwas zwingen, keine Bedrohung mehr für dich darstellen.