Was ich interessant finde ist, dass Mono als große Entwicklungsplattform für den GNOME Desktop angesehen wird, während Java mit Java-GNOME dem ganzen doch gar nicht nachsteht.
Obwohl es Java und Java-GNOME schon seit Ewigkeiten gibt hat doch früher keiner einen solchen Hype darum gemacht, dass man mit Java Anwendungen für den GNOME Desktop schreiben sollte. Jetzt taucht auf einmal Mono mit C# auf und auf einmal wird es von einigen als das Non-Plus-Ultra geworben.
Ist das lediglich Marketing? Oder taugt Mono mit C# tatsächlich soviel mehr, als Java mit Java-GNOME? Ich versuche gerade Java-GNOME einzurichten und werde mal versuchen mir selbst ein Bild davon zu machen.
Die Sprache Java kenne ich bereits und C# habe ich mir auch einmal angeschaut und die Unterschiede halten sich ja stark in Grenzen. Was das Lizenzproblem angeht, so sehe ich da keinen großen Unterschied zwischen Mono und Java. Beide bewegen sich IMHO in einer Grauzone, wo man nicht genau weiß, ob das rechtlich so einwandfrei ist.
Fedora setzt eben primär auf Java, während Novell stark in Mono investiert. Was davon Sinn, oder Unsinn ist kann wohl keiner sagen, das wird die Zukunft zeigen.
In Java geschriebene GNOME Anwendungen habe ich bisher eher wenige gesehen. Aber auch Anwendungen in C# mit Mono sind eher schwach vertreten. Jedoch gibt es einige große Anwendungen, wie Beagle und F-Spot, was man bei Java-GNOME nicht findet.
Würde mich über ein paar Informationen diesbzgl. freuen.
Java? Mono? C#? Ich schreibe meine GNOME-Apps in PERL Irgendwie ist mir gtk_get_my_stupid_little_function...wurzelbrunft in C(!) zu unübersichtlich. Noch dazu kommt, dass ich weder C noch C++, ergo auch kein Java / C# kann. Was ich aber eigentlich mal zum Ausdruck bringen will, ist, dass man doch inzwischen mit jeder x-beliebigen Sprache GNOME-Applikationen schreiben kann und das finde ich schon ziehmlich cool. :) Vielleicht habe ich ja Deine Frage hinsichtlich der Vielfalt etwas beantwortet... (jedem das seine). Gruß
Letztlich alles eine Frage des persönlichen Geschmacks. java-gnome sind nicht nur Gtk+ bindings für java, sondern gehören auch zu den "GNOME Platform Bindings", d.h. sie sind immer sehr aktuell und nahe an der aktuellen GNOME/Gtk+ Verison, was man von gtk# noch nicht sagen kann. Auf der anderen Seite gibt es gtk# für windows, bei gnome-java sieht es da afaik nicht so gut aus. Ausserdem hat java imho den "Nachteil", dass es für viele Systeme eine Sun implementierung gibt. Es ist also relativ schwer Java-Programmierer von der Verwendung von gnome-java zu überzeugen wenn sie auf der anderen Seite mit Sun java und den entsprechenden Toolkits alles haben was sie brauchen. Mono ist dagegen eine in sich abgeschlossene Plattform die du komplett für GNU/Linux und komplett für windows bekommst und dann beidesmal deine C# (Gtk#) Programme darauf laufen.
java vs c#: Von Leuten die beides gut kennen hört man immer wieder das c# aus den Fehlern von java gelernt hat und viele kleine Sachen besser/schöner macht. Manche nennen auch als Vorteil von C#, dass es nicht nur Referenztypen gibt, sondern auch Wertetypen es ist also nicht alles ein Objekt welches auf dem Heap liegt sondern es gibt auch eine ganze Reihe von Wertetypen die ganz normal auf dem stack abgelegt werden können.
Mono ist, laut Aussage von vielen Entwicklern, viel sprachunabhängiger als Java. D.h. du kannst eine ganze Reihe von Programmiersprachen auf Mono verwenden, dass passt halt schön zu dem Programmiersprachenunabhängigen paradigma das gnome schon immer verfolgt hat. Schau dir auch mal die Demos dazu an: http://primates.ximian.com/~lluis/blog/pivot/entry.php?id=38
Das macht auch die Arbeit einfacher, da du z.B. nur einmal Gtk+ Sprachbindings für Mono erstellen mußt und kannst diese dann mit jeder Sprache verwenden die auf Mono läuft, du brauchst also nicht für alle Sprachen extra Bindings und libs. Das einfache einbinden von C libs/programmen soll auch ein Vorteil von c# sein (p/invoke). Ausserdem ist die CLI und C# ein offener Standard an dem u.a. auch Novell mitarbeitet. Man muß also nicht schauen was einer macht und dann hinterherrennen, sondern man kann die Richtung selber steuern und verfolgen.
Lange Rede kurzer Sinn. Mono und C# scheinen für viele Programmierer interessante Ansätze zu habe. Java ist deswegen nicht schlechter. Jeder hat seine vorlieben und sollte einfach die Sprache und das Framework nutzen das ihm am besten liegt oder das am besten zur Aufgabe passt.
Gut geschrieben! Was mich an Mono etwas zurueckhaellt ist diese Microsoft-Naehe... man bekommt Dateien die *.exe und *.dll heissen... sicher ist das nur ein aeusserliches Problem, aber ein wenig hemmt mich das schon. Ansonsten waere ich eigentlich ziemlich an Mono interessiert...
XML Schemas sind ja auch von Microsoft und so lange Microsoft richtige Standards definiert und diese öffentlichen Stellen übergiebt, können die noch vieles Entwickeln.
"Jeder hat seine vorlieben und sollte einfach die Sprache und das Framework nutzen das ihm am besten liegt oder das am besten zur Aufgabe passt."
Tja.. wenn das so einfach waere. Wenn du in ein projekt kommst wo seit 10 jahren Tcl/Tk gemacht wird hast du so ein kleines "ueberzeugungs" problem wenn du da mal eben die sprache wechseln willst.
Selbiges gilt wenn dir dein arbeitgeber vorschreibt was du zu nehmen hast. Auch wenn dies aus technischer sicht totaler bloedsinn ist. Z.B. Java fuer GUI apps.
Java eignet sich für GUI Applikationen auch sehr gut, aus meiner Erfahrung möchte ich das Toolkit SWT aus dem Eclipse-Projekt nennen, mit dem man schön GUI-Programme schreiben kann. Wer will, kann auch QT-Programme mit Java bauen, entsprechende Bindings gibt es.
> Von Leuten die beides gut kennen hört man immer wieder das c# aus den Fehlern von java gelernt hat > und viele kleine Sachen besser/schöner macht.
Hab ich auch schon gehört :-)
> Manche nennen auch als Vorteil von C#, dass es nicht nur Referenztypen gibt, sondern auch Wertetypen > es ist also nicht alles ein Objekt welches auf dem Heap liegt sondern es gibt auch eine ganze Reihe > von Wertetypen die ganz normal auf dem stack abgelegt werden können.
Auch wenn durch deine Aussage jetzt nicht ganz klar ist wer auf den Stack kommt - sicherlich eine gute Idee
> Mono ist, laut Aussage von vielen Entwicklern, viel sprachunabhängiger als Java. D.h. du kannst eine > ganze Reihe von Programmiersprachen auf Mono verwenden, dass passt halt schön zu dem > Programmiersprachenunabhängigen paradigma das gnome schon immer verfolgt hat. Schau dir auch mal die > Demos dazu an: http://primates.ximian.com/~lluis/blog/pivot/entry.php?id=38
Sicher kein Nachteil aber auch kein soo grosser Vorteil. Praktisch ist ja dann eh fast alles in C# was auch gut so ist - denn dann können auch andere den Code verstehen.
> Das einfache einbinden von C libs/programmen soll auch ein Vorteil von c# sein (p/invoke).
Sehr gut und wichtig. Java ist da ein Albtraum (mal CNI ausgenommen, das afaik bisher nur mit GCJ funktioniert)
> Ausserdem ist die CLI und C# ein offener Standard an dem u.a. auch Novell mitarbeitet. Man muß also > nicht schauen was einer macht und dann hinterherrennen, sondern man kann die Richtung selber steuern > und verfolgen.
Naja. Standardisiert wurde soviel ich weiss das Zeugs für .NET 1.0 oder so und die Weiterentwicklung macht Microsoft... Ich lasse mich natürlich gerne eines besseren belehren.
Mal ganz abgesehen davon dass bei Java das grosse Problem imo nicht so die fehlende VM sondern die Klassenbilbiothek ist - und die ist bei .NET genau so wenig standardisiert.
> Lange Rede kurzer Sinn. Mono und C# scheinen für viele Programmierer interessante Ansätze zu habe. > Java ist deswegen nicht schlechter. Jeder hat seine vorlieben und sollte einfach die Sprache und das > Framework nutzen das ihm am besten liegt oder das am besten zur Aufgabe passt.
Die Frage ist doch: Wer ist freier in seiner Entwicklung?
Ich habe den Verdacht, dass Mono der .NET-Entwicklung immer hinterher hinken wird. Sobald Mono in irgendeiner Sache aufgeschlossen hat, holt MS schon die nächste Entwicklung hervor. Z.B. WinForms. Jetzt basteln die Mono-Leute daran, die API möglichst vollständig hinzubekommen. Dabei steht mit Avalon schon die Wachablösung bevor.
.NET ist nicht wirklich plattformunabhängig. MS versteht darunter sowieso etwas anderes, nämlich Plattformunabhängigkeit zwischen den verschiedenen Windows-Versionen.
Warum also nicht gleich Java nehmen? Zumal die Software einige Jahr mehr auf dem Buckel hat und daher auch viel ausgereifter ist.
Ich habe den Verdacht, dass Mono der .NET-Entwicklung immer hinterher hinken wird.
würde ich nicht sagen. In einer der letzten Ct's gab es einen Artikel über Mono und .Net nach dem Mono schon eine deutlich vollständigere Implementierung des kommenden Standard 2 hat. Ich würde sagen, beide rennen dem eigen definierten Standard hinterher und dabei scheint Mono zumindest nicht langsammer zu sein.
Sobald Mono in irgendeiner Sache aufgeschlossen hat, holt MS schon die nächste Entwicklung hervor. Z.B. WinForms. Jetzt basteln die Mono-Leute daran, die API möglichst vollständig hinzubekommen.
Du redest vom Kompatibilitätsstack. Der ist ganz nett für Leute die aus der Windows Ecke kommen aber ansonsten total unwichtig. Entscheidend ist die CLI, C#, Gtk#, gst#, gecko#, apache#,... Das ist das Framework welches Mono aus macht und nicht der Kompatibilitätsstack der nur eine kleine Zugabe für die windows Leute ist und sicher nie 100% erreichen wird.
.NET ist nicht wirklich plattformunabhängig.
.Net nicht, Mono dagegen schon sehr gut. Leider werfen Leute immer viele Sachen zusammen ohne sinnvoll zu unterscheiden was was ist.
Warum also nicht gleich Java nehmen?
ich kann auch einen C++ Programmiere fragen, warum er nicht C nimmt. Oder einen Python Programmierer warum er nicht Ruby nimmt. Oder... Alles die gleiche Fragen und alle total sinnlos und auch nicht zu beantworten.
> Ich würde sagen, beide rennen dem eigen definierten Standard hinterher und dabei scheint Mono zumindest nicht langsammer zu sein.
Schaun wir mal was draus wird.
> nur eine kleine Zugabe für die windows Leute
Wetten, dass diese "Kleine Zugabe" bald _der_ Standard bei .NET-Applikationen sein wird? Bisherige WinForm-Applikationen sehen dagegen richtig alt aus und sind in ihren Anwendungen extrem eingeschränkt (z.B. bei Skalierung auf PDA). Gnome-Applikationen ebenso. Gnome könnte sich allenfalls durch massiven SVG-Support retten. Wobei hier sicher noch die Frage der Performance aufkommen wird.
> .Net nicht, Mono dagegen schon sehr gut.
Ich kann also mit Mono eine Gnome-App entwickeln und die läuft dann sofort ohne weiteres in .NET?
Ich kann mir gut vorstellen, dass Mono als Eigenentwicklung auf mehr Plattformen läuft als .NET. Aber ich würde mich sehr wundern, wenn größere .NET-Applikationen (z.B. MS Word.NET) tatsächlich problemlos in Mono laufen würden.
Mein Eindruck ist, dass Mono gut für Unix-Entwickler ist, die ihre Applikationen sowohl für Windows als auch für Unix anbieten wollen. Umgekehrt (.NET --> Mono) wird das vermutlich nur sehr begrenzt funktionieren (auf dem Client, auf Servern sieht die Sache anders aus).
Wetten, dass diese "Kleine Zugabe" bald _der_ Standard bei .NET-Applikationen sein wird?
kann sein, nur .Net interessiert mich eigentlich garnicht, mir geht es um Mono.
Ich kann also mit Mono eine Gnome-App entwickeln und die läuft dann sofort ohne weiteres in .NET?
unter .Net? Sollte in den meisten Fällen kein problem sein. Entscheidend ist aber das Mono Programme auf Mono laufen, egal ob du Mono auf GNU, BSD, Windows, MacOS oder Unix Systemen installierst. .Net und Mono sind am Ende zwei verschiedene Frameworks, deren Gemeinsammkeit besteht letztlich darin, dass sie beide auf dem gleichen offenen Standard aufbauen.
die Weiterentwickung geschieht im Standardkommitee zu dem MS, Novell und noch einige andere (nicht unbekannte) Firmen gehören.
um das mal etwas konkreter zu machen. Hier gibt es einen neuen Draft des Standards: http://www.ecma-international.org/publications/standards/Ecma-334.htm http://www.ecma-international.org/publications/standards/Ecma-335.htm
Aus dem C# Standard:
"This International Standard is based on a submission from Hewlett-Packard, Intel, and Microsoft, that describes a language called C# [..] The following companies and organizations have participated in the development of this standard, and their contributions are gratefully acknowledged: ActiveState, Borland, CSK Corp., Hewlett-Packard, IBM, Intel, IT University of Copenhagen, Jaggersoft (UK), Microsoft, Mountain View Compiler, Monash University (AUS), Netscape, Novell, Pixo, Plum Hall, Sun, and the University of Canterbury (NZ)."
Aus dem CLI Standard:
"The following companies and organizations have participated in the development of this standard, and their contributions are gratefully acknowledged: Borland, Fujitsu Software Corporation, Hewlett-Packard, Intel Corporation, IBM Corporation, ISE, IT University of Copenhagen, Jagger Software Ltd., Microsoft Corporation, Monash University, Netscape, Novell/Ximian, Phone.Com, Plum Hall, Sun Microsystems, and University of Canterbury (NZ)"
> Beipiele sind z.B. structs und die ganzen einfachen Datentypen: die int Familie, float, double, char > enum, bool decimal,..
Naja, structs konnte ich (ausser in C - dort gibts halt nichts anderes) noch nie wirklich viel abgewinnen. Der Rest ist auch in Java nicht auf dem Heap. d.h. eigentlich ist im Ende doch nix wirklich anders und ich werde auch bei C# nicht gefragt ob ich jetzt was aufm Stack oder aufm Heap haben möchte?
> nein, die Weiterentwickung geschieht im Standardkommitee zu dem MS, Novell und noch einige andere > (nicht unbekannte) Firmen gehören.
Naja, mal gucken. Für mich läufts einmal mehr auf dasselbe heraus wie bei Microsofts Java...
Was natürlich nicht heisst dass das ein Problem für DotGNU oder Mono als Linux-Entwicklungsplattform darstellt.
Naja, structs konnte ich (ausser in C - dort gibts halt nichts anderes) noch nie wirklich viel abgewinnen.
Ein Beispiel wurde ja schon weiter unten genannt. Stell dir vor du hast eine Anwendungen die Graphen zeichnet die aus mehreren hundert oder tausend Punkten bestehen. Du wirst also irgendwo einen Datentyp der Form "Point { double x, double y }" haben. In C# kannst du das als struct machen wodurch es optimal, für die Speicherverwaltung und Performance, auf dem stack landet. Bei Java kommst du nicht um eine Klasse herum die auf den heap kommt und wenn du hunderte/tausende Punkte auf dem heap hasst, dann ist das alles andere als optimal.
Naja, mal gucken. Für mich läufts einmal mehr auf dasselbe heraus wie bei Microsofts Java...
Klar, wenn man bei MS an den großen "Satan" denkt und zusammenzuckt wie ein Hase vor der Schlange wenn man irgendwo den Namen MS hört, dann kann ich wenig Argumente dagegen liefern. Dann wäre vielleicht ein Psychologe der bessere Ansprechpartner ;)
Aber objektiv betrachtet gibt es imho keinen Grund zu irgendeiner Art von Panik. Schau dir alleine die Liste an wer alles an dem Standard mitarbeitet...
> Ein Beispiel wurde ja schon weiter unten genannt. Stell dir vor du hast eine Anwendungen die Graphen > zeichnet die aus mehreren hundert oder tausend Punkten bestehen. Du wirst also irgendwo einen Datentyp > der Form "Point { double x, double y }" haben. In C# kannst du das als struct machen wodurch es > optimal, für die Speicherverwaltung und Performance, auf dem stack landet. Bei Java kommst du nicht um > eine Klasse herum die auf den heap kommt und wenn du hunderte/tausende Punkte auf dem heap hasst, dann > ist das alles andere als optimal.
Wieso ist das nicht optimal? Klar braucht speicherallozierung auf dem Heap viel Zeit - zumindest in C ist dem so. Aber das kann man ja auch sehr gut in einem Array speichern. Würde man sogar vernünftigerweise bei tausenden von Punkten.
> Klar, wenn man bei MS an den großen "Satan" denkt und zusammenzuckt wie ein Hase vor der Schlange > wenn man irgendwo den Namen MS hört, dann kann ich wenig Argumente dagegen liefern. Dann wäre > vielleicht ein Psychologe der bessere Ansprechpartner
Jaja, du wirst es ja wissen...
> Aber objektiv betrachtet gibt es imho keinen Grund zu irgendeiner Art von Panik. Schau dir alleine > die Liste an wer alles an dem Standard mitarbeitet...
Objektiv gibt es noch viel weniger Grund anzunehmen Microsoft werde tatenlos zusehen wie andere (DotGNU, Mono) anfangen ihre Marktmacht zu Untergraben. Standards und ähnliches unwichtiges Zeugs hin oder her.
Aber das kann man ja auch sehr gut in einem Array speichern. Würde man sogar vernünftigerweise bei tausenden von Punkten.
Ein Array von "points"... wo ist der Unterschied, die "points" liegen weiterhin auf der Halde.
Objektiv gibt es noch viel weniger Grund anzunehmen Microsoft werde tatenlos zusehen wie andere (DotGNU, Mono) anfangen ihre Marktmacht zu Untergraben. Standards und ähnliches unwichtiges Zeugs hin oder her.
jaja, wieder dar Hase... ;) Nenn mir doch mal ein paar Argumente? MS hat auch sein eigenes C++ mit ihren ganz bestimmten libs für ihre Plattform, beeinflußt das alle andere die C++ auf dem Basis des Standards implementieren und libs für ihre Plattform anbieten?
Dann kommt die MS vs. Java Geschichte. Das ist in meinen Augen ganz alleine Suns schuld und nicht die von MS. Sun entwickelt etwas in einem sehr geschlossenen Prozess, andere sehen es und denke sich das sie das auch brauchen könnten aber ein paar kleine Änderungen bevorzugen würden, da sie aber keinen Einfluß auf die Entwicklung der offiziellen Sprache haben kochen sie eben ihre eigene Suppe wie der java Initiator (sun) selber ja auch. C# dagegen ist von Anfang an aber ein offener Standard, jeder kann auf die Richtig einfluss nehmen. Selbst Sun wirkt am C# und CLI Standard mit! Was ist wenn MS sich nicht 100% an den C# Standard hält? Ich könnte die Frage auch so stellen: Was ist mit MS C++ Kompiler der oft als so schlecht und nicht 100% Standardkonform bezeichnet wurde? Ist deswegen der g++ schlecht und wir sollten kein C++ mehr verwenden? Was MS mit .Net macht kann uns doch am aller wertesten vorbei gehen, genauso wie die Frage was MS mit C++, C, Java,.. macht.
Ausserdem hat MS wirklich keine Geschichte in der sie aktiv gegen andere vor gehen. Klar, sie setzten mit ihrer Markdominanz ihre Produkte auf ihrer Plattform durch (würde jeder andere der proprietären Anbieter übrigens auch machen, da muss man MS nicht böse sein). Aber aktiv (z.B. Patentklagen) gehen sie nicht gegen die Konkurrenz vor. Das können sie sich auch garnicht leisten, sie wissen ja genau wie seh sie beobachtet werden.
Also mein Tip: Einfach mal etwas lockerer werden wenn man MS hört. Sich die Sprache C# und Mono ansehen (oder es auch bleiben lassen, man muß ja nicht alles gesehen haben), schauen ob es einem gefällt und dann nehmen was man will.
> Ein Array von "points"... wo ist der Unterschied, die "points" liegen weiterhin auf der Halde.
Der Unterschied ist dass es nichts bringt, die auf dem Stack zu haben und ich folglich den extremen Vorteil den mir so Dinger wie Structs bringen sollen immer noch nicht erblickt habe.
> Dann kommt die MS vs. Java Geschichte. Das ist in meinen Augen ganz alleine Suns schuld und nicht die > von MS. Sun entwickelt etwas in einem sehr geschlossenen Prozess, andere sehen es und denke sich das > sie das auch brauchen könnten aber ein paar kleine Änderungen bevorzugen würden, da sie aber keinen > Einfluß auf die Entwicklung der offiziellen Sprache haben kochen sie eben ihre eigene Suppe wie der > java Initiator (sun) selber ja auch.
Java = Selbstbedienungsladen? Naja, so kann man das schon auch sehen - aber das was Microsoft gemacht hat sind eher weniger "ein paar kleine Änderungen die sie bevorzugen würden" sondern mehr "Knüppelt das Ding möglichst stark in unsere Plattform rein damit ja keiner mehr wegkommt"...
> C# dagegen ist von Anfang an aber ein offener Standard, jeder kann auf die Richtig einfluss nehmen. > Selbst Sun wirkt am C# und CLI Standard mit!
Offen? Naja. C# und CLI wurden "Standardisiert" - aber damit allein ist der Blumentopf ja noch nicht gewonnen.
> Was ist wenn MS sich nicht 100% an den C# Standard hält? Ich könnte die Frage auch so stellen: Was > ist mit MS C++ Kompiler der oft als so schlecht und nicht 100% Standardkonform bezeichnet wurde? Ist > deswegen der g++ schlecht und wir sollten kein C++ mehr verwenden?
Die Gedanken meinerseits gehen eher in Richtung Klassenbibliothek...
> Ausserdem hat MS wirklich keine Geschichte in der sie aktiv gegen andere vor gehen. Klar, sie setzten > mit ihrer Markdominanz ihre Produkte auf ihrer Plattform durch
Jä, was jetzt? Aktiv oder nicht? Ich nenne das auf jeden Fall nicht passiv.
> würde jeder andere der proprietären Anbieter übrigens auch machen, da muss man MS nicht böse sein
Zweifellos. Das würde nichts ändern. Und? $MACHTHABER versucht mit allen mitteln $MACHT zu behalten und $SCHWARZER_PETER möglichst jemand anderem unterzujubeln.
Der Unterschied ist dass es nichts bringt, die auf dem Stack zu haben und ich folglich den extremen Vorteil den mir so Dinger wie Structs bringen sollen immer noch nicht erblickt habe.
Dann sag doch gleich, dass du keine Ahnung von Speichermanagement hast und das erklärt haben willst.
Wenn Objekte auf den heap müssen dauert es länger den nötigen Speicher zu reservieren als auf einem stack. Wenn Variablen auf dem stack normal mit "pulsieren" sind sie nicht im Weg und verschwinden automatisch wenn man den Gültigkeitsbereich endgültig verlässt. Auf dem heap liegen sie dagegen irgendwo im Speicher herum und das nicht immer an der besten Stelle wenn man weiteren Speicher reservieren will, und keiner weiß wann der Speicher wieder freigegeben wird. Wenn er dann mal freigegeben wird muß sich im Fall java/c# erstmal der garbage collector darum kümmern was die ganze sache nicht unbedingt performanter macht.
Vielleicht war ich nicht klar genug - ich habs vorher schon gesagt aber egal: Einen Vorteil sehe ich nur wenn ich selber entscheide wo das hinkommt - und zwar für alles, nicht nur für so exotische Sachen wie für Structs.
Obige Aussage bezog sich insbesondere auf dein Beispiel bei dem der Speicher ja recht Problemlos an einem Stück alloziert werden kann was performancemässig nicht wirklich Probleme bringt. Zumindest hätte mich das jetzt noch nie gestört. (Bei vielen kleine Objekten hingegen schon)
Um noch mal auf Microsoft zurückzukommen: Klar sind die böse und tun alles um ihre Macht zu stärken: Guck mal was sie mit OpenGL vorhaben: http://www.heise.de/newsticker/meldung/62708 Das nenne ich einen äusserst perfiden Schlag gegen alle "anderen" Betriebssysteme und insbesondere Plattformunabhängige Software - nicht mehr und nicht weniger.
Manche nennen auch als Vorteil von C#, dass es nicht nur Referenztypen gibt, sondern auch Wertetypen es ist also nicht alles ein Objekt welches auf dem Heap liegt sondern es gibt auch eine ganze Reihe von Wertetypen die ganz normal auf dem stack abgelegt werden können.
So ein Blödsinn, es gibt in java auch Wertetypen, was .net von Anfang an konnte was Autoboxing, java hat das erst mit Version 1.5 eingeführt.
Mono ist, laut Aussage von vielen Entwicklern, viel sprachunabhängiger als Java. D.h. du kannst eine ganze Reihe von Programmiersprachen auf Mono verwenden, dass passt halt schön zu dem Programmiersprachenunabhängigen paradigma das gnome schon immer verfolgt hat. Es gibt auch für die java vm compiler anderer Sprachen, nur haben die nie grossartige Bedeutung erreicht. MS hat halt von Anfang an C# und VB.net als gleichwertige Sprachen für die runtime Präsentiert. Die beiden Sprachen unterscheiden sich sogar in den Sprachkonstrukten die sie unterstützen.
Das macht auch die Arbeit einfacher, da du z.B. nur einmal Gtk+ Sprachbindings für Mono erstellen mußt und kannst diese dann mit jeder Sprache verwenden die auf Mono läuft, du brauchst also nicht für alle Sprachen extra Bindings und libs. Naja so einfach ist das nich. Mit IronPython z.B. kann man erst seit der letzten Version .net Assemblies von Python aus verwenden. gnome-java kann ich genausogut aus jpython oder groovy verwenden.
Das einfache einbinden von C libs/programmen soll auch ein Vorteil von c# sein (p/invoke). p/invoke lässt sich direkt nach der api der library bauen, so dass sich gtk# z.B. unter Windows, MacOS unx *nix nutzen lässt, da die library auf allen Plattformen die selbe API hat. Für jni braucht mal leider immer ne Wrapperlibrary in native Code. Insofern hast du da tatsächlich recht.
Ausserdem ist die CLI und C# ein offener Standard an dem u.a. auch Novell mitarbeitet. Man muß also nicht schauen was einer macht und dann hinterherrennen, sondern man kann die Richtung selber steuern und verfolgen. Man, dass ich sowas mal auf dieser Seite lese, hätte ich nie gedacht. Microsoft macht die Spec und Implementierung alleine und lässt das dann von dem Ecma Board als Standard abnicken. Und das machen sie auch nur mit Teilen der Implementierung.
In Java gibt es mehr Wertetypen : byte,short,int,long,double,char. Der Vorteil von Java gegenüber C# : Java hat eine freie und mächtige Entwicklungsumgebung(Eclipse,Netbeans).Java ist stabil, da es schon seit 10 Jahren auf dem Markt ist.
In Java gibt es mehr Wertetypen : byte,short,int,long,double,char
nicht zu vergessen boolean und float, also wie ich schon schrieb booleanbisshort (da das offensichtlich nicht verstanden wurde).
Moechte man nun allerdings etwa ein Point { double x, double y } muss man in Java zwangslaeufig auf Referenztypen, mit den entsprechenden Nachteilen, zurueckgreifen. In C# waere es moeglich das ganze mit Hilfe von struct auch als Wertetyp zu definieren.
Der Vorteil von Java gegenüber C# : Java hat eine freie und mächtige Entwicklungsumgebung (Eclipse,Netbeans)
Ich moechte ja nicht die Vorteile von Java kleinreden und verwende es ja auch gerne, insbesondere wegen Eclipse. Aber es hilft doch nichts offensichtliche Vorteile von C#, wie die Existenz von selbstdefinierbaren Wertetypen, durch Nichtwissen zu leugnen.
Ok; hatte es falsch verstanden. Jedoch;denke ich mal, dass auch C# einige wichtige Java Features nicht enthält. Ich kann mir nicht vorstellen, dass der Reflection Mechanismus (Stichwort dynamische Proxies) in C# mächtiger als in Java sein soll. Wie transparent ist das Aufrufen entfernter Methoden,Objekte und Klassen in C# ?
Ich wollte nicht den Anschein erwecken mit .NET sei alles besser. Es gibt in Java sicher einige Features die .NET nicht hat. Es kommt halt immer darauf an was man benoetigt. Besonders ungluecklich ist meiner Meinung nach das generische Klassen sich im .NET 2.0 auf den neuen System.Collections.Generic Namespace beschraenken. Das ist bei Java 1.5 deutlich besser geloest. Allerdings werden in .NET wiederum Wertetype in generischen Klassen direkt unterstuetzt (ohne boxing).
Ob es sowas einfaches wie java.lang.reflect.Proxy gibt kann ich nicht sagen, mit System.Reflection.TypeDelegator sollte sowas aehnliches, aber wahrscheinlich nicht so einfach, gehen (hab ich aber noch nicht getestet). Der Umgang mit remote Objekten (java.rmi bzw System.Runtime.Remoting) ist bei beiden recht aehnlich.
Da könnte man sich etwas über eine gesonderte Optimierung hierfür durch die VM machen. Wie ich in einer Diskussion zu diesem Thema gelesen habe, hat Sun hier aber leider keinen Ansatz verfolgt.
Vielleicht tut sich in den nächsten Versionen dank der veränderten Lage durch .Net wieder etwas …
sicherlich ist Mono eine Implementierung eines Standards. Jedoch kommt es auch mir so vor, als ob Novell im Grunde dem Standard hinterherrennt. Microsoft wird C# und .NET genau so auslegen, dass es auf Microsoftsysteme abgestimmt ist. Sicherlich kann man Mono eigenständig entwickeln, dennoch wird Novell versuchen, dass die Microsoft Software auch unter Linux läuft. Und hier sehe ich das Problem. Was dabei entsteht ist eine Art Hybrid. Man muss versuchen die Windows-Technologien unter Linux zum Laufen zu kriegen. Das wird so nicht komplett funktionieren.
Microsoft wird versuchen sich mit den neuen und sehr komplexen Technologien vom Rest abzuschotten. .NET wird nicht so einfach portierbar sein, weil die Technologien einfach zu unterschiedlich sind.
Und was haben wir dann: Wieder eine Programmiersprache für Linux, die im Vergleich zu Java frei ist (wobei freie Java Implementierungen folgen).
Dazu wird Mono irgendwelchen Mist aus der Windowswelt mitschleifen, der überhaupt nicht sinnvoll für den Linuxdesktop ist, aber hilfreich ist, wenn man Programme, die eben komplett für Windows entwickelt wurden unter Linux laufen. Letzteres ist sicher sinnvoll, aber dann sehe ich Mono eher als reine Möglichkeit Windows Programme unter Linux laufen zu lassen.
Bin mir da ziemlich unsicher *g* Weiß daher nie, womit ich mich genauer beschäftigen sollte. Im Grunde ist eh wieder wurscht und man muss das nehmen, was man braucht. Man hat eh nicht immer die Wahl :)
Ich habe jahrelang C++ programmiert und mir dann interessehalber mal ein C# Buch gekauft (C# in a nutshell) und muss sgen das ich eher enttäuscht bin von C#. Da wurde nichts von Java gelernt sondern eher die Fehler wiederholt. die Container klassen z.b. sind genauso schlecht wie in Java, weil dort die reine objectorientierung einfach nicht passt. Generische programmierung wie in C++ ist zwar für C# irgendwann mal angekündigt, aber jedenfalls in der C# standard bibliothek nicht verwendet. Das ist eher schade, weil die generische Programmierung heutzutage ebenso wichtig ist wie die object-orientierte Programmierung und eine Sprache die modern sein will wie C# sollte das schon von anbegin unterstützen. Ehrlich gesagt kenne ich keine Sprache die momentan mit C++ richtig mithalten kann.
Das .Net Framework hat aber den Vorteil gegenüber zum Java Framework das man C++ (und andere) DIREKT einbinden kann. Somit wird das Problem der "Viele Sprachen, eine Platform" relativ gut gelöst. Ich kann meine C++ libs in .Net weiterverwenden.
Ich denke schon, daß die Unterschiede im wesentlichen auf Marketing zurückzuführen sind, aber auch auf das 'Management': Miguel de Icaza scheint es irgendwie zu schaffen, andere Entwickler zu begeistern. Seine Möglichkeiten, im Rahmen zu Ximian auf Leute zugehen zu können, boten ihm allerdings auch ganz andere Möglichkeiten.
Außerdem muß Java-GNOME noch mit Anderen konkurrieren: Warum als Entwickler nicht SWT nehmen? Es läuft, soweit ich weiß, auf allen wesentlichen Platformen mit einem einigermaßen lokalen Look'n'Feel. Daher gibt es kaum Anwendungen, die Java-GNOME benutzen. Mit Mono wurden dagegen in einer relativ kurzen Zeit eine ordentliche Zahl von erfolgreichen Anwendungen geschaffen: etwa Muine, F-Spot, Beagle, oder Tomboy; und es gibt unglaubliche viele neue, die bisher nur wenige kennen. Es sind inzwischen fast mehr als GTKmm für sich verbuchen kann.
Platformen sind immer nur dann erfolgreich, wenn es zumindest eine Handvoll erfolgreiche Anwendungen dafür gibt. Daher ist Java-GNOME nur wenig relevant; und würde es auch bleiben, wäre RedHat nicht der Zwickmühle, einerseits eine modernere Sprache zur Entwicklung haben zu wollen, aber andererseits mögliche Patentschwierigkeiten bei Mono fürchten zu müssen.
Von Paulchen Panther am Mo, 8. August 2005 um 16:51 #
etwa Muine, F-Spot, Beagle, oder Tomboy; und es gibt unglaubliche viele neue, die bisher nur wenige kennen.
Und keine von den Anwendungen ist wirklich was besonnderes. Muine kommt nicht an amaroK hin, F-Spot nicht an digikam, die Beagle-Suchmaschine ist ein port von lucene, das urspruenglich fuer Java geschrieben wurde. Gut, tomboy kenne ich nicht, aber wahrscheinlich ist's auch nicht wirklich toll.
Mono und die paar Anwendungen, die damit geschrieben wurden, werden von ein paar Leuten einfach nur furchtbar gehypt. Damit will ich jetzt nicht sagen, dass Mono grundsaetzlich schlecht ist (obwohl es mir wirklich nicht behagt, dass da eine Microsoft-Technologie, auf die Microsoft jede Menge Patente hat, einfach eins zu eins uebernommen wurde). Allerdings gefaellt mir der Hype um ein paar Mono-Applikationen nicht, denn was anderes als dass sie mit Mono geschrieben sind, spricht nicht fuer diese Anwendungen.
Von Daniel Borgmann am Mo, 8. August 2005 um 23:35 #
Das ist schlichtweg Unsinn. Muine z.B. wurde niemals gehyped, sondern die Benutzer moegen es wegen des innovativen Bedienkonzepts. Amarok kann noch so viele Features haben, letztendlich zaehlt der Komfort des Benutzers. Da hat Muine nunmal einen Volltreffer gelandet und gehoert deswegen mit zu den beliebtesten Anwendungen.
Deine Vermutung zu Tomboy "wahrscheinlich ist's auch nicht wirklich toll" zeigt ja schon deutlich wie unvoreingenommen du an die Sache herran gehst. Tomboy ist eine der innovativsten Desktop-Anwendungen der letzten Zeit und ebenfalls ein absoluter Komfortgewinn.
Keiner behauptet, dass man mit Mono generell bessere Anwendungen schreiben kann. Aber die Moeglichkeit schnell und einfach GUIs zu erstellen ermoeglicht es den Entwicklern mehr zu eperimentieren und mehr Zeit in die Gestaltung der Oberflaeche zu investieren. Nicht zuletzt ermoeglicht es auch weniger technisch versierten Entwicklern und Designern ihre Ideen direkt umzusetzen. Natuerlich ist Mono nicht die einzige Option hierfuer, aber nunmal zumindest fuer GNOME derzeit unbestritten die populaerste. java-gnome hat sicher das Potential, zu einer Alternative zu werden. Ich selbst bevorzuge derzeit Python.
Ein weiteres interessantes Desktop Projekt mit Mono ist uebrigens Diva, ein Video Editor: http://diva.mdk.org.pl/ Dafuer, dass es grad einen Monat alt ist, ist der aktuelle Status schon sehr erstaunlich. Inzwischen typisch ist auch, dass der Kern in C geschrieben ist, aber die Oberflaeche mit Mono. Ich denke das werden wir in Zukunft oefter sehen, egal ob mit Mono, Java oder Python.
Ich bin jetzt mal unverschämt und behaupte, daß ich einer der Ersten und Wenigen war, die gesagt haben, daß Mono allein keine außergewöhnlichen Anwendungen hervorbringt: Es ist nicht die Sprache, das Toolkit oder die VM, sondern die Zusammenarbeit von Entwicklern.
Allerdings entspringt Deine Darstellung eher Deinen persönlichen Vorlieben. Tomboy und Muine sind sicher ungewöhnlich und neu in ihrer Bedienung.
Zudem unterschlägst Du in Deinem Vergleich die weite Streuung von Open Source im Allgemeinen: Es gibt kaum noch Anwendungen, die wirklich fehlen. Es ist richtig schwer, irgendetwas zu finden, daß noch nicht als OpenSource Lösung realisiert wurde.
Zugegeben: Viele Ansätze verlieren sich in Reviergeplänkel oder mangelnder Recherche! Letztens erst haben ich mir Outliner unter GNOME angeschaut. Da gab es allein 3 Projekte, die mit Python erstellt wurden, und keines hatte besondere Merkmale, außer daß sie gerade so ihren Zweck erfüllten. Nimmt man noch allen anderen Sprachen und Toolkits hinzu, dann ist keine neue Anwendung etwas Besonderes.
Insofern hängst Du die Meßlatte Deiner Kritik einfach zu hoch: amaroK ist schließlich auch nur ein Klon von WinAmp: Er spielt Musik ab, oder?
Siehe es einfach realistisch: Nicht die 'Qualität' einer Platform fördert ihre Verbreitung, sondern der Hype, der darum gemacht wird. Das gilt für jede 'Platform'; sei es eine Sprache, eine Toolkit oder irgend etwas anderes. Um QT würde sich auch niemand scheren, wenn es nicht zufälligerweise KDE gäbe; es wäre sang- und klanglos untergegangen wie die Platformen BeOS oder OS/2.
> Was ich interessant finde ist, dass Mono als große > Entwicklungsplattform für den GNOME Desktop angesehen > wird, während Java mit Java-GNOME dem ganzen doch gar > nicht nachsteht. Richtig. Der einzige Nachteil war jedoch, dass bisher ein proprietäres JDK notwendig war.
Während ich also Python, Perl, C#, C++, C oder Ruby-basierte GNOME-Anwendungen schreiben konnte, ohne befürchten zu müssen, dass diese schwer in Debian/Ubuntu/Fedora Core reinzubekommen sind, bestand bis jetzt bei Java dieses Problem.
Mit GNU Classpath und GCJ haben wir diesem Problem aber ein Ende bereitet. Der im Artikel verlinkte Flash-Film zeigt zB. Java-Gnome auf GCJ.
Für das Gerangel um C#, Java oder anderen Sprachen habe ich wenig Verständnis. Jeder sollte die Sprache einsetzen, mit der er oder sie am besten zum Ziel gelangt.
Bedeutend finde ich eher, wie man es schaffen kann die Barrieren zwischen den Sprachen abzubauen: Deshalb finde ich IKVM.NET und CNI sehr spannend. Und mal sehen ob wir (GNU Classpath) es hinkriegen eine Brücke zu unseren Kumpels bei DotGNU zu bauen ...
> Ist das lediglich Marketing? Oder taugt Mono mit C# > tatsächlich soviel mehr, als Java mit Java-GNOME? Lediglich gute PR. Apache Harmony hat ja auch schon mehr Wirbel verursacht als GNU Classpath und GCJ zusammen, obwohl in letzterem die Entwicklungsarbeit von mittlerweile 62 Leuten steckt.
Ein anderes Beispiel: Letzlich ging eine Meldung rum, das IBM einen Entwickler zu Harmony geschickt hat. Das ist witzig, denn niemand verbreitet die News, dass Red Hat etliche Leute an GCJ und GNU Classpath beschäftigt. Daneben haben sie sogar noch Angestellte die sich um die Portierung von OpenOffice.org nach Classpath kümmern.
Ich möchte nicht die Bemühungen von IBM herunterspielen (Eclipse ist IMHO ein Segen!), aber auf dem Gebiet "Befreiung der Java-Plattform" ist Red Hat einsame Spitze.
Warum Red Hat so kräftig investiert kann ich mir folgendermaßen erklären: Sie wollen kräftig im J2EE-Markt mitmischen. Während die proprietären JDK/JREs nur Aufgüsse der Sun-Version sind, kann GCJ mit einer ganz eigenen und unabhängigen Implementierung aufwarten. In diese kann Red Hat jede Art von Optimierung einbauen, um ihre Serverprodukte (RHEL) ggü. der Konkurrenz glänzen zu lassen (ohne das Sun ihnen einen Maulkorb verpassen kann).
> Beide bewegen sich IMHO in einer Grauzone, wo man nicht > genau weiß, ob das rechtlich so einwandfrei ist. Die einzige Gefahr für beide Projekte sind die Softwarepatente. Gegenüber den übrigen Ansprüchen sichern wir uns ab, indem wir nur öffentlich verfügbare Informationen zur Implementierung nutzen. Jeder Classpath/GCJ Entwicker muss ausserdem versichern, dass er/sie keinen Quellcode von einer proprietären Java-Klassenbibliothek gesehen hat. Bei Mono, DotGNU und vielen anderen Projekten (zB Wine, Samba) wird IMHO genauso verfahren.
> In Java geschriebene GNOME Anwendungen habe ich bisher > eher wenige gesehen. Aber auch Anwendungen in C# mit Mono > sind eher schwach vertreten. Jedoch gibt es einige große > Anwendungen, wie Beagle und F-Spot, was man bei Java-GNOME > nicht findet. Java-Gnome steht mit seinem Bekanntheitsgrad noch am Anfang. Auf der Mailingliste wurde kürzlich ein Desktop Suchtool besprochen. Dann war einer der Java-Gnome Entwickler unzufrieden mit SQL-Ledger und GNUcash und hat mit der Programmierung eines Finanzprogrammes angefangen. Schliesslich hatte einer mal gefragt, ob es schwierig wäre die GUI von JEdit (setzt auf Swing) mit Java-Gnome zu reimplementieren. Mal gucken was aus diesen Ansätzen wird ...
ich kann Java-GNOME bisher wenig beurteilen, habe es erst gestern zum Laufen bekommen Aber es macht auf mich einen recht guten Eindruck, was die Integration in Java angeht.
Wo ich jedoch finde, dass Java C# etwas hinterherhinkt sind die Events. Ich finde das mit den lifeCycleEvents in Java-GNOME ziemlich merkwürdig. Ein einfaches Ergänzen von Events mit += wie es in C# der Fall ist, finde ich da logischer.
Desweiteren kann ich nicht beurteilen, inwiefern die Neuerung in Java 5 relevant sind. C# scheint auch auf mich einen etwas moderneren Eindruck zu machen.
Ansonsten wünsche ich jedoch Java-GNOME sehr viel Erfolg. Es hat im Grunde nicht weniger Aufmerksamkeit verdient, als C#.
Ist C# wirklich so viel moderner oder verwendet es einfach andere (angenehmere?) Ansätze? Ein paar Freunde, die Delphi sehr gern mochten, meinen das ihnen hier C# lieber wäre als die Art vo Java.
> Ein paar Freunde, die Delphi sehr gern mochten, meinen das ihnen hier C# lieber wäre als die Art vo Java.
Das liegt daran weil C# ein paar Dinge von Delphi uebernommen bzw. damit gemeinsam hat (Properties, Events -> Delegates, Schluesselwoerter wie override, und bestimmt noch ein paar andere Dinge). Das liegt u.a. daran weil Delphi-Erfinder Anders Hejlsberg an C# mitgewirkt hat.
Meiner persoenlichen Meinung nach ist C# angenehmer als Java - vor allem wg. den Delegates.
libgcj basiert auf Classpath. Man könnte sagen, das libgcj einfach die binär kompilierte Variante von Classpath ist, die mit GCJ läuft.
Theoretisch kommt niemand in direkten Kontakt mit GNU Classpath, solange es nicht für Entwicklungszwecke benötigt wird.
Snapshots und Releases von GCJ, Kaffe oder SableVM enthalten bislang auch immer passende Classpath-Quellen. In ganz ferner Zukunft wird es dann aber so sein, dass sich Classpath zu GCJ/Kaffe und Co. so verhält wie glibc zu gcc.
Von Kevin Krammer am Mo, 8. August 2005 um 14:18 #
Mein bisheriger Kenntnisstand war, daß java-gnome die Java Bindings von GNOME sind, also die GNOME API in Java.
Das bestätigt auch der Text in Punkt 5.2.4 des Artikels. Allerdings steht unter Punkt 4 im Absatz nach der Erwähnung von java-gnome praktisch eine Art Aufruf, AWT Peers auf Qt Basis zu versuchen.
Darum bin ich jetzt nicht ganz sicher ob das java-gnome Projekt tatsächlich GNOME Bindings sind, also das Äquivalent zu Koala (KDE Java Bindings), oder GNOME AWT Peers (praktisch als Alternative zu den GTK-only Peers)
Von Kevin Krammer am Mo, 8. August 2005 um 19:14 #
Dann ist das unter (4) ein bischen eigenartig formuliert.
In dem Kontext liest es sich so als wäre es unter KDE nicht möglich mit Java Applikationen zu schreiben, bzw als wären AWT Qt Peers die dafür nötig Voraussetzung.
Vielleicht wußte der Autor aber auch nicht von der Existenz der KDE Java Bindings.
Von Dalibor Topic am Mo, 8. August 2005 um 23:32 #
Sven de Marothy hat in den letzte Wochen an Qt peers fuer AWT programmiert, und dabei recht ansehnliches in kuerzester Zeit produziert. Mehr dazu auf irc://irc.freenode.org/classpath
Von Kevin Krammer am Di, 9. August 2005 um 13:14 #
Danke, äußerst interessant!
Ich hab schon mit dem Gedanken gespielt KDE Peers für AWT zu versuchen, aber nicht so recht eine Idee, wo man da am Besten beginnt.
Ausgehend von Qt Peers dürfte das dann aber nicht mehr so schwierig sein.
Schade in dem Zusammenhang ist ja auch, daß es schon eine Qt basierte AWT Implementation von Trolltech gibt, für Qt/embedded, aber leider nicht zum Download.
Sind das dann so Leute wie Miguel de Icaza und Co? Ich weiß nicht, aber die sind noch so Jung und irgendwie traue ich denen nicht zu, dass das Ding dann so perfekt ist :)
Bei SUN und Microsoft arbeiten sicher teurere und somit auch vielleicht bessere Leute. Weiß nicht, ob die Leute von Novell da mithalten können.
jaja, sehe ich ja genauso. Ich kann mir auch nicht vorstellen das die ganzen "bastler" bei KDE, GNOME, Linux, GNU,... etwas vernünftiges hinbekommen. Da vertraue ich doch besser den teuren Profis von MS -> Freue mich schon auf Vista um mein XP zu upgraden.
*lol* Ich musste das auch die letzte Woche ein paar mal machen. Habe mir dafür von einem Windows-Fan ein paar Tipps geben lassen. Das ist echt lustig. Man installiere Windows und installiere dann Service Pack2, ohne vorher online zu gehen, weil sonst kaputt. Macht dann ein Windows Update und zwar ganz schnell, sonst kaputt.
Dann aktiviert man die Firewall, weil sonst kaputt und dann schnell AntiVirus, weil sonst kaputt.
Dann darf man online gehen. Aber nicht IE nehmen, sonst kaputt.
Ich hab das alles befolgt. Funktioniert auch. Dann hab ich Hardware installiert. Komischerweise startet Windows nun mittendrin einfach mal neu. Ich liebe es (TM)
Ah, bin darum herum gekommen. Wenn man eine Partition die vor der Windowspartition liegt löscht dann ändert sich die Reihenfolge - entsprechend ist Windows bei der Selbstfindung gestört und brabbelt "\winnt\system32\ntoskrnl.exe fehlt oder ist defekt"
Und daraus soll meine Kristallkugel dann ein
VFS: Cannot open root device "hda3" or unknown-block(0,0) Please append to a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
machen das ein normaler Mensch versteht. Naja, muss wohl mal eine neue kaufen gehen...
Ich denke halt nur, dass bei Microsoft ja wirklich Leute arbeiten, die schon seit Jahren im Bereich der Compilerentwicklung und Sprachdesign oder sowas forschen. Und Sun und Microsoft haben doch wesentlich mehr Geld als z.B. Novell :)
Also wenn dann muss Novell ja auch Fachleute eingestellt haben. Ich weiß ja eben nicht, wieviele hinter Mono arbeiten. Miguel mag ja nicht schlecht sein und sowas wie GNOME ins Leben zu rufen ist ja schon ne tolle Sache. Aber reicht das automatisch auch, um nen Compiler und ne VM zu schreiben? :)
Ach so schwer ist es garnicht einen Kompiler zu schreiben, dass wird allgemein als deutlich komplizierter angesehen als es in der Praxis ist. Und das Sprachdesign entsteht ja im Standard Kommitee wo viele Namenhafte Firmen und Personen beteiligt sind.
Hmmm, ok, aber ich hab Benchmarks gesehen, wo Mono deutlich langsamer ist, als .NET. Also da müssten die Mono Jungs noch etwas aufholen, aber natürlich Respekt für die bisherige Arbeit.
Hach dieses ständige Java/Mono Getüdel ist mühsam. Am besten ich lass von beidem die Finger :)) Kann sich ja kein Mensch entscheiden.
Hmmm, ok, aber ich hab Benchmarks gesehen, wo Mono deutlich langsamer ist, als .NET. Also da müssten die Mono Jungs noch etwas aufholen, aber natürlich Respekt für die bisherige Arbeit.
Da gibt es durchaus unterschiede. Je nachdem welche Tests die Benchmarks machen gibt es Bereiche in denen Mono, dotGNU oder .Net am schnellsten ist.
Obwohl es Java und Java-GNOME schon seit Ewigkeiten gibt hat doch früher keiner einen solchen Hype darum gemacht, dass man mit Java Anwendungen für den GNOME Desktop schreiben sollte. Jetzt taucht auf einmal Mono mit C# auf und auf einmal wird es von einigen als das Non-Plus-Ultra geworben.
Ist das lediglich Marketing? Oder taugt Mono mit C# tatsächlich soviel mehr, als Java mit Java-GNOME? Ich versuche gerade Java-GNOME einzurichten und werde mal versuchen mir selbst ein Bild davon zu machen.
Die Sprache Java kenne ich bereits und C# habe ich mir auch einmal angeschaut und die Unterschiede halten sich ja stark in Grenzen. Was das Lizenzproblem angeht, so sehe ich da keinen großen Unterschied zwischen Mono und Java. Beide bewegen sich IMHO in einer Grauzone, wo man nicht genau weiß, ob das rechtlich so einwandfrei ist.
Fedora setzt eben primär auf Java, während Novell stark in Mono investiert. Was davon Sinn, oder Unsinn ist kann wohl keiner sagen, das wird die Zukunft zeigen.
In Java geschriebene GNOME Anwendungen habe ich bisher eher wenige gesehen. Aber auch Anwendungen in C# mit Mono sind eher schwach vertreten. Jedoch gibt es einige große Anwendungen, wie Beagle und F-Spot, was man bei Java-GNOME nicht findet.
Würde mich über ein paar Informationen diesbzgl. freuen.
Gruß
Mike
Ich schreibe meine GNOME-Apps in PERL
Irgendwie ist mir gtk_get_my_stupid_little_function...wurzelbrunft in C(!) zu unübersichtlich. Noch dazu kommt, dass ich weder C noch C++, ergo auch kein Java / C# kann. Was ich aber eigentlich mal zum Ausdruck bringen will, ist, dass man doch inzwischen mit jeder x-beliebigen Sprache GNOME-Applikationen schreiben kann und das finde ich schon ziehmlich cool. :)
Vielleicht habe ich ja Deine Frage hinsichtlich der Vielfalt etwas beantwortet... (jedem das seine).
Gruß
java-gnome sind nicht nur Gtk+ bindings für java, sondern gehören auch zu den "GNOME Platform Bindings", d.h. sie sind immer sehr aktuell und nahe an der aktuellen GNOME/Gtk+ Verison, was man von gtk# noch nicht sagen kann. Auf der anderen Seite gibt es gtk# für windows, bei gnome-java sieht es da afaik nicht so gut aus. Ausserdem hat java imho den "Nachteil", dass es für viele Systeme eine Sun implementierung gibt. Es ist also relativ schwer Java-Programmierer von der Verwendung von gnome-java zu überzeugen wenn sie auf der anderen Seite mit Sun java und den entsprechenden Toolkits alles haben was sie brauchen. Mono ist dagegen eine in sich abgeschlossene Plattform die du komplett für GNU/Linux und komplett für windows bekommst und dann beidesmal deine C# (Gtk#) Programme darauf laufen.
java vs c#:
Von Leuten die beides gut kennen hört man immer wieder das c# aus den Fehlern von java gelernt hat und viele kleine Sachen besser/schöner macht.
Manche nennen auch als Vorteil von C#, dass es nicht nur Referenztypen gibt, sondern auch Wertetypen es ist also nicht alles ein Objekt welches auf dem Heap liegt sondern es gibt auch eine ganze Reihe von Wertetypen die ganz normal auf dem stack abgelegt werden können.
Mono ist, laut Aussage von vielen Entwicklern, viel sprachunabhängiger als Java. D.h. du kannst eine ganze Reihe von Programmiersprachen auf Mono verwenden, dass passt halt schön zu dem Programmiersprachenunabhängigen paradigma das gnome schon immer verfolgt hat. Schau dir auch mal die Demos dazu an: http://primates.ximian.com/~lluis/blog/pivot/entry.php?id=38
Das macht auch die Arbeit einfacher, da du z.B. nur einmal Gtk+ Sprachbindings für Mono erstellen mußt und kannst diese dann mit jeder Sprache verwenden die auf Mono läuft, du brauchst also nicht für alle Sprachen extra Bindings und libs.
Das einfache einbinden von C libs/programmen soll auch ein Vorteil von c# sein (p/invoke).
Ausserdem ist die CLI und C# ein offener Standard an dem u.a. auch Novell mitarbeitet. Man muß also nicht schauen was einer macht und dann hinterherrennen, sondern man kann die Richtung selber steuern und verfolgen.
Lange Rede kurzer Sinn. Mono und C# scheinen für viele Programmierer interessante Ansätze zu habe.
Java ist deswegen nicht schlechter. Jeder hat seine vorlieben und sollte einfach die Sprache und das Framework nutzen das ihm am besten liegt oder das am besten zur Aufgabe passt.
Tja.. wenn das so einfach waere. Wenn du in ein projekt kommst wo seit 10 jahren Tcl/Tk
gemacht wird hast du so ein kleines "ueberzeugungs" problem wenn du da mal eben die
sprache wechseln willst.
Selbiges gilt wenn dir dein arbeitgeber vorschreibt was du zu nehmen hast. Auch wenn
dies aus technischer sicht totaler bloedsinn ist. Z.B. Java fuer GUI apps.
ac
gehts noch einfacher.
froggi
> und viele kleine Sachen besser/schöner macht.
Hab ich auch schon gehört :-)
> Manche nennen auch als Vorteil von C#, dass es nicht nur Referenztypen gibt, sondern auch Wertetypen
> es ist also nicht alles ein Objekt welches auf dem Heap liegt sondern es gibt auch eine ganze Reihe
> von Wertetypen die ganz normal auf dem stack abgelegt werden können.
Auch wenn durch deine Aussage jetzt nicht ganz klar ist wer auf den Stack kommt - sicherlich eine gute Idee
> Mono ist, laut Aussage von vielen Entwicklern, viel sprachunabhängiger als Java. D.h. du kannst eine
> ganze Reihe von Programmiersprachen auf Mono verwenden, dass passt halt schön zu dem
> Programmiersprachenunabhängigen paradigma das gnome schon immer verfolgt hat. Schau dir auch mal die
> Demos dazu an: http://primates.ximian.com/~lluis/blog/pivot/entry.php?id=38
Sicher kein Nachteil aber auch kein soo grosser Vorteil. Praktisch ist ja dann eh fast alles in C# was auch gut so ist - denn dann können auch andere den Code verstehen.
> Das einfache einbinden von C libs/programmen soll auch ein Vorteil von c# sein (p/invoke).
Sehr gut und wichtig. Java ist da ein Albtraum (mal CNI ausgenommen, das afaik bisher nur mit GCJ funktioniert)
> Ausserdem ist die CLI und C# ein offener Standard an dem u.a. auch Novell mitarbeitet. Man muß also
> nicht schauen was einer macht und dann hinterherrennen, sondern man kann die Richtung selber steuern
> und verfolgen.
Naja. Standardisiert wurde soviel ich weiss das Zeugs für .NET 1.0 oder so und die Weiterentwicklung macht Microsoft...
Ich lasse mich natürlich gerne eines besseren belehren.
Mal ganz abgesehen davon dass bei Java das grosse Problem imo nicht so die fehlende VM sondern die Klassenbilbiothek ist - und die ist bei .NET genau so wenig standardisiert.
> Lange Rede kurzer Sinn. Mono und C# scheinen für viele Programmierer interessante Ansätze zu habe.
> Java ist deswegen nicht schlechter. Jeder hat seine vorlieben und sollte einfach die Sprache und das
> Framework nutzen das ihm am besten liegt oder das am besten zur Aufgabe passt.
Einverstanden :-)
MfG Peschmä
Die Frage ist doch: Wer ist freier in seiner Entwicklung?
Ich habe den Verdacht, dass Mono der .NET-Entwicklung immer hinterher hinken wird. Sobald Mono in irgendeiner Sache aufgeschlossen hat, holt MS schon die nächste Entwicklung hervor. Z.B. WinForms. Jetzt basteln die Mono-Leute daran, die API möglichst vollständig hinzubekommen. Dabei steht mit Avalon schon die Wachablösung bevor.
.NET ist nicht wirklich plattformunabhängig. MS versteht darunter sowieso etwas anderes, nämlich Plattformunabhängigkeit zwischen den verschiedenen Windows-Versionen.
Warum also nicht gleich Java nehmen? Zumal die Software einige Jahr mehr auf dem Buckel hat und daher auch viel ausgereifter ist.
würde ich nicht sagen. In einer der letzten Ct's gab es einen Artikel über Mono und .Net nach dem Mono schon eine deutlich vollständigere Implementierung des kommenden Standard 2 hat. Ich würde sagen, beide rennen dem eigen definierten Standard hinterher und dabei scheint Mono zumindest nicht langsammer zu sein.
Sobald Mono in irgendeiner Sache aufgeschlossen hat, holt MS schon die nächste Entwicklung hervor. Z.B. WinForms. Jetzt basteln die Mono-Leute daran, die API möglichst vollständig hinzubekommen.
Du redest vom Kompatibilitätsstack. Der ist ganz nett für Leute die aus der Windows Ecke kommen aber ansonsten total unwichtig. Entscheidend ist die CLI, C#, Gtk#, gst#, gecko#, apache#,... Das ist das Framework welches Mono aus macht und nicht der Kompatibilitätsstack der nur eine kleine Zugabe für die windows Leute ist und sicher nie 100% erreichen wird.
.NET ist nicht wirklich plattformunabhängig.
.Net nicht, Mono dagegen schon sehr gut. Leider werfen Leute immer viele Sachen zusammen ohne sinnvoll zu unterscheiden was was ist.
Warum also nicht gleich Java nehmen?
ich kann auch einen C++ Programmiere fragen, warum er nicht C nimmt. Oder einen Python Programmierer warum er nicht Ruby nimmt. Oder... Alles die gleiche Fragen und alle total sinnlos und auch nicht zu beantworten.
Schaun wir mal was draus wird.
> nur eine kleine Zugabe für die windows Leute
Wetten, dass diese "Kleine Zugabe" bald _der_ Standard bei .NET-Applikationen sein wird? Bisherige WinForm-Applikationen sehen dagegen richtig alt aus und sind in ihren Anwendungen extrem eingeschränkt (z.B. bei Skalierung auf PDA). Gnome-Applikationen ebenso. Gnome könnte sich allenfalls durch massiven SVG-Support retten. Wobei hier sicher noch die Frage der Performance aufkommen wird.
> .Net nicht, Mono dagegen schon sehr gut.
Ich kann also mit Mono eine Gnome-App entwickeln und die läuft dann sofort ohne weiteres in .NET?
Ich kann mir gut vorstellen, dass Mono als Eigenentwicklung auf mehr Plattformen läuft als .NET. Aber ich würde mich sehr wundern, wenn größere .NET-Applikationen (z.B. MS Word.NET) tatsächlich problemlos in Mono laufen würden.
Mein Eindruck ist, dass Mono gut für Unix-Entwickler ist, die ihre Applikationen sowohl für Windows als auch für Unix anbieten wollen. Umgekehrt (.NET --> Mono) wird das vermutlich nur sehr begrenzt funktionieren (auf dem Client, auf Servern sieht die Sache anders aus).
kann sein, nur .Net interessiert mich eigentlich garnicht, mir geht es um Mono.
Ich kann also mit Mono eine Gnome-App entwickeln und die läuft dann sofort ohne weiteres in .NET?
unter .Net? Sollte in den meisten Fällen kein problem sein.
Entscheidend ist aber das Mono Programme auf Mono laufen, egal ob du Mono auf GNU, BSD, Windows, MacOS oder Unix Systemen installierst.
.Net und Mono sind am Ende zwei verschiedene Frameworks, deren Gemeinsammkeit besteht letztlich darin, dass sie beide auf dem gleichen offenen Standard aufbauen.
Kann man eigentlich beide gleichzeitig in Windows verwenden?
Beipiele sind z.B. structs und die ganzen einfachen Datentypen: die int Familie, float, double, char enum, bool decimal,..
Naja. Standardisiert wurde soviel ich weiss das Zeugs für .NET 1.0 oder so und die Weiterentwicklung macht Microsoft...
nein, die Weiterentwickung geschieht im Standardkommitee zu dem MS, Novell und noch einige andere (nicht unbekannte) Firmen gehören.
um das mal etwas konkreter zu machen. Hier gibt es einen neuen Draft des Standards:
http://www.ecma-international.org/publications/standards/Ecma-334.htm
http://www.ecma-international.org/publications/standards/Ecma-335.htm
Aus dem C# Standard:
"This International Standard is based on a submission from Hewlett-Packard, Intel, and Microsoft, that
describes a language called C# [..]
The following companies and organizations have participated in the development of this standard, and their
contributions are gratefully acknowledged: ActiveState, Borland, CSK Corp., Hewlett-Packard, IBM, Intel,
IT University of Copenhagen, Jaggersoft (UK), Microsoft, Mountain View Compiler, Monash University
(AUS), Netscape, Novell, Pixo, Plum Hall, Sun, and the University of Canterbury (NZ)."
Aus dem CLI Standard:
"The following companies and organizations have participated in the development of this standard, and their
contributions are gratefully acknowledged: Borland, Fujitsu Software Corporation, Hewlett-Packard, Intel
Corporation, IBM Corporation, ISE, IT University of Copenhagen, Jagger Software Ltd., Microsoft
Corporation, Monash University, Netscape, Novell/Ximian, Phone.Com, Plum Hall, Sun Microsystems, and
University of Canterbury (NZ)"
> enum, bool decimal,..
Naja, structs konnte ich (ausser in C - dort gibts halt nichts anderes) noch nie wirklich viel abgewinnen. Der Rest ist auch in Java nicht auf dem Heap.
d.h. eigentlich ist im Ende doch nix wirklich anders und ich werde auch bei C# nicht gefragt ob ich jetzt was aufm Stack oder aufm Heap haben möchte?
> nein, die Weiterentwickung geschieht im Standardkommitee zu dem MS, Novell und noch einige andere
> (nicht unbekannte) Firmen gehören.
Naja, mal gucken. Für mich läufts einmal mehr auf dasselbe heraus wie bei Microsofts Java...
Was natürlich nicht heisst dass das ein Problem für DotGNU oder Mono als Linux-Entwicklungsplattform darstellt.
MfG Peschmä
Ein Beispiel wurde ja schon weiter unten genannt. Stell dir vor du hast eine Anwendungen die Graphen zeichnet die aus mehreren hundert oder tausend Punkten bestehen. Du wirst also irgendwo einen Datentyp der Form "Point { double x, double y }" haben. In C# kannst du das als struct machen wodurch es optimal, für die Speicherverwaltung und Performance, auf dem stack landet. Bei Java kommst du nicht um eine Klasse herum die auf den heap kommt und wenn du hunderte/tausende Punkte auf dem heap hasst, dann ist das alles andere als optimal.
Naja, mal gucken. Für mich läufts einmal mehr auf dasselbe heraus wie bei Microsofts Java...
Klar, wenn man bei MS an den großen "Satan" denkt und zusammenzuckt wie ein Hase vor der Schlange wenn man irgendwo den Namen MS hört, dann kann ich wenig Argumente dagegen liefern. Dann wäre vielleicht ein Psychologe der bessere Ansprechpartner ;)
Aber objektiv betrachtet gibt es imho keinen Grund zu irgendeiner Art von Panik. Schau dir alleine die Liste an wer alles an dem Standard mitarbeitet...
> zeichnet die aus mehreren hundert oder tausend Punkten bestehen. Du wirst also irgendwo einen Datentyp
> der Form "Point { double x, double y }" haben. In C# kannst du das als struct machen wodurch es
> optimal, für die Speicherverwaltung und Performance, auf dem stack landet. Bei Java kommst du nicht um
> eine Klasse herum die auf den heap kommt und wenn du hunderte/tausende Punkte auf dem heap hasst, dann
> ist das alles andere als optimal.
Wieso ist das nicht optimal? Klar braucht speicherallozierung auf dem Heap viel Zeit - zumindest in C ist dem so. Aber das kann man ja auch sehr gut in einem Array speichern. Würde man sogar vernünftigerweise bei tausenden von Punkten.
> Klar, wenn man bei MS an den großen "Satan" denkt und zusammenzuckt wie ein Hase vor der Schlange
> wenn man irgendwo den Namen MS hört, dann kann ich wenig Argumente dagegen liefern. Dann wäre
> vielleicht ein Psychologe der bessere Ansprechpartner
Jaja, du wirst es ja wissen...
> Aber objektiv betrachtet gibt es imho keinen Grund zu irgendeiner Art von Panik. Schau dir alleine
> die Liste an wer alles an dem Standard mitarbeitet...
Objektiv gibt es noch viel weniger Grund anzunehmen Microsoft werde tatenlos zusehen wie andere (DotGNU, Mono) anfangen ihre Marktmacht zu Untergraben. Standards und ähnliches unwichtiges Zeugs hin oder her.
MfG Peschmä
Ein Array von "points"... wo ist der Unterschied, die "points" liegen weiterhin auf der Halde.
Objektiv gibt es noch viel weniger Grund anzunehmen Microsoft werde tatenlos zusehen wie andere (DotGNU, Mono) anfangen ihre Marktmacht zu Untergraben. Standards und ähnliches unwichtiges Zeugs hin oder her.
jaja, wieder dar Hase... ;)
Nenn mir doch mal ein paar Argumente?
MS hat auch sein eigenes C++ mit ihren ganz bestimmten libs für ihre Plattform, beeinflußt das alle andere die C++ auf dem Basis des Standards implementieren und libs für ihre Plattform anbieten?
Dann kommt die MS vs. Java Geschichte. Das ist in meinen Augen ganz alleine Suns schuld und nicht die von MS. Sun entwickelt etwas in einem sehr geschlossenen Prozess, andere sehen es und denke sich das sie das auch brauchen könnten aber ein paar kleine Änderungen bevorzugen würden, da sie aber keinen Einfluß auf die Entwicklung der offiziellen Sprache haben kochen sie eben ihre eigene Suppe wie der java Initiator (sun) selber ja auch.
C# dagegen ist von Anfang an aber ein offener Standard, jeder kann auf die Richtig einfluss nehmen. Selbst Sun wirkt am C# und CLI Standard mit!
Was ist wenn MS sich nicht 100% an den C# Standard hält? Ich könnte die Frage auch so stellen: Was ist mit MS C++ Kompiler der oft als so schlecht und nicht 100% Standardkonform bezeichnet wurde? Ist deswegen der g++ schlecht und wir sollten kein C++ mehr verwenden? Was MS mit .Net macht kann uns doch am aller wertesten vorbei gehen, genauso wie die Frage was MS mit C++, C, Java,.. macht.
Ausserdem hat MS wirklich keine Geschichte in der sie aktiv gegen andere vor gehen. Klar, sie setzten mit ihrer Markdominanz ihre Produkte auf ihrer Plattform durch (würde jeder andere der proprietären Anbieter übrigens auch machen, da muss man MS nicht böse sein). Aber aktiv (z.B. Patentklagen) gehen sie nicht gegen die Konkurrenz vor. Das können sie sich auch garnicht leisten, sie wissen ja genau wie seh sie beobachtet werden.
Also mein Tip: Einfach mal etwas lockerer werden wenn man MS hört. Sich die Sprache C# und Mono ansehen (oder es auch bleiben lassen, man muß ja nicht alles gesehen haben), schauen ob es einem gefällt und dann nehmen was man will.
Der Unterschied ist dass es nichts bringt, die auf dem Stack zu haben und ich folglich den extremen Vorteil den mir so Dinger wie Structs bringen sollen immer noch nicht erblickt habe.
> Dann kommt die MS vs. Java Geschichte. Das ist in meinen Augen ganz alleine Suns schuld und nicht die
> von MS. Sun entwickelt etwas in einem sehr geschlossenen Prozess, andere sehen es und denke sich das
> sie das auch brauchen könnten aber ein paar kleine Änderungen bevorzugen würden, da sie aber keinen
> Einfluß auf die Entwicklung der offiziellen Sprache haben kochen sie eben ihre eigene Suppe wie der
> java Initiator (sun) selber ja auch.
Java = Selbstbedienungsladen? Naja, so kann man das schon auch sehen - aber das was Microsoft gemacht hat sind eher weniger "ein paar kleine Änderungen die sie bevorzugen würden" sondern mehr "Knüppelt das Ding möglichst stark in unsere Plattform rein damit ja keiner mehr wegkommt"...
> C# dagegen ist von Anfang an aber ein offener Standard, jeder kann auf die Richtig einfluss nehmen.
> Selbst Sun wirkt am C# und CLI Standard mit!
Offen? Naja. C# und CLI wurden "Standardisiert" - aber damit allein ist der Blumentopf ja noch nicht gewonnen.
> Was ist wenn MS sich nicht 100% an den C# Standard hält? Ich könnte die Frage auch so stellen: Was
> ist mit MS C++ Kompiler der oft als so schlecht und nicht 100% Standardkonform bezeichnet wurde? Ist
> deswegen der g++ schlecht und wir sollten kein C++ mehr verwenden?
Die Gedanken meinerseits gehen eher in Richtung Klassenbibliothek...
> Ausserdem hat MS wirklich keine Geschichte in der sie aktiv gegen andere vor gehen. Klar, sie setzten
> mit ihrer Markdominanz ihre Produkte auf ihrer Plattform durch
Jä, was jetzt? Aktiv oder nicht? Ich nenne das auf jeden Fall nicht passiv.
> würde jeder andere der proprietären Anbieter übrigens auch machen, da muss man MS nicht böse sein
Zweifellos. Das würde nichts ändern. Und?
$MACHTHABER versucht mit allen mitteln $MACHT zu behalten und $SCHWARZER_PETER möglichst jemand anderem unterzujubeln.
MfG Peschmä
Dann sag doch gleich, dass du keine Ahnung von Speichermanagement hast und das erklärt haben willst.
Wenn Objekte auf den heap müssen dauert es länger den nötigen Speicher zu reservieren als auf einem stack. Wenn Variablen auf dem stack normal mit "pulsieren" sind sie nicht im Weg und verschwinden automatisch wenn man den Gültigkeitsbereich endgültig verlässt. Auf dem heap liegen sie dagegen irgendwo im Speicher herum und das nicht immer an der besten Stelle wenn man weiteren Speicher reservieren will, und keiner weiß wann der Speicher wieder freigegeben wird. Wenn er dann mal freigegeben wird muß sich im Fall java/c# erstmal der garbage collector darum kümmern was die ganze sache nicht unbedingt performanter macht.
Obige Aussage bezog sich insbesondere auf dein Beispiel bei dem der Speicher ja recht Problemlos an einem Stück alloziert werden kann was performancemässig nicht wirklich Probleme bringt. Zumindest hätte mich das jetzt noch nie gestört. (Bei vielen kleine Objekten hingegen schon)
Um noch mal auf Microsoft zurückzukommen: Klar sind die böse und tun alles um ihre Macht zu stärken: Guck mal was sie mit OpenGL vorhaben: http://www.heise.de/newsticker/meldung/62708
Das nenne ich einen äusserst perfiden Schlag gegen alle "anderen" Betriebssysteme und insbesondere Plattformunabhängige Software - nicht mehr und nicht weniger.
MfG Peschmä
So ein Blödsinn, es gibt in java auch Wertetypen, was .net von Anfang an konnte was Autoboxing, java hat das erst mit Version 1.5 eingeführt.
Mono ist, laut Aussage von vielen Entwicklern, viel sprachunabhängiger als Java. D.h. du kannst eine ganze Reihe von Programmiersprachen auf Mono verwenden, dass passt halt schön zu dem Programmiersprachenunabhängigen paradigma das gnome schon immer verfolgt hat.
Es gibt auch für die java vm compiler anderer Sprachen, nur haben die nie grossartige Bedeutung erreicht. MS hat halt von Anfang an C# und VB.net als gleichwertige Sprachen für die runtime Präsentiert. Die beiden Sprachen unterscheiden sich sogar in den Sprachkonstrukten die sie unterstützen.
Das macht auch die Arbeit einfacher, da du z.B. nur einmal Gtk+ Sprachbindings für Mono erstellen mußt und kannst diese dann mit jeder Sprache verwenden die auf Mono läuft, du brauchst also nicht für alle Sprachen extra Bindings und libs.
Naja so einfach ist das nich. Mit IronPython z.B. kann man erst seit der letzten Version .net Assemblies von Python aus verwenden. gnome-java kann ich genausogut aus jpython oder groovy verwenden.
Das einfache einbinden von C libs/programmen soll auch ein Vorteil von c# sein (p/invoke).
p/invoke lässt sich direkt nach der api der library bauen, so dass sich gtk# z.B. unter Windows, MacOS unx *nix nutzen lässt, da die library auf allen Plattformen die selbe API hat. Für jni braucht mal leider immer ne Wrapperlibrary in native Code. Insofern hast du da tatsächlich recht.
Ausserdem ist die CLI und C# ein offener Standard an dem u.a. auch Novell mitarbeitet. Man muß also nicht schauen was einer macht und dann hinterherrennen, sondern man kann die Richtung selber steuern und verfolgen.
Man, dass ich sowas mal auf dieser Seite lese, hätte ich nie gedacht. Microsoft macht die Spec und Implementierung alleine und lässt das dann von dem Ecma Board als Standard abnicken. Und das machen sie auch nur mit Teilen der Implementierung.
In Java gibt es nur boolean - short. Etwas wie struct zur Definition komplexer Wertetypen fehlt im Gegensatz zu .net.
Der Vorteil von Java gegenüber C# : Java hat eine freie und mächtige Entwicklungsumgebung(Eclipse,Netbeans).Java ist stabil, da es schon seit 10 Jahren auf dem Markt ist.
nicht zu vergessen boolean und float, also wie ich schon schrieb boolean bis short (da das offensichtlich nicht verstanden wurde).
Moechte man nun allerdings etwa ein Point { double x, double y } muss man in Java zwangslaeufig auf Referenztypen, mit den entsprechenden Nachteilen, zurueckgreifen. In C# waere es moeglich das ganze mit Hilfe von struct auch als Wertetyp zu definieren.
Der Vorteil von Java gegenüber C# : Java hat eine freie und mächtige Entwicklungsumgebung (Eclipse,Netbeans)
Ich moechte ja nicht die Vorteile von Java kleinreden und verwende es ja auch gerne, insbesondere wegen Eclipse. Aber es hilft doch nichts offensichtliche Vorteile von C#, wie die Existenz von selbstdefinierbaren Wertetypen, durch Nichtwissen zu leugnen.
Ob es sowas einfaches wie java.lang.reflect.Proxy gibt kann ich nicht sagen, mit System.Reflection.TypeDelegator sollte sowas aehnliches, aber wahrscheinlich nicht so einfach, gehen (hab ich aber noch nicht getestet). Der Umgang mit remote Objekten (java.rmi bzw System.Runtime.Remoting) ist bei beiden recht aehnlich.
Da könnte man sich etwas über eine gesonderte Optimierung hierfür durch die VM machen.
Wie ich in einer Diskussion zu diesem Thema gelesen habe, hat Sun hier aber leider keinen Ansatz verfolgt.
Vielleicht tut sich in den nächsten Versionen dank der veränderten Lage durch .Net wieder etwas …
sicherlich ist Mono eine Implementierung eines Standards. Jedoch kommt es auch mir so vor, als ob Novell im Grunde dem Standard hinterherrennt. Microsoft wird C# und .NET genau so auslegen, dass es auf Microsoftsysteme abgestimmt ist. Sicherlich kann man Mono eigenständig entwickeln, dennoch wird Novell versuchen, dass die Microsoft Software auch unter Linux läuft. Und hier sehe ich das Problem. Was dabei entsteht ist eine Art Hybrid. Man muss versuchen die Windows-Technologien unter Linux zum Laufen zu kriegen. Das wird so nicht komplett funktionieren.
Microsoft wird versuchen sich mit den neuen und sehr komplexen Technologien vom Rest abzuschotten. .NET wird nicht so einfach portierbar sein, weil die Technologien einfach zu unterschiedlich sind.
Und was haben wir dann: Wieder eine Programmiersprache für Linux, die im Vergleich zu Java frei ist (wobei freie Java Implementierungen folgen).
Dazu wird Mono irgendwelchen Mist aus der Windowswelt mitschleifen, der überhaupt nicht sinnvoll für den Linuxdesktop ist, aber hilfreich ist, wenn man Programme, die eben komplett für Windows entwickelt wurden unter Linux laufen. Letzteres ist sicher sinnvoll, aber dann sehe ich Mono eher als reine Möglichkeit Windows Programme unter Linux laufen zu lassen.
Bin mir da ziemlich unsicher *g* Weiß daher nie, womit ich mich genauer beschäftigen sollte. Im Grunde ist eh wieder wurscht und man muss das nehmen, was man braucht. Man hat eh nicht immer die Wahl :)
Gruß
Mike
Das ist eher schade, weil die generische Programmierung heutzutage ebenso wichtig ist wie die object-orientierte Programmierung und eine Sprache die modern sein will wie C# sollte das schon von anbegin unterstützen. Ehrlich gesagt kenne ich keine Sprache die momentan mit C++ richtig mithalten kann.
Das .Net Framework hat aber den Vorteil gegenüber zum Java Framework das man C++ (und andere) DIREKT einbinden kann. Somit wird das Problem der "Viele Sprachen, eine Platform" relativ gut gelöst. Ich kann meine C++ libs in .Net weiterverwenden.
Außerdem muß Java-GNOME noch mit Anderen konkurrieren: Warum als Entwickler nicht SWT nehmen? Es läuft, soweit ich weiß, auf allen wesentlichen Platformen mit einem einigermaßen lokalen Look'n'Feel. Daher gibt es kaum Anwendungen, die Java-GNOME benutzen. Mit Mono wurden dagegen in einer relativ kurzen Zeit eine ordentliche Zahl von erfolgreichen Anwendungen geschaffen: etwa Muine, F-Spot, Beagle, oder Tomboy; und es gibt unglaubliche viele neue, die bisher nur wenige kennen. Es sind inzwischen fast mehr als GTKmm für sich verbuchen kann.
Platformen sind immer nur dann erfolgreich, wenn es zumindest eine Handvoll erfolgreiche Anwendungen dafür gibt. Daher ist Java-GNOME nur wenig relevant; und würde es auch bleiben, wäre RedHat nicht der Zwickmühle, einerseits eine modernere Sprache zur Entwicklung haben zu wollen, aber andererseits mögliche Patentschwierigkeiten bei Mono fürchten zu müssen.
Und keine von den Anwendungen ist wirklich was besonnderes. Muine kommt nicht an amaroK hin, F-Spot nicht an digikam, die Beagle-Suchmaschine ist ein port von lucene, das urspruenglich fuer Java geschrieben wurde. Gut, tomboy kenne ich nicht, aber wahrscheinlich ist's auch nicht wirklich toll.
Mono und die paar Anwendungen, die damit geschrieben wurden, werden von ein paar Leuten einfach nur furchtbar gehypt. Damit will ich jetzt nicht sagen, dass Mono grundsaetzlich schlecht ist (obwohl es mir wirklich nicht behagt, dass da eine Microsoft-Technologie, auf die Microsoft jede Menge Patente hat, einfach eins zu eins uebernommen wurde). Allerdings gefaellt mir der Hype um ein paar Mono-Applikationen nicht, denn was anderes als dass sie mit Mono geschrieben sind, spricht nicht fuer diese Anwendungen.
Deine Vermutung zu Tomboy "wahrscheinlich ist's auch nicht wirklich toll" zeigt ja schon deutlich wie unvoreingenommen du an die Sache herran gehst. Tomboy ist eine der innovativsten Desktop-Anwendungen der letzten Zeit und ebenfalls ein absoluter Komfortgewinn.
Keiner behauptet, dass man mit Mono generell bessere Anwendungen schreiben kann. Aber die Moeglichkeit schnell und einfach GUIs zu erstellen ermoeglicht es den Entwicklern mehr zu eperimentieren und mehr Zeit in die Gestaltung der Oberflaeche zu investieren. Nicht zuletzt ermoeglicht es auch weniger technisch versierten Entwicklern und Designern ihre Ideen direkt umzusetzen. Natuerlich ist Mono nicht die einzige Option hierfuer, aber nunmal zumindest fuer GNOME derzeit unbestritten die populaerste. java-gnome hat sicher das Potential, zu einer Alternative zu werden. Ich selbst bevorzuge derzeit Python.
Ein weiteres interessantes Desktop Projekt mit Mono ist uebrigens Diva, ein Video Editor: http://diva.mdk.org.pl/
Dafuer, dass es grad einen Monat alt ist, ist der aktuelle Status schon sehr erstaunlich. Inzwischen typisch ist auch, dass der Kern in C geschrieben ist, aber die Oberflaeche mit Mono. Ich denke das werden wir in Zukunft oefter sehen, egal ob mit Mono, Java oder Python.
Allerdings entspringt Deine Darstellung eher Deinen persönlichen Vorlieben. Tomboy und Muine sind sicher ungewöhnlich und neu in ihrer Bedienung.
Zudem unterschlägst Du in Deinem Vergleich die weite Streuung von Open Source im Allgemeinen: Es gibt kaum noch Anwendungen, die wirklich fehlen. Es ist richtig schwer, irgendetwas zu finden, daß noch nicht als OpenSource Lösung realisiert wurde.
Zugegeben: Viele Ansätze verlieren sich in Reviergeplänkel oder mangelnder Recherche! Letztens erst haben ich mir Outliner unter GNOME angeschaut. Da gab es allein 3 Projekte, die mit Python erstellt wurden, und keines hatte besondere Merkmale, außer daß sie gerade so ihren Zweck erfüllten. Nimmt man noch allen anderen Sprachen und Toolkits hinzu, dann ist keine neue Anwendung etwas Besonderes.
Insofern hängst Du die Meßlatte Deiner Kritik einfach zu hoch: amaroK ist schließlich auch nur ein Klon von WinAmp: Er spielt Musik ab, oder?
Siehe es einfach realistisch: Nicht die 'Qualität' einer Platform fördert ihre Verbreitung, sondern der Hype, der darum gemacht wird. Das gilt für jede 'Platform'; sei es eine Sprache, eine Toolkit oder irgend etwas anderes. Um QT würde sich auch niemand scheren, wenn es nicht zufälligerweise KDE gäbe; es wäre sang- und klanglos untergegangen wie die Platformen BeOS oder OS/2.
> Entwicklungsplattform für den GNOME Desktop angesehen
> wird, während Java mit Java-GNOME dem ganzen doch gar
> nicht nachsteht.
Richtig. Der einzige Nachteil war jedoch, dass bisher ein proprietäres JDK notwendig war.
Während ich also Python, Perl, C#, C++, C oder Ruby-basierte GNOME-Anwendungen schreiben konnte, ohne befürchten zu müssen, dass diese schwer in Debian/Ubuntu/Fedora Core reinzubekommen sind, bestand bis jetzt bei Java dieses Problem.
Mit GNU Classpath und GCJ haben wir diesem Problem aber ein Ende bereitet. Der im Artikel verlinkte Flash-Film zeigt zB. Java-Gnome auf GCJ.
Für das Gerangel um C#, Java oder anderen Sprachen habe ich wenig Verständnis. Jeder sollte die Sprache einsetzen, mit der er oder sie am besten zum Ziel gelangt.
Bedeutend finde ich eher, wie man es schaffen kann die Barrieren zwischen den Sprachen abzubauen: Deshalb finde ich IKVM.NET und CNI sehr spannend.
Und mal sehen ob wir (GNU Classpath) es hinkriegen eine Brücke zu unseren Kumpels bei DotGNU zu bauen ...
> Ist das lediglich Marketing? Oder taugt Mono mit C#
> tatsächlich soviel mehr, als Java mit Java-GNOME?
Lediglich gute PR. Apache Harmony hat ja auch schon mehr Wirbel verursacht als GNU Classpath und GCJ zusammen, obwohl in letzterem die Entwicklungsarbeit von mittlerweile 62 Leuten steckt.
Ein anderes Beispiel: Letzlich ging eine Meldung rum, das IBM einen Entwickler zu Harmony geschickt hat. Das ist witzig, denn niemand verbreitet die News, dass Red Hat etliche Leute an GCJ und GNU Classpath beschäftigt. Daneben haben sie sogar noch Angestellte die sich um die Portierung von OpenOffice.org nach Classpath kümmern.
Ich möchte nicht die Bemühungen von IBM herunterspielen (Eclipse ist IMHO ein Segen!), aber auf dem Gebiet "Befreiung der Java-Plattform" ist Red Hat einsame Spitze.
Warum Red Hat so kräftig investiert kann ich mir folgendermaßen erklären: Sie wollen kräftig im J2EE-Markt mitmischen. Während die proprietären JDK/JREs nur Aufgüsse der Sun-Version sind, kann GCJ mit einer ganz eigenen und unabhängigen Implementierung aufwarten. In diese kann Red Hat jede Art von Optimierung einbauen, um ihre Serverprodukte (RHEL) ggü. der Konkurrenz glänzen zu lassen (ohne das Sun ihnen einen Maulkorb verpassen kann).
> Beide bewegen sich IMHO in einer Grauzone, wo man nicht
> genau weiß, ob das rechtlich so einwandfrei ist.
Die einzige Gefahr für beide Projekte sind die Softwarepatente. Gegenüber den übrigen Ansprüchen sichern wir uns ab, indem wir nur öffentlich verfügbare Informationen zur Implementierung nutzen. Jeder Classpath/GCJ Entwicker muss ausserdem versichern, dass er/sie keinen Quellcode von einer proprietären Java-Klassenbibliothek gesehen hat. Bei Mono, DotGNU und vielen anderen Projekten (zB Wine, Samba) wird IMHO genauso verfahren.
> In Java geschriebene GNOME Anwendungen habe ich bisher
> eher wenige gesehen. Aber auch Anwendungen in C# mit Mono
> sind eher schwach vertreten. Jedoch gibt es einige große
> Anwendungen, wie Beagle und F-Spot, was man bei Java-GNOME
> nicht findet.
Java-Gnome steht mit seinem Bekanntheitsgrad noch am Anfang. Auf der Mailingliste wurde kürzlich ein Desktop Suchtool besprochen. Dann war einer der Java-Gnome Entwickler unzufrieden mit SQL-Ledger und GNUcash und hat mit der Programmierung eines Finanzprogrammes angefangen. Schliesslich hatte einer mal gefragt, ob es schwierig wäre die GUI von JEdit (setzt auf Swing) mit Java-Gnome zu reimplementieren. Mal gucken was aus diesen Ansätzen wird ...
ich kann Java-GNOME bisher wenig beurteilen, habe es erst gestern zum Laufen bekommen
Aber es macht auf mich einen recht guten Eindruck, was die Integration in Java angeht.
Wo ich jedoch finde, dass Java C# etwas hinterherhinkt sind die Events. Ich finde das mit den lifeCycleEvents in Java-GNOME ziemlich merkwürdig. Ein einfaches Ergänzen von Events mit += wie es in C# der Fall ist, finde ich da logischer.
Desweiteren kann ich nicht beurteilen, inwiefern die Neuerung in Java 5 relevant sind. C# scheint auch auf mich einen etwas moderneren Eindruck zu machen.
Ansonsten wünsche ich jedoch Java-GNOME sehr viel Erfolg. Es hat im Grunde nicht weniger Aufmerksamkeit verdient, als C#.
Gruß
Mike
Ein paar Freunde, die Delphi sehr gern mochten, meinen das ihnen hier C# lieber wäre als die Art vo Java.
Das liegt daran weil C# ein paar Dinge von Delphi uebernommen bzw. damit gemeinsam hat (Properties, Events -> Delegates, Schluesselwoerter wie override, und bestimmt noch ein paar andere Dinge). Das liegt u.a. daran weil Delphi-Erfinder Anders Hejlsberg an C# mitgewirkt hat.
Meiner persoenlichen Meinung nach ist C# angenehmer als Java - vor allem wg. den Delegates.
ja genau das mit den Delegates ist der Punkt, den ich in C# wesentlich besser finde, als in Java. Aber ansonsten tut sich da ja nun nicht soviel.
Gruß
Mike
Wenn ich das richtig gelesen habe, war er auch der hinter Microsofts Java-Verbrechen …
wenn ich die Dokus verstanden habe, die Java API?
Aber libgcj kommt mit gcj mit und Classpath muss man erst
in gcj hineinkompilieren, oder!?
Welches von den beiden sollte man also verwenden?
Kann mir da mal jemand zur Erleuchtung verhelfen, bitte?
Theoretisch kommt niemand in direkten Kontakt mit GNU Classpath, solange es nicht für Entwicklungszwecke benötigt wird.
Snapshots und Releases von GCJ, Kaffe oder SableVM enthalten bislang auch immer passende Classpath-Quellen. In ganz ferner Zukunft wird es dann aber so sein, dass sich Classpath zu GCJ/Kaffe und Co. so verhält wie glibc zu gcc.
Alle Klarheiten beseitigt?
Das bestätigt auch der Text in Punkt 5.2.4 des Artikels.
Allerdings steht unter Punkt 4 im Absatz nach der Erwähnung von java-gnome praktisch eine Art Aufruf, AWT Peers auf Qt Basis zu versuchen.
Darum bin ich jetzt nicht ganz sicher ob das java-gnome Projekt tatsächlich GNOME Bindings sind, also das Äquivalent zu Koala (KDE Java Bindings), oder GNOME AWT Peers (praktisch als Alternative zu den GTK-only Peers)
> das Äquivalent zu Koala
... das hier trifft zu. Die Arbeit an Gtk-AWT-Peers hat so nichts mit Java-Gnome zu tun.
MfG Peschmä
In dem Kontext liest es sich so als wäre es unter KDE nicht möglich mit Java Applikationen zu schreiben, bzw als wären AWT Qt Peers die dafür nötig Voraussetzung.
Vielleicht wußte der Autor aber auch nicht von der Existenz der KDE Java Bindings.
gruss,
dalibor topic
Ich hab schon mit dem Gedanken gespielt KDE Peers für AWT zu versuchen, aber nicht so recht eine Idee, wo man da am Besten beginnt.
Ausgehend von Qt Peers dürfte das dann aber nicht mehr so schwierig sein.
Schade in dem Zusammenhang ist ja auch, daß es schon eine Qt basierte AWT Implementation von Trolltech gibt, für Qt/embedded, aber leider nicht zum Download.
> Vielleicht wußte der Autor aber auch nicht von der Existenz der KDE Java Bindings.
Ich denke schon dass er die kennt - er scheint noch so recht viel zu kennen ;-)
MfG Peschmä
Welche Leute arbeiten denn bei Novell an Mono?
Sind das dann so Leute wie Miguel de Icaza und Co? Ich weiß nicht, aber die sind noch so Jung und irgendwie traue ich denen nicht zu, dass das Ding dann so perfekt ist :)
Bei SUN und Microsoft arbeiten sicher teurere und somit auch vielleicht bessere Leute. Weiß nicht, ob die Leute von Novell da mithalten können.
Mike
MfG Peschmä, der demnächst zum 3. Mal in 2 Wochen Windows neu installieren wird und der Meinung ist dabei eigentlich nix falsch gemacht zu haben...
Dann aktiviert man die Firewall, weil sonst kaputt und dann schnell AntiVirus, weil sonst kaputt.
Dann darf man online gehen. Aber nicht IE nehmen, sonst kaputt.
Ich hab das alles befolgt. Funktioniert auch. Dann hab ich Hardware installiert. Komischerweise startet Windows nun mittendrin einfach mal neu. Ich liebe es (TM)
Gruß
Mike
nein es ist eine ganz normale große Kiste mit AthlonXP.
Gruß
Mike
Und daraus soll meine Kristallkugel dann ein
VFS: Cannot open root device "hda3" or unknown-block(0,0) Please append to a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
machen das ein normaler Mensch versteht. Naja, muss wohl mal eine neue kaufen gehen...
MfG Peschmä
Ich denke halt nur, dass bei Microsoft ja wirklich Leute arbeiten, die schon seit Jahren im Bereich der Compilerentwicklung und Sprachdesign oder sowas forschen. Und Sun und Microsoft haben doch wesentlich mehr Geld als z.B. Novell :)
Also wenn dann muss Novell ja auch Fachleute eingestellt haben. Ich weiß ja eben nicht, wieviele hinter Mono arbeiten. Miguel mag ja nicht schlecht sein und sowas wie GNOME ins Leben zu rufen ist ja schon ne tolle Sache. Aber reicht das automatisch auch, um nen Compiler und ne VM zu schreiben? :)
Gruß
Mike
Und das Sprachdesign entsteht ja im Standard Kommitee wo viele Namenhafte Firmen und Personen beteiligt sind.
Hach dieses ständige Java/Mono Getüdel ist mühsam. Am besten ich lass von beidem die Finger :)) Kann sich ja kein Mensch entscheiden.
Gruß
Mike
Da gibt es durchaus unterschiede. Je nachdem welche Tests die Benchmarks machen gibt es Bereiche in denen Mono, dotGNU oder .Net am schnellsten ist.
Gruß
Mike