was genau ist so toll jetzt daran? warum soll jetzt aufeinmal c# genommen werden fuer projekte und nicht ruby oder python? was ist toll an .net? bzw was ist das ueberhaupt? sollense mal machen. olli
Miguel de Icaza and the Mono team recently hosted a two day open meeting in Boston. O'Reilly have just published my report of the meeting. Highlights include Miguel's view that 'C is dead!' and the Mono approach to dealing with Microsoft patents on .NET."
Gut dass die GNOME Leute das auch mal einsehen. Einen Kernel kann/muss man vielleicht in C schreiben aber bei GUIs wirds doch recht mühsam und fehleranfällig.
Da war der Knabe aber noch so grün hinter den Ohren das man ihm eigentlich vergeben muss. Ich bewundere immer diese Leute die mit kompletem Unwissen und schlechter Ausbildung dann doch noch eine Menge geld scheffeln können, währrend ich mich mit Peanuts abgebe.
Wieso ist C tot? Was das denn? Und wieso .Net und wieso nicht Java? Wegen Kompatibilität zu Windows? Irgendwie is das mit den Sprachen zur Zeit alles etwas chaotisch. Unter Linux läuft C/C++ wunderbar. Damit kann man GTK QT usw. schreiben. Dafür läuft das nicht unter Windows. Mit Java hat man etwas, das zwar mit einer nachträglich installierten VM auch gut läuft, aber etwas langsamer (etwas!! nicht mehr viel) ist, und sich noch nicht so gut in den Desktop einfügt. Derzeit wird dran gearbeitet, dass es mit SwintWT auch native läuft, aber so ganz ist das noch nicht das wahre. Da man für Java eben immer eine VM benötigt ist das mit der Verbreitung von Java auf dem Desktop so eine Sache. Mit Mono haben wir jetzt wieder etwas anderes, das sich versucht irgendwie breit zu machen und schauen muss, dass es mit .Net von Windows mithält. Wäre Java standardmäßig auch unter Windows installiert und würde es sich standardmäßig an die GUI anpassen wäre das wirklich topp. Aber nach wie vor ist C sicher nicht tot, meiner Meinung nach.
"C ist tot" ist halt Marketing. Nach ihren FAQ soll Mono zwar .NET-kompatibel sein, aber auch eigene Standards beinhalten/ plattform-übergreifend zugänglich machen.
C ist wenn überhaupt schon seit 20 Jahren tot. C++ ist schon besser (OOP) aber immer noch ein Sicherheitsrisiko (buffer overflow, ...) wenns von Lamern programmiert wird. Zum Thema Java: Java ist schön interoperabel (und vom Konzept eine tolle Programmiersprache), aber leider viel zu langsam (ausser man kann sich privat ein Cluster leisten). Wenn Mono/DotGNU Erfolg haben sollte, können Windowsprogramme (Office, ...) auch auf Linux laufen (ohne die Probleme mit WINE, ...) -> das wäre meiner Meinung nach der Durchbruch für den Linux Desktop - auch Unternehmen könnten dann überzeugt werden auf ein Linux System zu gehen. Zum Thema Ruby/Python: Warum ins Mittelalter zurück ? Python ist für Scripts toll, aber mit (OO-)Programmierung hat das nichts zu tun.
Mono / .NET ist ebenso interpretiert wie Java es läuft eine verdammt ähnliche Technik dahinter und .NET ist in sehr vielen Fällen deutlich langsamer als java... ( das Vorurteil Java sei langsamer sollte entkräftet sein wenn man sich mal Benches anguckt wie schnell Java dynamische Arrays hantiert.. das kann Java nämlich sogar noch schneller als C++ )
Für alle die glauben Java sei keine Alternative.. die sollen sich doch bitte mal Eclipse anschauen... native Widgets ( dank SWT ) schnell, stabil, komplex und ein absolut gigantisch gutes IDE....... ( ich kenne keine IDE die Eclipse überlegen ist.. schon gar nicht Visual Studio .NET..... )
Ich finde Mono ist ein Schuss in die falsche Richtung Java wäre die bessere Lösunge gewesen.. ( und es ist auch schöner zu programmieren ich habe mit beidem sehr viel beruflich gearbeitet und gerade C# hat einfach so ein paar "eigenheiten" die den wirklich sehr schönen ( wenn auch nicht perfekten ) Programmierstil von Java brechen )
Hätte Icaza sich auf Java eingeschossen hätten wir jetzt schon viel länger ein stabile Sammlung an GTK Bindings ( gnome-java ist schon weit ) einen perfekt funktionierenden gcj sowie eine super Java IDE mit Eclipse...... aber nein Icaza musste ja unbedint Microsoft hinterherdackeln ( und ja ich bin mir bewusst das die .NET Technologie etwas feines ist.. aber so VIEL feiner als Java ist es auch nicht und Java kann sich auch noch weiterentwickeln und die kleinen Schwächen ausmerzen )
Na da muss ich aber mal widersprechen: Zugegeben Java ist mittlerweile sehr schnell geworden und steht z.B. C++ in nicht mehr sehr viel nach, aber Eclipse ist keine schnelle GUI. Sicher nicht! Ich habe Eclipse auf einem 1,4 GHz mit 512 MB Ram laufen und es ist absolut träge. Kumpel hat jetzt extra wegen eclipse auf 1 GB Ram aufgestockt, damits vernünftig läuft. Auch wenn es schön native aussieht dank SWT ist es garantiert nicht schnell. Vielleicht ist das unter Windows anders.
ich kenne keine IDE die Eclipse überlegen ist.. schon gar nicht Visual Studio .NET..... )
Nicht wirklich Visual Studio ist schon ein anderes Kaliber. Eclipses CDT kommt nicht im entferntesten an die Möglichkeiten von VStudio heran. Der Java-Support ist ganz ordentlich und das ganze ist ziemlich modular, das war es dann aber auch schon bei Eclipse.
Von Manfred Tremmel am Di, 16. März 2004 um 12:14 #
Schön, und wenn dann alle brav C#-.NET Anwendungen schreiben und keine nativen Linux- oder Java-Anwendungen mehr, kommt MS, verweist auf die Softwarepatente, die im Rahmen von .NET zugeteilt wurden und läst MONO/DotGNU verbieten. Die Firmen die nun auf ihren .NET-Anwendungen sitzen haben keine Wahl mehr und müssen auf Windows migrieren. Im Gegensatz zur lächerlichen SCO-Abmahnwelle hat MS dann wirklich was auf der Hand und Linux versinkt in der Bedeutungslosigkeit.
Nicht wirklich! M$ kann seine Softwarepatente in Europa (noch) nicht durchsetzen. Ich hoffe das das auch in Zukunft so bleibt. Wenn es erst mal eine OSS Lösung gibt die konkurenzfähig ist (und darum geht es hier). Es geht _nicht_ darum ob nun .NET oder Java besser is. Es geht einfach darum, dass M$ sich mit .NET keine Vormachtstellung sichern kann. Wenn nämlich im enterprise bereich alle von .NET begeistert sind und darauf programmieren, hätten alternativen keine Chance mehr. .NET ist nur das Mittel, dass M$ einsetzt um sich auf dem Servermarkt zu etablieren. Mono hällt nur dagegen, DAMIT sich M$ nicht in diesem Bereich auch noch durchsetzen kann. Wenn Mono voll kompatibel ist, könnte außerdem die Migration von Windows zu Unix basierten Systemen leichter fallen (_auch_ und _gerade_ für Privatanwender und "Mittelständler"). Java gibt es bereits für Linux und es ist daher nicht nötig noch ein Projekt in Java zu starten. Damit würde man nur eine Art Java .Net Emulator erreichen. Eine Art "Wine für .NET", was sicherlich langsamer wäre als Java und .NET zusammen. Wenn Mono unter GPL steht und die schnell genug sind (wenn die SW Patente hier durchgesetzt sind) könnte man M$ sogar .NET-mäßig aus Europa verdrängen
Python gehört nicht ins Mittelalter. Ich bin ja kein Experte für objekt-orietierte Programmierung, aber gerade Python bietet sich als Scriptsprache für OO-Programmierung an und lässt sich einfacher verstehen als Java. Gerade für die schnelle Entwicklung ist es geeignet und bietet sich so als Alternative an.
Was Mono an geht bin ich gespannt und wenn es die Entwicklung auf dem Desktop voranbringt, dann ist das prima. Gerade die Vielfältigkeit hat Linux und OpenSource bislang ausgezeichnet
Das problem mit Miguel - ist dass er so von sich selbst ueberzeugt ist, sowas von arrogant ist, und keine Ruecksicht auf verluste nimmt. D.h. - was er denkt und sagt, dass glaubt er selbst auch - und das "ist" Gesetz. Eigentlich ein guter Programmierer - aber ein A* IMHO ...
Was ist eigentlich mit dotGNU? Geht da die Entwicklung einigermaßen voran? Warum überhaupt zwei Projekte mit (oberflächlich betrachtet) dem gleichen Ziel? Könnte man da nicht mehr zusammenarbeiten? Normal ist ja gerade der Vorteil von Freier Software das nicht jeder das Rad für sich erfinden muß...
Wie freier? BSD-Lizenz ;)... Nur weil GTK/GNOME, verständlicherweise bevorzugt wird, heisst das noch lange nicht KDE feindlich, oder wer würde denn SUSE/Mandrake oder gar deutchen Linuxnutzern z.B. Gnome Feindlichkeit unterstellen?
Und wird auch genausowenig von den DotGNU-Entwicklern gefördert.
Das einzige, was DotGNU zusätzliches an Widget-Libraries bietet ist deren Windows-Forms Implementierung. Wärend DotGNU sie auf der Basis vom puren X11 erstellt, versucht Mono es mit WINE als Grundlage (und als weiteres Miniprojekt mir Gtk+ als Grundlage für Winforms). Aber das Hauptziel von Mono ist - im Gegensatz zu DotGNU - auch nicht die Winforms alle nachzuentwickeln, sondern eine schöne Entwicklungsplattform für Linux/Unix zu entwickeln. Daher sind sie hauptsächlich an GTK# dran. Abgesehen davon läuft GTK# ebenfalls sowohl auf Linux/Unix, als auch auf MS-Windows, als auch auf MacOS X und anderen Plattformen.
ich glaube eher dieser miguel leidet selbst an hirntot. zu sagen c ist tot gleicht einem armutszeugnis. was sollen all diese affensprachen python net und wie sie alle heißen? ich programmiere schon seit jahren mit c++ und ich würde um nix in der welt anfangen mit so ner affigen performance killenden gebärdensprache zu programmieren. was sind die vorteile? hardwareunabhängig? wer braucht das? programmierung muss 100 %ige kontrolle üebr den code bieten und dass können weder C# python oder sonst was für affensprachen.
Oh, sogar was objektorientiertes (wenn man will). Ich nehme mal an, Du meidest diesen ganzen blödsinnigen STL-Kram und so Sachen wie beispielsweise new und delete und benutzt stattdessen noch malloc und free. Um die volle Kontrolle über den Code zu haben (s.u.). Gleiches bei Strings, denn die string-Klasse ist nix für wahre Programmierer. Da kann man gar nicht mehr so schöne Buffer Overflows produzieren, die man dann hinterher suchen darf. Wie langweilig.
> hardwareunabhängig? wer braucht das?
Ja, klar, Portabilität ist was für Schattenparker. Hauptsache der Code läuft auf meinem Sinclair QL.
> programmierung muss 100 %ige kontrolle üebr den code bieten
Warum nicht gleich Assembler? Das bietet 100%ige Kontrolle über den Code. Wie schade, dass man nicht gleich jeden Transistor direkt ansteuern kann.
> affensprachen
Meinst Du damit das Gebrabbel, das Du hier von Dir lässt?
deine begrenzte intelligenz hat dir wohl verborgen das c teil von c++ ist. demnach kann jeder c++ programierer auch mit c umgehen. dein vergleich mit dem transistor ist interessant nur leider volkommen an den haaren gezogen. und mit affensprachen meine ich sprachen die für leute gemacht sind die zu blöd sind mit pointern und speicherverwaltung umzugehen. und stl hat auch nix mit den affensprachen(ich liebe den begriff den er ist für dich wie geschaffen) zu tun. ziel der programmierung muss es sein lösungen zu optimieren und abstrakte sprachen sind hierfür die größte gefahr denn sie nehmen dem programmierer die möglichkeit das program komplett nachzuvollziehen und an den notwendigen stellen zu verfeinern.
Auch wenn ich mich in Gefahr begebe, einem Troll zu antworten...
===== und mit affensprachen meine ich sprachen die für leute gemacht sind die zu blöd sind mit pointern und speicherverwaltung umzugehen. ===== Nicht jeder, der wie du es nennst "Affensprachen" einsetzt und verwendet ist zu blöd, um mit Pointern oder der Speicherverwaltung umzugehen. Aber das ist dir natürlich alles bekannt.
===== und stl hat auch nix mit den affensprachen(ich liebe den begriff den er ist für dich wie geschaffen) zu tun. ziel der programmierung muss es sein lösungen zu optimieren und abstrakte sprachen sind hierfür die größte gefahr denn sie nehmen dem programmierer die möglichkeit das program komplett nachzuvollziehen und an den notwendigen stellen zu verfeinern. ===== "Für die moderne geläufige Auffassung ist eine Sprache die virtuelle Sprache: man spricht Sprachen (also realisiert man sie im Sprechen), man kann Sprachen. Und für den Sprachwissenschaftler ist gewöhnlich eine Sprache die abstrakte Sprache, die Sprache, die er selbst vom Sprechen abstrahiert hat."
C# und Java sind also abstrakte Sprachen? Ebenso wie Perl, Python und Ruby?
Und was soll dich als Programmierer daran hindern, ein in z.B. Java geschriebenes Programm komplett zu verstehen ("was tut es?") und es eventuell anzupassen bzw. zu optimieren? Ist es vielleicht schwer, verschiedene Implementierungen von Sortierroutinen (eine gern gemachte Aufgabe für Programmieranfänger) in C#, Java, Perl, Python, Ruby, Tcl, ... selbst zu implementieren, komplett zu verstehen und zu optimieren?
"Und was soll dich als Programmierer daran hindern, ein in z.B. Java geschriebenes Programm komplett zu verstehen ("was tut es?") und es eventuell anzupassen bzw. zu optimieren?"
Die tatasache das man den GC nicht abschalten kann, es keine gescheiten templates gibt und das native interface von Java nicht auf portable c++/obj-c bibliotheken ohne grosse Umstände zugreifen kann. zum Beispiel.
C++/Obj-C/Pascal/Fortran kann man mischen. Java/Perl und andere "Affensprachen" können die bibliotheken nicht nutzen und können deshalb nicht mithalten.
===== Die tatasache das man den GC nicht abschalten kann, es keine gescheiten templates gibt und das native interface von Java nicht auf portable c++/obj-c bibliotheken ohne grosse Umstände zugreifen kann. zum Beispiel. ===== Ok, es gibt bei Java und C# eine GarbageCollection. Die gibt es allerdings auch für das so populäre VisualBasic. So what? Wenn die GC stört, dann verwende halt eine Programmiersprache/-umgebung wo es keinen GC gibt. Wie wäre es mit Assembler, C, C++, Obj-C, Obj-C++, Pascal, Object-Pascal, ...
===== C++/Obj-C/Pascal/Fortran kann man mischen. Java/Perl und andere "Affensprachen" können die bibliotheken nicht nutzen und können deshalb nicht mithalten. ===== Das ist eine Einschränkung des verwendeten Compilers und nicht eine Einschränkung der verwendeten Programmiersprachen als solches.
Desweiteren kannst du durchaus von Java (Stichwort: JNI) oder Perl (Stichwort: PerlXS) heraus Funktionen aufrufen die du vorher in Shared Libraries abgelegt hast.
IIRC kann man selbst aus Python, Ruby und Tcl heraus auf Shared Libraries zurück greifen.
> demnach kann jeder c++ programierer auch mit c umgehen.
Nein, man kann wunderbar in C++ programmieren, ohne von z.B. von malloc, free und char*-Vodoo nur die geringste Ahnung zu haben. Wozu gibt es new, delete und std::string...
> sprachen die für leute gemacht sind die zu blöd sind mit pointern und speicherverwaltung umzugehen.
Haha, deshalb liest man auch ständig, dass in der mit C entwickelten Software XY mal wieder ein Buffer Overflow entdeckt wurde und Anwendungen verabschieden sich mit Segfault (meistens GTK/Gnome-Anwendungen, woher kommt das nur). Und das alles oft nur, weil sich da jemand mal wieder zu stur war, einzusehen, dass nicht jede popelige GUI-Anwendung nicht in ANSI C geschrieben werden muss.
> ziel der programmierung muss es sein lösungen zu optimieren
Nur wo es notwendig ist. Beim Linux-Kernel würde ich auch kein Python einsetzen, klar. Anderseits würde ich z.B. eine IDE im Leben nicht in C entwickeln.
Zum Optimieren: Ich halte es da mit dem Verfasser des Artikels "Optimization: Your Worst Enemy": http://www.codeproject.com/tips/optimizationenemy.asp (der Artikel hat nix mit MS oder .NET zu tun, die originale Seite gibts nicht mehr).
> ich liebe den begriff den er ist für dich wie geschaffen
Freundchen, Du bestätigst gerade mal wieder wunderbar das Klischee vom Low-Level-Fanatiker. Scheuklappen, pseudo-elitäres Dummgelaber, sozial inkompetent und diskussionsunfähig.
> > programmierung muss 100 %ige kontrolle üebr den code bieten > Die Programmierung ist das Programm und das hat nur seltenst die 100%ige Kontrolle -- geschweige denn überhaupt eine Art von Kontrolle -- über den (Quell-? oder Maschinen-?) Code, sondern das Programm folgt einfach stupide seiner Programmierung: seinem Code.
Der Programmierer selbst hat i.d.R. auch keine 100%ige Kontrolle über den (Maschinen-)Code, da er ja heutzutage bevorzugt in $HOCHSPRACHE programmiert und somit die Kontrolle einem Programm (dem Compiler) überlässt, das den (Quell-)Code des Programmierers analysiert, ggf. optimiert und letztendlich in (Maschinen-)Code übersetzt. Ausnahmen sind, wenn der Programmierer selbst in $MASCHINENSPRACHE programmiert. Nur in diesem Fall besitzt er die 100%ige Kontrolle darüber, wie sein Quellcode in Maschinencode übersetzt wird.
"c++", ich weiß nicht ob Du alles hier so ernst meinst wie Du's schreibst, aber danke, Du hast mich heute Abend doch noch erheitert...
Auch wenn ich eigentlich nicht auf solche Kommentare antworte, zwei Anmerkungen kann ich mir nicht verkneifen:
Affensprachen - Du subsumierst unter diesem Begriff keine Sprachen, sondern die Unterscheidung von grob gesagt interpretierten Programmen (in einer "Affensprache" verfasst) und nativ übersetzten Programmen (in einer "Hundesprache?" verfasst)... Dabei übersiehst Du völlig, das die Performance von C Programmen durch native Übersetzung nur bedingt mit der Sprache als solche, sondern vielmehr mit der Übersetzung zu tun hat. Theoretisch wär's kein Problem ein Programm in einer "Affensprache" mit einem geeigneten Compiler nativ zu übersetzen.
Zum anderen scheinst Du noch nie bemerkt zu haben, das die von Dir als "Affensprachen" gebranntmarkten Sprachen genauso Turing-Complete sind (und das ist sogar Brainfuck), wie Dein favorisierter C++ Dialekt.
Nachtrag: ...und letztendlich die wahre Performance von Programmen sich nicht aus ihrer nativen Ausführung bzw. interpretativen Ausführung ergibt, sondern aus der Platz- und Zeitkomplexität ihrer Algorithmen ergibt.
vollkommen falsch. java code(und andere) muss erst von eine virtualmachine in machinecode übersetzt werden das allein sorgt für erhebliche geschwindigkeitseinbußen. also hier irst du dich gewaltig. zudem nutzen viele dieser template sprachen vorgefertigte klassenfunktionen die manchmal eben mehr oder weniger tun als man braucht was ében die optimierung und anpassung verhindert. da hat c++ recht auch wenn er es unqualifiziert ausdrückt.
> java code(und andere) muss erst von eine virtualmachine in machinecode > übersetzt werden das allein sorgt für erhebliche geschwindigkeitseinbußen.
Und was macht das für einen Unterschied? Selbst ein 500 MHz-Rechner bringt bei den meisten Anwendungen noch einen Großteil mit dem Warten auf Benutzereingaben zu. Ausserdem ist der Aufwand, in einer Scriptsprache zu programmieren, in der Regel deutlich geringer, der Programmierer schafft also mehr in weniger Zeit. Und die meisten Scriptsprachen lassen sich einfach in C/C++ erweitern, so kann man zeitkritische Routinen optimiert in C schreiben und den Rest in der Scriptsprache schreiben.
Dieses Prinzip hat sich sogar in der Spielebranche durchgesetzt, wo man doch eigentlich immer noch Hochleistung von den Rechnern erwartet. So ist z. B. EVE-Online in Stackless-Python geschrieben, Monkey Island ist in Lua geschrieben (siehe die Luabar ;)), genauso FarCry.
Ich finde das Programmieren in Ruby beispielsweise einfach sehr angenehm, und ich habe längere Zeit C programmiert und auch in Java und C++ reingeschnuppert. Es ist zwar nicht für jeden Anwendungsfall etwas, aber doch für erstaunlich viele Sachen geeignet. Aber wer nicht über den Tellerrand schauen will, muss halt in seinen Vorurteilen versauern. ;)
du bist wieder ein beispiel für leute die keine ahnung haben aber ihren senf trotzdem dazugeben müssen. wenn der code zur laufzeit übersetzt werden muss dann ist das sehr wohl extrem viel langsamer. das ist auch der grund warum die meißten spiele wie half life doom3 etc. drauf verzichten. außerdem ist ut im vergleich zu anderen spielen langsamer. außerdem wer zu weit iüber den tellerrand guckt fällt runter(du hoffentlich als erster).
"Wenn der code zur laufzeit übersetzt werden muss dann ist das sehr wohl extrem viel langsamer."
Das kann man pauschal nicht sagen. Es gibt auch sehr wohl viele Situationen, bei denen die Geschwindigkeit zwar spürbar geringer ist, aber dennoch der Vorteil der gesteigerten Flexibilität überwiegt. Zumal in vielen Situationen auch andere Faktoren wichtig sind: Festplatten Zugriffszeit, Netzwerkgeschwindigkeit (Durchsatz und Latenz), vorhandene "Spezial"-Hardware
"wie half life doom3 etc. drauf verzichten"
Mag sein, aber bisher scheint weder Doom3 noch HalfLife der UT Engine überlegen zu sein. Und Far Cry ebensowenig.
"ist ut im vergleich zu anderen spielen langsamer"
Das kann ich garnicht bestätigen. Bei mir läuft UT genauso gut oder schlecht wie andere Spiele vergleichbarer Grafik auch (2GHz Athlon, ATI 9500Pro, 512 MBRam, diverse HDDs)
"wer zu weit iüber den tellerrand guckt fällt runter"
Sehr schöner Satz .... also viel Spaß in deiner Suppenschüssel
jetzt muß ich da mal einschreiten. Deine Meinung in Ehren, aber "Affen" und "Gebärdensprache" in abwertenden Aussagen einzubinden ist gar nicht in Ordnung.
Ich kann die Gebärdensprache soweit, daß ich mich mit Gehörlosen unterhalten kann. So kenne ich die Unterschiede zwischen der Lautsprache und der Gebärdensprache. Ein Punkt ist in diesem Zusammenhang sehr prägnant:
Mit der Gebärdensprache kann ein Satzinhalt schneller von Person zu Person übermittelt werden, als mit der Lautspreche -> es geht schneller! Kurzum: Gehörlose können innerhalb eines gleichen Zeitraums mehr Informationen übermitteln als Lautsprechende.
Das liegt daran, weil zur Kommunikation neben der Gestik bzw. Gebärden auch die Mimik eingesetzt werden. Kurz gesagt, bei der Gebärdensprache werden MEHR Mittel (= bewußter Einsatz nichtsprachlicher Signale) zur Kommunikation eingesetzt, als mit der Lautsprache, bei der überwiegend nur gesprochen wird.
Wenn man schon die Gebärdensprache / Lautsprache mit Programmiersprachen "vergleicht", dann wäre es durchaus im Sinne des Programmierers, wenn sich Programmiersprachen in weiten Teilen an die Gebärdensprache "anlehnen" würde.
Denkt doch alle mal bitte darüber nach. Ich stehe gerne zur Verfügung.
jetzt muß ich da mal einschreiten. Deine Meinung in Ehren, aber "Affen" und "Gebärdensprache" in abwertenden Aussagen einzubinden ist gar nicht in Ordnung.
Ich kann die Gebärdensprache soweit, daß ich mich mit Gehörlosen unterhalten kann. So kenne ich die Unterschiede zwischen der Lautsprache und der Gebärdensprache. Ein Punkt ist in diesem Zusammenhang sehr prägnant:
Mit der Gebärdensprache kann ein Satzinhalt schneller von Person zu Person übermittelt werden, als mit der Lautsprache -> es geht schneller! Kurzum: Gehörlose können innerhalb eines gleichen Zeitraums mehr Informationen übermitteln als Lautsprechende.
Das liegt daran, weil zur Kommunikation neben der Gestik bzw. Gebärden auch die Mimik eingesetzt werden. Kurz gesagt, bei der Gebärdensprache werden MEHR Mittel (= umfassender Einsatz nichtsprachlicher Signale als Ersatz für die Lautsprache) zur Kommunikation eingesetzt, als mit der Lautsprache, bei der überwiegend nur gesprochen wird.
Wenn man schon die Gebärdensprache / Lautsprache mit Programmiersprachen "vergleicht", dann wäre es durchaus im Sinne des Programmierers, wenn sich Programmiersprachen in weiten Teilen an die Gebärdensprache "anlehnen" würde.
Denkt doch alle mal bitte darüber nach. Ich stehe gerne zur Verfügung.
Da sieht man, was rauskommt, wenn Leute zu schnell schreiben, ohne ihr Gehirn einzuschalten.
Die Gebärdensprache ist zusätzlich noch 3D orientiert und verfügt eigentlich über wesentlich mehr Ausdrucksmöglichkeiten als unsere Sprache. Oder kannst du ein gesprochenes Wort tanzen???
Ansonsten stimme ich TOPS in allen Punnkten nachdrücklich zu!
der miguel de icaza schleimt sich schon lange bei M$ ein - vermutlich weil er dort nie untergekommen ist ;-) wie auch immer - irgendetwas das von M$ kommt, nachzuprogrammieren, ist von vornherein zum scheitern verurteilt - es wird immer hinterherhinken, und falls es mal doch eigenständig und zu einer gewissen gefahr zu werden droht, schiebt bill dem ganz schnell nen riegel vor....
Wenn man mal aussen vor lässt, dass die Programmiersprache C# und das ganze .Net Runtime Zeugs von Microsoft initiiert wurde, dann ist es nur eine weitere Programmiersprache und -umgebung die von einer Free Software Community für -- aber nicht nur -- Linux implementiert wird.
Beim GNU/Pascal Compiler (oder FreePascal) hat ja auch keiner gemeckert. Ditto beim GNU Compiler for Java oder beim Guavac Projekt. Java mit seiner VM ist ja auch nicht so vom Himmel gefallen, sondern wurde von einer Closed-Source Company quasi "erfunden".
IMO vollzieht die Free Software Community mit Mono und Dot-Gnu genau das, was damals bei Java versäumt wurde: Eine komplett freie (und bessere) Implementierung basierend auf verfügbaren Spezifikationen. Die Ähnlichkeiten von C# und Java sind ja durchaus vorhanden trotzdem scheint mir das Mono/Dot-Gnu/.Net Zeugs doch durchaus performanter zu laufen im Vergleich zu Java Programmen. Lässt man mal Microsofts Windows-only .Net Runtime + Erweiterungen aussen vor und betrachtet nur die freien Implementierungen dann ist es doch schön zu sehen, dass von vornherein VMs und Compiler für verschiedene Betriebsysteme (Unix, Linux, MacOSX, Windows) und Rechnerplattformen (x86, Sparc, PowerPC) entwickelt werden. Mono und Dot-Gnu könnten durchaus das Zeug dazu haben, im FreeSoftware und UNIX Bereich Java den Rang abzulaufen. Umso mehr, als dass die JIT und VM Performance gegenüber der Java VM nicht ins hintertreffen gerät.
Anmerkung zu Samba: Hat nicht ein Vergleichstest ergeben, dass die Version 3 von Samba sich performace-mässig selbst vor dem Microsoft Windows Server 2003 nicht zu verstecken braucht? Ihn im Gegenteil sogar im Regen stehen lässt? Wollt das ja nur mal so am Rande bemerken
Wertfrei gesprochen ist Mono zumindest eine Bereicherung, weil es in gewisser Weise die Leistungsfähigkeit freier Softwareentwicklung zeigt, auch komplexere Dinge die nicht auf unserem Mist gewachsen sind nachzubauen. Wer weiss... vielleicht denkt ja Icaza insgeheim an ein Gnome auf .NET basierend. Wäre zumindest keine so uninteressante Geschichte ;)
Wem es nicht gefällt wird Mono sowieso nicht nutzen. Wenn es keinem gefällt wird das Projekt halt untergehen. Zumindest ist C# eine recht durchdachte Sache und mit dem entsprechenden GUI-Klassen lassen sich hier recht schnell GUI-Anwendungen zusammenbauen.
Von Bolek Malkonato am Di, 16. März 2004 um 09:10 #
Ich habe selbst eine jahrelange Entwicklung: Basic, Assembler, C, C++, (Java), Smalltalk, C# mitgemacht. Jedesmal war ich davon überzeugt das die aktuelle Sprache die beste ist. Ausser Java, weil ich dann immer merke, dass der Rechner um den Faktor 20 langsamer ist. Seit einen Jahr arbeite ich mit .NET. Man muss schon zugegeben es ist vollständiger und ausgereifter als alles was es vorher war. Mono ist ein Segen für Open Source, weil es eine wichtige technologische Entwicklung nicht verpasst wird. Selbstverständlich kann man immer noch in C programmieren aber es ist zu unwirtschaftlich. Nur wenige verstehen C++ gut genug um damit sichere Programme zu schreiben. C und C++ wird wahrscheinlich nur bei Treiber oder Kernel verwendet. Mit dem Kommen von Longhorn wird man es merken, dass Linux auf einer 20 veralteten Technologie aufsetzt, die für Unternehmenanwendungen nicht ausreichend ist. Es wird stabil aber es wird auch keine Konkurenz mehr. Es wird wieder das was es war, nur ein Hobby-Informatiker-Spielzeug. Die Hoffnung für mich sind noch die moderne Skriptsprachen wie Python, Ruby oder Tcl (XOTcl). .NET ist sehr gut als eine Richtung an der man sich orientieren kann. Es ist besser .NET nachzuprogrammieren und Open Source machen (wie es bei anderen erfolgreichen Projekten schon immer war) als zu versuchen in mehreren 100 Projekten einen dritten Weg zu finden.
Von Johann von Nepomuk am Di, 16. März 2004 um 00:34 #
Bei den allen 'neuen' Technologien, die nun endlich die Software-Industrie revolutionieren werden, bin ich vorsichtig geworden. Ja es begann mit Pascal - bis dtto hat man mit hp-basic spagetti geschrieben - mit Pascal wird es strukturiert und besser. War nichts.
Dann kam C. Was die Leute davon halten lesen wir gerade hier. Dann kam ADA. Wir alle wurden zu den Schulungen geschickt, da die US-Verteidigungsministerium dahinter stand - wird sich sicher weltweit durchsetzen - erzählte das Management.
Danach Objektorientierung. Alles wird besser, endlich werden Programme ohne Fehler herstellbar. Fehlanzeige. Dann kam die Komponenten-Era - zuerst vbx. Alles wird Komponente, wieder Schulungen und alles neu schreiben. Hielt nicht lange, kam ocx. Dann Java. Alles wurde geschult - endlich einmal schreiben und ueberall benutzen. Von Big-Iron bis zur Kaffeemaschine. Und nun .NET.
Im Ernst: Ich lerne gerade meine 7. Sprache (Javascript nicht mitgerechnet) seit meinen Anfängen im Programmieren vor 10 Jahren, und man nimmt doch überall Erfahrung mit, die man wieder brauchen kann. Erst wenn man eine Sprache kennt halbwegs kennt, kann man abschätzen, für was sie sich eignet und für was nicht. Und es ist ja nicht so, dass Java oder .net nicht eingesetzt werden würden. Nur dauert es halt alles viel länger, als uns manche Marketingabteilung glauben machen will und nur die Hälfte bewahrheitet sich. Ich will aber auch nicht mehr in Comal 80 oder Turbo Pascal programmieren. Von daher kann ich das Gejammer nicht verstehen.
Ja, die Programmiersprache ist nur ein Werkzeug, die Qualität der Software hängt immer noch von dem Deppen vor der Kiste ab.
Ich kann jeden Schraubenzieher ruinieren, wenn ich ihn als Meisel verwende, genau das ist auch bei den Programmiersprachen möglich.
Aber es gibt einfach Werkzeuge, die sind bei ordnungsgemäßer Anwendung besser als andere. Dazu gehören mit Sicherheit Sprachen wie Java und C#.
Programme ohne Fehler ist keine Frage der Programmiersprache. Aber es gibt Unterschiede, was die Wartbarkeit von Code angeht. Da dürfte Assambler und C vergleichsweise schlecht abschneiden.
Ich glaube nicht so recht an OO Programmiersprachen. GTK hat bewisen das, man mit C genauso effiziente OO Programme entickeln kann, welche extrem flexibel sind. Und für die andern gibts ja gtkmm.
Was spricht dagegen, eine Programmiersprache zu verwenden, die das OO-Paradigma mit geeigneten Sprachkonstrukten unterstützt? Das dürfte eleganter sein, als "Pseudo-OO" mithilfe von C. Warum nimmst Du lieber C als z.B. C++? (ernstgemeinte Frage)
es scheint ja bei jeder News immer wieder vorzukommen, dass Leute fragen, wo denn jetzt der Unterschied zwischen Mono und DotGNU liegen, oder was es mit Miguel de Icaza auf sich hat (Ich habe z.B. ein paar Kommentare weiter oben wüste Beschimpfungen ihm gegenüber gelesen). Ob das jetzt "Rudelschimpfen" oder eigene Erfahrungen sind lasse ich mal dahingestellt, aber ich persönlich halte nicht viel Mono und dem ganzen dahinter (auch wenn es sich sehr schnell entwickelt und mittlerweile viel kann), im Gegensatz zu DotGNU, was meiner Meinung nach ein sehr sehr gutes Projekt ist.
Auf osnews.com war ein Artikel zum 0.6.4 release von DotGNU Portable.NET (kam vor paar Tagen raus) und dieser Kommentar trifft es (meiner Meinung nach) sehr gut, warum man von Mono nicht allzuviel halten kann/könnte und warum Mono evtl. einen negativen Einfluss auf .NET in Unix hat:
http://osnews.com/comment.php?news_id=6335#211141
Der Kommentar drückt das sehr sanft aus, aber man könnte ihn denke ich auch als "10 reasons not to support mono" oder "why mono destroys the .NET/Unix vision" bezeichnen ;)
Auch wenn das für manche wie ein flame klingt, das ist absolut nicht meine Absicht, ich sehe das einfach nur genauso wie es z.b. in dem Kommentar auf osnews.com dargestellt wird (Und da ich mich schon fast 2 Jahre mit DotGNU/Mono beschäftige kann ich euch versichern, dass das nicht aus der Nase gezogen ist was da steht)
Auf osnews.com war ein Artikel zum 0.6.4 release von DotGNU Portable.NET (kam vor paar Tagen raus) und dieser Kommentar trifft es (meiner Meinung nach) sehr gut,
möglicherweise, weil Du den Kommentar dort selber gschrieben hattest? Auf jeden Fall schrieb ihn jemand aus Deutschland (siehe dort die IP-Adresse).
Doch nun zu den entsprechenden Punkten zu Deinem Link:
zu 1: man muß es so sehen: weil Mono eine Firma hinter sich stehen hat, geht die Entwicklung schneller voran als bei DotGNU. Ansonsten dürfte es doch kaum jemanden stören, daß eine Firma dahintersteht. Die Lizent von Mono ist doch OpenSource. Bei OpenOffice.org stört doch auch keinen, daß eine Firma dahintersteht.
zu 2: Ich habe keine Probleme dort bemerkt. Der Vorteil von dem in C# geschriebenen C#-Compiler ist, daß er nicht mit portiert werden muß (ähnlich wie bei Java, wo der Java-Compiler auch in Java geschrieben wurde). Außerdem ist es konsequenter. Miguel erwähnt immer die Vorteile von C# gegenüber C, also ist es nur konseqent, wenn er auch möglichst viel (und somit auch den C#-Compiler) in C# schreibt.
zu 3: Der JIT-Compiler von Mono läuft auf x86, Sparc und PPC. Für andere Systeme müßte er bloß portiert werden. Doch dafür laufen Programme auf Mono nun mal auch schneller als auf DotGNU. Desweiteren kann man auch den Mono-Interpreter verwenden. Dort ist die Portierungsarbeit nicht ganz so groß. Und einen Mono-Interpreter guibt es auch für StrongARM.
zu 4: > Miguel de Icaza said if Microsoft ever wants to have money for an API or > whatever of .NET, Novell is going to pay for it wann und wo hat Miguel das gesagt? (ein Link wäre nett)
zu 5: Richtig. Viele Codeteile von Mono wurden neu geschrieben. Und mit dadran gearbeitet hat u.a. Dietmar Maurer, Martin Baulig und andere.
zu 6: Dann guck mal hier. Man kann nicht sogenau sagen, wer zuerst angefangen hat, eine .NET-Implementierung zu entwickeln. Abgesehen davon arbeiten DotGNU und Mono bei den Bibliotheken derzeit eng zusammen. DotGNU verwendet Mono-Bibliotheken und umgekehrt. Wobei ersterer Weg - daß DotGNU von Mono nimmt - weit aus häufiger vorkommt. Aber auch beim Compilerbau und JITter-bau nimmt jeder - jeweils mit der Erlaubnis des anderen - von jedem.
zu 7: Ximian guckt vorrangig zu der Entwicklungsplattform. Aber das Mono-Projekt selbst ist zu allen Seiten hin offen.
zu 8: Die einzige Auseinandersetzung die ich kenne war, daß Ximian eine zusätzliche Mailingliste Namens Ximian-hackers oder so eingerichtet hatte, die vorrangig nur Leute aus dem Mono-Core-Team aufnimmt. Dieses Mono-Core-Team beinhaltet jedoch nicht nur Ximian-Entwickler. Ist jedoch trotzdem eher eine etwas Ximian-interne Mailingliste. Für die Öffentlichkeit und für sämtliche Mono-Entwickler allgemein gibnt es Mono-devel. Und auch die Mono-Entwickler schreiben dort vorrangig rein.
zu 9: das einzige Argument dem ich mich anschließen kann. Ist schon etwas blöd, daß man für die Mono-Minimalinstallation (also ohne GTK# oder System.Windows.Forms) glib und andere Bibliotheken installiert haben muß.
zu 10: Mit "C is dead" meinte Miguel die Entwicklung von neuen C-Programmen. Damirt meinte er jedoch nicht Programme, die C zu IL kompilieren. Wenn ich mich recht erinnere, gibt es sogar ein GCC.net-projekt, daß Miguel gerne erwähnt. Verständlicherweise kann er nicht überall sein und er kann nicht an allen Projekten teilhaben. Daher wirkt er selber an Mono mit. Findet aber Entwicklungen wie GCC.net (welches die gesamten GCC-Sprachen wie gcc, g++, g77) für die .NET-Platform kompiliert als lobenswert. Genauso den LCC, der C zu IL kompiliert. Das selbe gilt für Java. Miguel lobt das IKVM-Projekt. Doch im Gegensatz zu DotGNU arbeitet Mono nicht selbst an einem Java. DotGNU erstellt von allem ein Bischen. Mono erstellt in erster Linie die Plattform, den Rest überläßt es anderen.
ja wow, es gibt ja in Deutschland auch nur wenige Leute die sich mit der Thematik beschäftigen, oder? ;)
Aber jetzt egal, zu deiner Frage Nr 4: (war in einer Diskussion um Bereiche, die eventuell durch Patente in den USA gefährdet sind, da die Diskussion von einem DotGNU Mitglied angestoßen wurde habe ich das sogar noch einigermaßen in erinnerung [nach dem link habe ich aber ehrlich gesagt gerade ge-google'ed, aber gibt ja ne thread ansicht) http://archive.neotonic.com/archive/mono-list/messages/16144?noheader=1
Das was du bei 6. sagst wäre mir neu, es stimmt, dass einige Sachen ausgetauscht wurden (Mono hat z.b. vor ner zeit das i18n Zeug von pnet übernommen, pnet hat die regex implementierung und sogar ein eigenes paket "ml-pnet" wo mono bibliotheken drin sind, die auch mit pnet funktionieren) aber die runtime und compiler haben oft große unterschiede (z.b. treecc und cvm bei pnet, ich glaube nicht, dass da irgendwas von mono kam bzw. mono sich was von da genommen hat, könnte mich aber auch irren ;) Aber grundsätzlich sind Kooperationen ja dank Ximian-seite immer gescheitert ;)
Ich will das gar nicht hochspielen oder so, Mono ist sicher interessant für Firmen die propriätäre Software im Unixbereich anbieten wollen, oder auch die Entwicklung von gtk# und vielen anderen Sachen die "eigenständig" sind, aber naja, das ist nur meine Meinung (die zum Glück viele mit mir Teilen, aber das heißt ja noch lange nicht, dass sie richtig ist *g*). Außerdem wird es ja in Zukunft 2 "Pakete" von mono geben, einmal als komplettes Paket und einmal nur wirklich "freie" Sachen, das ist ja was schönes, worauf man sicher aufbauen kann. Das ändert aber leider trotzdem nichts, dass mono für viele immer noch (aus Personeller Sicht) einen unmoralischen Beigeschmack haben wird, aber im Grunde ist das ja (fast) egal
warum soll jetzt aufeinmal c# genommen werden fuer projekte und nicht ruby oder python?
was ist toll an .net? bzw was ist das ueberhaupt?
sollense mal machen.
olli
Laut Miguel ist die Sprache C ja tot...
Warum?
http://slashdot.org/article.pl?sid=04/03/12/0146248&mode=thread
Miguel de Icaza and the Mono team recently hosted a two day open meeting in
Boston. O'Reilly have just published my report of the meeting. Highlights
include Miguel's view that 'C is dead!' and the Mono approach to dealing with
Microsoft patents on .NET."
Gut dass die GNOME Leute das auch mal einsehen. Einen Kernel kann/muss man vielleicht in C schreiben aber bei GUIs wirds doch recht mühsam und fehleranfällig.
fällt ihm vielleicht etwas spät ein, nachdem er jahrelang (erfolgreich) versucht hat eine Desktop in C zu programmieren...
Gruß
Mike
Nach ihren FAQ soll Mono zwar .NET-kompatibel sein, aber auch eigene Standards beinhalten/ plattform-übergreifend zugänglich machen.
Qt läuft nicht unter Windows? Das ist mir neu.
:D
Zum Thema Ruby/Python: Warum ins Mittelalter zurück ? Python ist für Scripts toll, aber mit (OO-)Programmierung hat das nichts zu tun.
Mono / .NET ist ebenso interpretiert wie Java es läuft eine verdammt ähnliche Technik dahinter und .NET ist in sehr vielen Fällen deutlich langsamer als java... ( das Vorurteil Java sei langsamer sollte entkräftet sein wenn man sich mal Benches anguckt wie schnell Java dynamische Arrays hantiert.. das kann Java nämlich sogar noch schneller als C++ )
Für alle die glauben Java sei keine Alternative.. die sollen sich doch bitte mal Eclipse anschauen... native Widgets ( dank SWT ) schnell, stabil, komplex und ein absolut gigantisch gutes IDE....... ( ich kenne keine IDE die Eclipse überlegen ist.. schon gar nicht Visual Studio .NET..... )
Ich finde Mono ist ein Schuss in die falsche Richtung Java wäre die bessere Lösunge gewesen.. ( und es ist auch schöner zu programmieren ich habe mit beidem sehr viel beruflich gearbeitet und gerade C# hat einfach so ein paar "eigenheiten" die den wirklich sehr schönen ( wenn auch nicht perfekten ) Programmierstil von Java brechen )
Hätte Icaza sich auf Java eingeschossen hätten wir jetzt schon viel länger ein stabile Sammlung an GTK Bindings ( gnome-java ist schon weit ) einen perfekt funktionierenden gcj sowie eine super Java IDE mit Eclipse...... aber nein Icaza musste ja unbedint Microsoft hinterherdackeln ( und ja ich bin mir bewusst das die .NET Technologie etwas feines ist.. aber so VIEL feiner als Java ist es auch nicht und Java kann sich auch noch weiterentwickeln und die kleinen Schwächen ausmerzen )
Gruß
Waldgeist
Gruß
Mike
Nicht wirklich
Visual Studio ist schon ein anderes Kaliber. Eclipses CDT kommt nicht im entferntesten an die Möglichkeiten von VStudio heran. Der Java-Support ist ganz ordentlich und das ganze ist ziemlich modular, das war es dann aber auch schon bei Eclipse.
Im Gegensatz zur lächerlichen SCO-Abmahnwelle hat MS dann wirklich was auf der Hand und Linux versinkt in der Bedeutungslosigkeit.
Was Mono an geht bin ich gespannt und wenn es die Entwicklung auf dem Desktop voranbringt, dann ist das prima. Gerade die Vielfältigkeit hat Linux und OpenSource bislang ausgezeichnet
Eigentlich ein guter Programmierer - aber ein A* IMHO ...
Geht da die Entwicklung einigermaßen voran?
Warum überhaupt zwei Projekte mit (oberflächlich betrachtet) dem gleichen Ziel?
Könnte man da nicht mehr zusammenarbeiten?
Normal ist ja gerade der Vorteil von Freier Software das nicht jeder das Rad für sich erfinden muß...
Das einzige, was DotGNU zusätzliches an Widget-Libraries bietet ist deren Windows-Forms Implementierung.
Wärend DotGNU sie auf der Basis vom puren X11 erstellt, versucht Mono es mit WINE als Grundlage (und als weiteres Miniprojekt mir Gtk+ als Grundlage für Winforms).
Aber das Hauptziel von Mono ist - im Gegensatz zu DotGNU - auch nicht die Winforms alle nachzuentwickeln, sondern eine schöne Entwicklungsplattform für Linux/Unix zu entwickeln. Daher sind sie hauptsächlich an GTK# dran.
Abgesehen davon läuft GTK# ebenfalls sowohl auf Linux/Unix, als auch auf MS-Windows, als auch auf MacOS X und anderen Plattformen.
Leider is C jedoch nicht tot sondern wird immer noch missbraucht anstelle C++ zu nehmen.
Afensprachen, was für eine Wortwahl.
> ich programmiere schon seit jahren mit c++
Oh, sogar was objektorientiertes (wenn man will). Ich nehme mal an, Du meidest diesen ganzen blödsinnigen STL-Kram und so Sachen wie beispielsweise new und delete und benutzt stattdessen noch malloc und free.
Um die volle Kontrolle über den Code zu haben (s.u.). Gleiches bei Strings, denn die string-Klasse ist nix für wahre Programmierer. Da kann man gar nicht mehr so schöne Buffer Overflows produzieren, die man dann hinterher suchen darf. Wie langweilig.
> hardwareunabhängig? wer braucht das?
Ja, klar, Portabilität ist was für Schattenparker. Hauptsache der Code läuft auf meinem Sinclair QL.
> programmierung muss 100 %ige kontrolle üebr den code bieten
Warum nicht gleich Assembler? Das bietet 100%ige Kontrolle über den Code.
Wie schade, dass man nicht gleich jeden Transistor direkt ansteuern kann.
> affensprachen
Meinst Du damit das Gebrabbel, das Du hier von Dir lässt?
=====
und mit affensprachen meine ich sprachen die für leute gemacht sind die zu blöd sind mit pointern und speicherverwaltung umzugehen.
=====
Nicht jeder, der wie du es nennst "Affensprachen" einsetzt und verwendet ist zu blöd, um mit Pointern oder der Speicherverwaltung umzugehen.
Aber das ist dir natürlich alles bekannt.
=====
und stl hat auch nix mit den affensprachen(ich liebe den begriff den er ist für dich wie geschaffen) zu tun. ziel der programmierung muss es sein lösungen zu optimieren und abstrakte sprachen sind hierfür die größte gefahr denn sie nehmen dem programmierer die möglichkeit das program komplett nachzuvollziehen und an den notwendigen stellen zu verfeinern.
=====
"Für die moderne geläufige Auffassung ist eine Sprache die virtuelle Sprache: man spricht Sprachen (also realisiert man sie im Sprechen), man kann Sprachen. Und für den Sprachwissenschaftler ist gewöhnlich eine Sprache die abstrakte Sprache, die Sprache, die er selbst vom Sprechen abstrahiert hat."
C# und Java sind also abstrakte Sprachen?
Ebenso wie Perl, Python und Ruby?
Und was soll dich als Programmierer daran hindern, ein in z.B. Java geschriebenes Programm komplett zu verstehen ("was tut es?") und es eventuell anzupassen bzw. zu optimieren?
Ist es vielleicht schwer, verschiedene Implementierungen von Sortierroutinen (eine gern gemachte Aufgabe für Programmieranfänger) in C#, Java, Perl, Python, Ruby, Tcl, ... selbst zu implementieren, komplett zu verstehen und zu optimieren?
Die tatasache das man den GC nicht abschalten kann, es keine gescheiten templates gibt und das native interface von Java nicht auf portable c++/obj-c bibliotheken ohne grosse Umstände zugreifen kann. zum Beispiel.
C++/Obj-C/Pascal/Fortran kann man mischen. Java/Perl und andere "Affensprachen" können die bibliotheken nicht nutzen und können deshalb nicht mithalten.
Die tatasache das man den GC nicht abschalten kann, es keine gescheiten templates gibt und das native interface von Java nicht auf portable c++/obj-c bibliotheken ohne grosse Umstände zugreifen kann. zum Beispiel.
=====
Ok, es gibt bei Java und C# eine GarbageCollection. Die gibt es allerdings auch für das so populäre VisualBasic. So what? Wenn die GC stört, dann verwende halt eine Programmiersprache/-umgebung wo es keinen GC gibt. Wie wäre es mit Assembler, C, C++, Obj-C, Obj-C++, Pascal, Object-Pascal, ...
=====
C++/Obj-C/Pascal/Fortran kann man mischen. Java/Perl und andere "Affensprachen" können die bibliotheken nicht nutzen und können deshalb nicht mithalten.
=====
Das ist eine Einschränkung des verwendeten Compilers und nicht eine Einschränkung der verwendeten Programmiersprachen als solches.
Desweiteren kannst du durchaus von Java (Stichwort: JNI) oder Perl (Stichwort: PerlXS) heraus Funktionen aufrufen die du vorher in Shared Libraries abgelegt hast.
IIRC kann man selbst aus Python, Ruby und Tcl heraus auf Shared Libraries zurück greifen.
Nein, man kann wunderbar in C++ programmieren, ohne von z.B. von malloc, free und char*-Vodoo nur die geringste Ahnung zu haben. Wozu gibt es new, delete und std::string...
> sprachen die für leute gemacht sind die zu blöd sind mit pointern und speicherverwaltung umzugehen.
Haha, deshalb liest man auch ständig, dass in der mit C entwickelten Software XY mal wieder ein Buffer Overflow entdeckt wurde und Anwendungen verabschieden sich mit Segfault (meistens GTK/Gnome-Anwendungen, woher kommt das nur).
Und das alles oft nur, weil sich da jemand mal wieder zu stur war, einzusehen, dass nicht jede popelige GUI-Anwendung nicht in ANSI C geschrieben werden muss.
> ziel der programmierung muss es sein lösungen zu optimieren
Nur wo es notwendig ist. Beim Linux-Kernel würde ich auch kein Python einsetzen, klar.
Anderseits würde ich z.B. eine IDE im Leben nicht in C entwickeln.
Zum Optimieren:
Ich halte es da mit dem Verfasser des Artikels "Optimization: Your Worst Enemy":
http://www.codeproject.com/tips/optimizationenemy.asp
(der Artikel hat nix mit MS oder .NET zu tun, die originale Seite gibts nicht mehr).
> ich liebe den begriff den er ist für dich wie geschaffen
Freundchen, Du bestätigst gerade mal wieder wunderbar das Klischee vom Low-Level-Fanatiker. Scheuklappen, pseudo-elitäres Dummgelaber, sozial inkompetent und diskussionsunfähig.
> programmierung muss 100 %ige kontrolle üebr den code bieten
>
Die Programmierung ist das Programm und das hat nur seltenst die 100%ige Kontrolle -- geschweige denn überhaupt eine Art von Kontrolle -- über den (Quell-? oder Maschinen-?) Code, sondern das Programm folgt einfach stupide seiner Programmierung: seinem Code.
Der Programmierer selbst hat i.d.R. auch keine 100%ige Kontrolle über den (Maschinen-)Code, da er ja heutzutage bevorzugt in $HOCHSPRACHE programmiert und somit die Kontrolle einem Programm (dem Compiler) überlässt, das den (Quell-)Code des Programmierers analysiert, ggf. optimiert und letztendlich in (Maschinen-)Code übersetzt. Ausnahmen sind, wenn der Programmierer selbst in $MASCHINENSPRACHE programmiert. Nur in diesem Fall besitzt er die 100%ige Kontrolle darüber, wie sein Quellcode in Maschinencode übersetzt wird.
Verschiedene Anwendungsfälle, verschiedene Werkzeuge.
Oder programmier mal ein Webportal mit C, viel spass
Auch wenn ich eigentlich nicht auf solche Kommentare antworte, zwei Anmerkungen kann ich mir nicht verkneifen:
Affensprachen - Du subsumierst unter diesem Begriff keine Sprachen, sondern die Unterscheidung von grob gesagt interpretierten Programmen (in einer "Affensprache" verfasst) und nativ übersetzten Programmen (in einer "Hundesprache?" verfasst)... Dabei übersiehst Du völlig, das die Performance von C Programmen durch native Übersetzung nur bedingt mit der Sprache als solche, sondern vielmehr mit der Übersetzung zu tun hat. Theoretisch wär's kein Problem ein Programm in einer "Affensprache" mit einem geeigneten Compiler nativ zu übersetzen.
Zum anderen scheinst Du noch nie bemerkt zu haben, das die von Dir als "Affensprachen" gebranntmarkten Sprachen genauso Turing-Complete sind (und das ist sogar Brainfuck), wie Dein favorisierter C++ Dialekt.
> java code(und andere) muss erst von eine virtualmachine in machinecode
> übersetzt werden das allein sorgt für erhebliche geschwindigkeitseinbußen.
Und was macht das für einen Unterschied? Selbst ein 500 MHz-Rechner bringt bei den meisten Anwendungen noch einen Großteil mit dem Warten auf Benutzereingaben zu. Ausserdem ist der Aufwand, in einer Scriptsprache zu programmieren, in der Regel deutlich geringer, der Programmierer schafft also mehr in weniger Zeit. Und die meisten Scriptsprachen lassen sich einfach in C/C++ erweitern, so kann man zeitkritische Routinen optimiert in C schreiben und den Rest in der Scriptsprache schreiben.
Dieses Prinzip hat sich sogar in der Spielebranche durchgesetzt, wo man doch eigentlich immer noch Hochleistung von den Rechnern erwartet. So ist z. B. EVE-Online in Stackless-Python geschrieben, Monkey Island ist in Lua geschrieben (siehe die Luabar ;)), genauso FarCry.
Ich finde das Programmieren in Ruby beispielsweise einfach sehr angenehm, und ich habe längere Zeit C programmiert und auch in Java und C++ reingeschnuppert. Es ist zwar nicht für jeden Anwendungsfall etwas, aber doch für erstaunlich viele Sachen geeignet. Aber wer nicht über den Tellerrand schauen will, muss halt in seinen Vorurteilen versauern. ;)
iGEL
Werbung -> www.rubyforen.de
Das kann man pauschal nicht sagen. Es gibt auch sehr wohl viele Situationen, bei denen die Geschwindigkeit zwar spürbar geringer ist, aber dennoch der Vorteil der gesteigerten Flexibilität überwiegt.
Zumal in vielen Situationen auch andere Faktoren wichtig sind: Festplatten Zugriffszeit, Netzwerkgeschwindigkeit (Durchsatz und Latenz), vorhandene "Spezial"-Hardware
"wie half life doom3 etc. drauf verzichten"
Mag sein, aber bisher scheint weder Doom3 noch HalfLife der UT Engine überlegen zu sein. Und Far Cry ebensowenig.
"ist ut im vergleich zu anderen spielen langsamer"
Das kann ich garnicht bestätigen. Bei mir läuft UT genauso gut oder schlecht wie andere Spiele vergleichbarer Grafik auch (2GHz Athlon, ATI 9500Pro, 512 MBRam, diverse HDDs)
"wer zu weit iüber den tellerrand guckt fällt runter"
Sehr schöner Satz .... also viel Spaß in deiner Suppenschüssel
jetzt muß ich da mal einschreiten. Deine Meinung in Ehren, aber "Affen" und "Gebärdensprache" in abwertenden Aussagen einzubinden ist gar nicht in Ordnung.
Ich kann die Gebärdensprache soweit, daß ich mich mit Gehörlosen unterhalten kann. So kenne ich die Unterschiede zwischen der Lautsprache und der Gebärdensprache. Ein Punkt ist in diesem Zusammenhang sehr prägnant:
Mit der Gebärdensprache kann ein Satzinhalt schneller von Person zu Person übermittelt werden, als mit der Lautspreche -> es geht schneller!
Kurzum: Gehörlose können innerhalb eines gleichen Zeitraums mehr Informationen übermitteln als Lautsprechende.
Das liegt daran, weil zur Kommunikation neben der Gestik bzw. Gebärden auch die Mimik eingesetzt werden. Kurz gesagt, bei der Gebärdensprache werden MEHR Mittel (= bewußter Einsatz nichtsprachlicher Signale) zur Kommunikation eingesetzt, als mit der Lautsprache, bei der überwiegend nur gesprochen wird.
Wenn man schon die Gebärdensprache / Lautsprache mit Programmiersprachen "vergleicht", dann wäre es durchaus im Sinne des Programmierers, wenn sich Programmiersprachen in weiten Teilen an die Gebärdensprache "anlehnen" würde.
Denkt doch alle mal bitte darüber nach. Ich stehe gerne zur Verfügung.
Servus,
Tops
jetzt muß ich da mal einschreiten. Deine Meinung in Ehren, aber "Affen" und "Gebärdensprache" in abwertenden Aussagen einzubinden ist gar nicht in Ordnung.
Ich kann die Gebärdensprache soweit, daß ich mich mit Gehörlosen unterhalten kann. So kenne ich die Unterschiede zwischen der Lautsprache und der Gebärdensprache. Ein Punkt ist in diesem Zusammenhang sehr prägnant:
Mit der Gebärdensprache kann ein Satzinhalt schneller von Person zu Person übermittelt werden, als mit der Lautsprache -> es geht schneller!
Kurzum: Gehörlose können innerhalb eines gleichen Zeitraums mehr Informationen übermitteln als Lautsprechende.
Das liegt daran, weil zur Kommunikation neben der Gestik bzw. Gebärden auch die Mimik eingesetzt werden. Kurz gesagt, bei der Gebärdensprache werden MEHR Mittel (= umfassender Einsatz nichtsprachlicher Signale als Ersatz für die Lautsprache) zur Kommunikation eingesetzt, als mit der Lautsprache, bei der überwiegend nur gesprochen wird.
Wenn man schon die Gebärdensprache / Lautsprache mit Programmiersprachen "vergleicht", dann wäre es durchaus im Sinne des Programmierers, wenn sich Programmiersprachen in weiten Teilen an die Gebärdensprache "anlehnen" würde.
Denkt doch alle mal bitte darüber nach. Ich stehe gerne zur Verfügung.
Servus,
Tops
Da sieht man, was rauskommt, wenn Leute zu schnell schreiben, ohne ihr Gehirn einzuschalten.
Die Gebärdensprache ist zusätzlich noch 3D orientiert und verfügt eigentlich über wesentlich mehr Ausdrucksmöglichkeiten als unsere Sprache. Oder kannst du ein gesprochenes Wort tanzen???
Ansonsten stimme ich TOPS in allen Punnkten nachdrücklich zu!
Gruss
UK
wie auch immer - irgendetwas das von M$ kommt, nachzuprogrammieren, ist von vornherein zum scheitern verurteilt - es wird immer hinterherhinken, und falls es mal doch eigenständig und zu einer gewissen gefahr zu werden droht, schiebt bill dem ganz schnell nen riegel vor....
...Mono muss *nicht* MS kompatibel sein um eine Bereicherung fuer die Open Source Bewegung zu sein.
Beim GNU/Pascal Compiler (oder FreePascal) hat ja auch keiner gemeckert.
Ditto beim GNU Compiler for Java oder beim Guavac Projekt. Java mit seiner VM ist ja auch nicht so vom Himmel gefallen, sondern wurde von einer Closed-Source Company quasi "erfunden".
IMO vollzieht die Free Software Community mit Mono und Dot-Gnu genau das, was damals bei Java versäumt wurde: Eine komplett freie (und bessere) Implementierung basierend auf verfügbaren Spezifikationen.
Die Ähnlichkeiten von C# und Java sind ja durchaus vorhanden trotzdem scheint mir das Mono/Dot-Gnu/.Net Zeugs doch durchaus performanter zu laufen im Vergleich zu Java Programmen. Lässt man mal Microsofts Windows-only .Net Runtime + Erweiterungen aussen vor und betrachtet nur die freien Implementierungen dann ist es doch schön zu sehen, dass von vornherein VMs und Compiler für verschiedene Betriebsysteme (Unix, Linux, MacOSX, Windows) und Rechnerplattformen (x86, Sparc, PowerPC) entwickelt werden.
Mono und Dot-Gnu könnten durchaus das Zeug dazu haben, im FreeSoftware und UNIX Bereich Java den Rang abzulaufen. Umso mehr, als dass die JIT und VM Performance gegenüber der Java VM nicht ins hintertreffen gerät.
Anmerkung zu Samba:
Hat nicht ein Vergleichstest ergeben, dass die Version 3 von Samba sich performace-mässig selbst vor dem Microsoft Windows Server 2003 nicht zu verstecken braucht? Ihn im Gegenteil sogar im Regen stehen lässt? Wollt das ja nur mal so am Rande bemerken
Wer weiss... vielleicht denkt ja Icaza insgeheim an ein Gnome auf .NET basierend. Wäre zumindest keine so uninteressante Geschichte ;)
Wem es nicht gefällt wird Mono sowieso nicht nutzen. Wenn es keinem gefällt wird das Projekt halt untergehen. Zumindest ist C# eine recht durchdachte Sache und mit dem entsprechenden GUI-Klassen lassen sich hier recht schnell GUI-Anwendungen zusammenbauen.
Seit einen Jahr arbeite ich mit .NET. Man muss schon zugegeben es ist vollständiger und ausgereifter als alles was es vorher war.
Mono ist ein Segen für Open Source, weil es eine wichtige technologische Entwicklung nicht verpasst wird. Selbstverständlich kann man immer noch in C programmieren aber es ist zu unwirtschaftlich. Nur wenige verstehen C++ gut genug um damit sichere Programme zu schreiben. C und C++ wird wahrscheinlich nur bei Treiber oder Kernel verwendet. Mit dem Kommen von Longhorn wird man es merken, dass Linux auf einer 20 veralteten Technologie aufsetzt, die für Unternehmenanwendungen nicht ausreichend ist. Es wird stabil aber es wird auch keine Konkurenz mehr. Es wird wieder das was es war, nur ein Hobby-Informatiker-Spielzeug.
Die Hoffnung für mich sind noch die moderne Skriptsprachen wie Python, Ruby oder Tcl (XOTcl). .NET ist sehr gut als eine Richtung an der man sich orientieren kann. Es ist besser .NET nachzuprogrammieren und Open Source machen (wie es bei anderen erfolgreichen Projekten schon immer war) als zu versuchen in mehreren 100 Projekten einen dritten Weg zu finden.
Dann kam C. Was die Leute davon halten lesen wir gerade hier. Dann kam ADA. Wir alle wurden zu den Schulungen geschickt, da die US-Verteidigungsministerium dahinter stand - wird sich sicher weltweit durchsetzen - erzählte das Management.
Danach Objektorientierung. Alles wird besser, endlich werden Programme ohne Fehler herstellbar. Fehlanzeige. Dann kam die Komponenten-Era - zuerst vbx. Alles wird Komponente, wieder Schulungen und alles neu schreiben. Hielt nicht lange, kam ocx. Dann Java. Alles wurde geschult - endlich einmal schreiben und ueberall benutzen. Von Big-Iron bis zur Kaffeemaschine. Und nun .NET.
Ich bin müde.
Wo? ;)
Im Ernst: Ich lerne gerade meine 7. Sprache (Javascript nicht mitgerechnet) seit meinen Anfängen im Programmieren vor 10 Jahren, und man nimmt doch überall Erfahrung mit, die man wieder brauchen kann. Erst wenn man eine Sprache kennt halbwegs kennt, kann man abschätzen, für was sie sich eignet und für was nicht. Und es ist ja nicht so, dass Java oder .net nicht eingesetzt werden würden. Nur dauert es halt alles viel länger, als uns manche Marketingabteilung glauben machen will und nur die Hälfte bewahrheitet sich. Ich will aber auch nicht mehr in Comal 80 oder Turbo Pascal programmieren. Von daher kann ich das Gejammer nicht verstehen.
iGEL
Ich kann jeden Schraubenzieher ruinieren, wenn ich ihn als Meisel verwende, genau das ist auch bei den Programmiersprachen möglich.
Aber es gibt einfach Werkzeuge, die sind bei ordnungsgemäßer Anwendung besser als andere. Dazu gehören mit Sicherheit Sprachen wie Java und C#.
Programme ohne Fehler ist keine Frage der Programmiersprache. Aber es gibt Unterschiede, was die Wartbarkeit von Code angeht. Da dürfte Assambler und C vergleichsweise schlecht abschneiden.
Warum nimmst Du lieber C als z.B. C++?
(ernstgemeinte Frage)
Kann auch OO und ist Modular.
> Kann auch OO und ist Modular.
Ich halte vom neuen ICE auch nichts. Fahre lieber weiter meinen Golf. Fährt auch schnell und ist vom Verbrauch her sparsam.
es scheint ja bei jeder News immer wieder vorzukommen, dass Leute fragen, wo denn jetzt der Unterschied zwischen
Mono und DotGNU liegen, oder was es mit Miguel de Icaza auf sich hat (Ich habe z.B. ein paar Kommentare weiter oben
wüste Beschimpfungen ihm gegenüber gelesen). Ob das jetzt "Rudelschimpfen" oder eigene Erfahrungen sind lasse ich mal dahingestellt, aber ich persönlich halte nicht viel Mono und dem ganzen dahinter (auch wenn es sich sehr schnell entwickelt und mittlerweile viel kann), im Gegensatz zu DotGNU, was meiner Meinung nach ein sehr sehr gutes Projekt ist.
Auf osnews.com war ein Artikel zum 0.6.4 release von DotGNU Portable.NET (kam vor paar Tagen raus) und dieser Kommentar trifft es (meiner Meinung nach) sehr gut, warum man von Mono nicht allzuviel halten kann/könnte und warum Mono evtl. einen negativen Einfluss auf .NET in Unix hat:
http://osnews.com/comment.php?news_id=6335#211141
Der Kommentar drückt das sehr sanft aus, aber man könnte ihn denke ich auch als "10 reasons not to support mono" oder "why mono destroys the .NET/Unix vision" bezeichnen ;)
Auch wenn das für manche wie ein flame klingt, das ist absolut nicht meine Absicht, ich sehe das einfach nur genauso wie es z.b. in dem Kommentar auf osnews.com dargestellt wird (Und da ich mich schon fast 2 Jahre mit DotGNU/Mono beschäftige kann ich euch versichern, dass das nicht aus der Nase gezogen ist was da steht)
möglicherweise, weil Du den Kommentar dort selber gschrieben hattest?
Auf jeden Fall schrieb ihn jemand aus Deutschland (siehe dort die IP-Adresse).
Doch nun zu den entsprechenden Punkten zu Deinem Link:
zu 1:
man muß es so sehen: weil Mono eine Firma hinter sich stehen hat, geht die Entwicklung schneller voran als bei DotGNU.
Ansonsten dürfte es doch kaum jemanden stören, daß eine Firma dahintersteht. Die Lizent von Mono ist doch OpenSource. Bei OpenOffice.org stört doch auch keinen, daß eine Firma dahintersteht.
zu 2:
Ich habe keine Probleme dort bemerkt. Der Vorteil von dem in C# geschriebenen C#-Compiler ist, daß er nicht mit portiert werden muß (ähnlich wie bei Java, wo der Java-Compiler auch in Java geschrieben wurde). Außerdem ist es konsequenter. Miguel erwähnt immer die Vorteile von C# gegenüber C, also ist es nur konseqent, wenn er auch möglichst viel (und somit auch den C#-Compiler) in C# schreibt.
zu 3:
Der JIT-Compiler von Mono läuft auf x86, Sparc und PPC. Für andere Systeme müßte er bloß portiert werden. Doch dafür laufen Programme auf Mono nun mal auch schneller als auf DotGNU.
Desweiteren kann man auch den Mono-Interpreter verwenden. Dort ist die Portierungsarbeit nicht ganz so groß. Und einen Mono-Interpreter guibt es auch für StrongARM.
zu 4:
> Miguel de Icaza said if Microsoft ever wants to have money for an API or
> whatever of .NET, Novell is going to pay for it
wann und wo hat Miguel das gesagt? (ein Link wäre nett)
zu 5:
Richtig. Viele Codeteile von Mono wurden neu geschrieben. Und mit dadran gearbeitet hat u.a. Dietmar Maurer, Martin Baulig und andere.
zu 6:
Dann guck mal hier.
Man kann nicht sogenau sagen, wer zuerst angefangen hat, eine .NET-Implementierung zu entwickeln.
Abgesehen davon arbeiten DotGNU und Mono bei den Bibliotheken derzeit eng zusammen.
DotGNU verwendet Mono-Bibliotheken und umgekehrt. Wobei ersterer Weg - daß DotGNU von Mono nimmt - weit aus häufiger vorkommt.
Aber auch beim Compilerbau und JITter-bau nimmt jeder - jeweils mit der Erlaubnis des anderen - von jedem.
zu 7:
Ximian guckt vorrangig zu der Entwicklungsplattform.
Aber das Mono-Projekt selbst ist zu allen Seiten hin offen.
zu 8:
Die einzige Auseinandersetzung die ich kenne war, daß Ximian eine zusätzliche Mailingliste Namens Ximian-hackers oder so eingerichtet hatte, die vorrangig nur Leute aus dem Mono-Core-Team aufnimmt. Dieses Mono-Core-Team beinhaltet jedoch nicht nur Ximian-Entwickler. Ist jedoch trotzdem eher eine etwas Ximian-interne Mailingliste.
Für die Öffentlichkeit und für sämtliche Mono-Entwickler allgemein gibnt es Mono-devel. Und auch die Mono-Entwickler schreiben dort vorrangig rein.
zu 9:
das einzige Argument dem ich mich anschließen kann. Ist schon etwas blöd, daß man für die Mono-Minimalinstallation (also ohne GTK# oder System.Windows.Forms) glib und andere Bibliotheken installiert haben muß.
zu 10:
Mit "C is dead" meinte Miguel die Entwicklung von neuen C-Programmen.
Damirt meinte er jedoch nicht Programme, die C zu IL kompilieren.
Wenn ich mich recht erinnere, gibt es sogar ein GCC.net-projekt, daß Miguel gerne erwähnt. Verständlicherweise kann er nicht überall sein und er kann nicht an allen Projekten teilhaben. Daher wirkt er selber an Mono mit. Findet aber Entwicklungen wie GCC.net (welches die gesamten GCC-Sprachen wie gcc, g++, g77) für die .NET-Platform kompiliert als lobenswert. Genauso den LCC, der C zu IL kompiliert. Das selbe gilt für Java. Miguel lobt das IKVM-Projekt. Doch im Gegensatz zu DotGNU arbeitet Mono nicht selbst an einem Java. DotGNU erstellt von allem ein Bischen. Mono erstellt in erster Linie die Plattform, den Rest überläßt es anderen.
Aber jetzt egal, zu deiner Frage Nr 4:
(war in einer Diskussion um Bereiche, die eventuell durch Patente in den USA gefährdet sind, da die Diskussion von einem DotGNU Mitglied angestoßen wurde habe ich das sogar noch einigermaßen in erinnerung [nach dem link habe ich aber ehrlich gesagt gerade ge-google'ed, aber gibt ja ne thread ansicht)
http://archive.neotonic.com/archive/mono-list/messages/16144?noheader=1
Das was du bei 6. sagst wäre mir neu, es stimmt, dass einige Sachen ausgetauscht wurden (Mono hat z.b. vor ner zeit das i18n Zeug von pnet übernommen, pnet hat die regex implementierung und sogar ein eigenes paket "ml-pnet" wo mono bibliotheken drin sind, die auch mit pnet funktionieren) aber die runtime und compiler haben oft große unterschiede (z.b. treecc und cvm bei pnet, ich glaube nicht, dass da irgendwas von mono kam bzw. mono sich was von da genommen hat, könnte mich aber auch irren ;)
Aber grundsätzlich sind Kooperationen ja dank Ximian-seite immer gescheitert ;)
Ich will das gar nicht hochspielen oder so, Mono ist sicher interessant für Firmen die propriätäre Software im Unixbereich anbieten wollen, oder auch die Entwicklung von gtk# und vielen anderen Sachen die "eigenständig" sind, aber naja, das ist nur meine Meinung (die zum Glück viele mit mir Teilen, aber das heißt ja noch lange nicht, dass sie richtig ist *g*).
Außerdem wird es ja in Zukunft 2 "Pakete" von mono geben, einmal als komplettes Paket und einmal nur wirklich "freie" Sachen, das ist ja was schönes, worauf man sicher aufbauen kann.
Das ändert aber leider trotzdem nichts, dass mono für viele immer noch (aus Personeller Sicht) einen unmoralischen Beigeschmack haben wird, aber im Grunde ist das ja (fast) egal