1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Microsofts Linux-Geschäft mit…

Mono!

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Mono!

    Autor: .:. 12.06.09 - 10:28

    Das beste an der Zusammenarbeit ist und bleibt Mono!

    Vor allendingen für GUI Anwendungen einfach unschlagbar!

  2. Re: Mono!

    Autor: Alptraum 12.06.09 - 10:33

    Keine Ahnung von was du redest.
    .Net ist 'n Witz!

  3. Re: Mono!

    Autor: mwi 12.06.09 - 11:59

    .NET hat zwar nichts mit dem Artikel zu tun, aber auch mit dem Ausrufezeichen wird dir kein Kunde, kein Dozent, kein Programmierer und kein objektiv veranlagter Mensch diese These ohne Nachfrage glauben.

  4. Re: Mono!

    Autor: herRrscher 12.06.09 - 18:19

    Ist aber so o_O

    Gruß, herRrscher
    http://www.whylinuxisbetter.net/index_de.php?lang=de
    Arch Linux - Take control!
    --> http://archlinux.de | http://archlinux.org <--

  5. Re: Mono!

    Autor: redwolf_ 12.06.09 - 20:13

    Na ja arbeite mit C#.NET und Java, primär C#.NET.

    Würde Java aber für Plattformunabhängigkeit immer zu Java greifen.

  6. So so

    Autor: so-isses 12.06.09 - 22:04

    Hast du denn schon mal eine größere .NET-GUI-Anwendung von Windows rübergenommen und ohne Änderung in Mono laufen lassen?

    Ich habe starke Zweifel, ob sowas ohne Änderungen jemals überhaupt möglich sein wird.

    Außerdem ist .NET stark C#-lastig. So soll z.B. IronPython langsamer laufen als Python-Skripte, obwohl es zu CLI-Code compiliert wird :-)

    Es ist erstaunlich, daß Jython (Python in Java) deutlich schneller als IronPython läuft, obwohl doch die CLI angeblich viel besser für Sprachimplementierung geeignet sein soll als die JVM. Am meisten erstaunt mich, daß Python in der Skriptversion in den meisten Fällen am schnellsten läuft, obwohl es nicht vom JIT in Maschinencode übersetzt wird wie .NET und Java.

    http://www.smallshire.org.uk/sufficientlysmall/2009/05/22/ironpython-2-0-and-jython-2-5-performance-compared-to-python-2-5/

    Die Schere zwischen den Skriptsprachen und Java/.NET wird in Zukunft wohl noch stärker auseinanderklaffen, weil die Skriptsprachen inzwischen auch schon intern in Maschinencode übersetzt werden, z.B. Javascript in der Google V8 Engine, ohne den ganzen VM-Ballast mit sich herumzuschleppen.

  7. Re: Mono!

    Autor: ( Alternativ: kostenlos registrieren) 13.06.09 - 09:49

    hm. war bei Aldi das hirn alle? solltest wieder mal nachfüllen ...

    Alptraum schrieb:
    -------------------------------------------------------
    > Keine Ahnung von was du redest.
    > .Net ist 'n Witz!


  8. Re: So so

    Autor: hb 14.06.09 - 00:59

    so-isses schrieb:
    -------------------------------------------------------
    > Außerdem ist .NET stark C#-lastig. So soll z.B.
    > IronPython langsamer laufen als Python-Skripte,
    > obwohl es zu CLI-Code compiliert wird :-)

    Nicht dass es irgendeine Aussagekraft über das .NET hätte, aber...
    http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP20VsCPy25Perf&referringTitle=IronPython%20Performance
    Traue keiner Statistik, die du nicht selbst gefälscht hast.

    Nebenbei übersetzt Python (wie praktisch alle modernen Skriptsprachen) schon immer in Zwischencode vor der Ausführung. Die C Implementierung von Python sollte eigentlich die schnellste sein (ist sie aber trotzdem nicht in jedem Fall, siehe obiger Link). Gründe dafür ist aber nicht die Performance der Programmiersprache C oder deren Compiler, sondern Implementierungsdetails. Das sieht bei IronPython nicht anders aus.

  9. CodePlex gehört Microsoft:

    Autor: so-isses 14.06.09 - 11:36

    Zitat Google:

    "CodePlex: Microsoft's open source project hosting web site. You can use CodePlex to find open source software or create new projects to share with the world."

    Daß die "Aussagekraft" über die Performance von .NET-Sprachen bei CodePlex in eine gewisse Richtung tendiert, braucht uns also nicht zu überraschen ;-)

    Die beste Statistik ist immer noch die eigene Erfahrung. Ausprobieren!

  10. Re: CodePlex gehört Microsoft:

    Autor: hb 14.06.09 - 11:55

    so-isses schrieb:
    -------------------------------------------------------
    > Daß die "Aussagekraft" über die Performance von
    > .NET-Sprachen bei CodePlex in eine gewisse
    > Richtung tendiert, braucht uns also nicht zu
    > überraschen ;-)

    Die Benchmarks (PyStone etc) sind nicht von CodePlex oder Microsoft.

    Du meinst also, deine Aussage " So soll z.B. IronPython langsamer laufen als Python-Skripte, obwohl es zu CLI-Code compiliert wird" hat mehr Aussagekraft?

    > Die beste Statistik ist immer noch die eigene
    > Erfahrung. Ausprobieren!

    Die Implementierungen werden für unterschiedliche Aufgabenstellungen unterschiedlich sein. "A ist langsamer als B" wird immer falsch sein.

    Und genau das ist die eigentliche Überraschung. Die C-Implementierung sollte IMMER schneller sein als Alternativen. Dass dies nicht der Fall ist, zeigt, dass die C Implementierung an einigen Stellen sehr suboptimal ist (so kann sie z.B. kein Threading).

  11. Re: CodePlex gehört Microsoft:

    Autor: so-isses 15.06.09 - 08:25

    > Du meinst also, deine Aussage " So soll z.B. IronPython langsamer laufen als
    > Python-Skripte, obwohl es zu CLI-Code compiliert wird" hat mehr Aussagekraft?

    Ok, klarer ausgedrückt: IronPython läuft in manchen (allen?) Bereichen langsamer als Python-Skripte, ... Ich hab mal eine Ajax-Demo mit IronPython gesehen und hab nur mit dem Kopf geschüttelt.

    Java und .NET haben zwar noch Potential zur Optimierung, aber ob das Ganze wirklich jemals mal so effizient laufen wird, daß es vergleichbar mit Pascal- oder C++-Applikationen wird, ist sehr zweifelhaft. Ich würde mich nicht wundern, wenn MS in ein paar Jahren .NET komplett über Bord wirft und was völlig Neues aufsetzt. Das ist ja auch deren Geschäftsmodell. Apple macht es da schon etwas cleverer: Die verdonnern alle Entwickler zur Objective-C. Das läuft effizient, aber wer Objective-C mag ... nun ja, ich nicht.

    > dass die C Implementierung an einigen Stellen sehr suboptimal ist

    C ist ein Fossil aus vergangenen Zeiten. Es hat mal großartige Dienste geleistet, aber dessen Zeit als Universalsprache ist vorbei. Es macht vielleicht noch Sinn im Embedded-Bereich, wenn man extrem auf Speicher- und Zeitverbrauch optimieren muss. Aber schon bei den besseren Embedded Boards braucht man sich C nicht mehr anzutun.

    Die Zukunft liegt in hochoptimierten funktionalen Skriptsprachen, die Zugriff auf native GUIs haben. Z.B. gibt es Compiler für Lisp und Scheme, die fast so effizienten Code wie C erzeugen. Bei der heutigen Leistung von PCs merkt man es kaum, ob ein Programm 3x langsamer läuft als ein vergleichbares C++-Programm. Es macht aber sehr wohl einen Unterschied, ob die .NET- oder Java-Implementierung desselben Programms 30x langsamer läuft (bedingt durch Startzeit, Reflections, Garbage Collections etc.)

  12. Re: CodePlex gehört Microsoft:

    Autor: hb 15.06.09 - 10:18

    so-isses schrieb:
    -------------------------------------------------------
    > Ok, klarer ausgedrückt: IronPython läuft in
    > manchen (allen?) Bereichen langsamer als
    > Python-Skripte, ...

    Mit "Python-Skripte" meinst du vermutlich die Ausführung der Skripte in der Python Referenz-Implementierung, die in C geschrieben ist. IronPython führt auch "Python-Skripte" aus. Es ist nichts anderes als eine Implementierung der Sprache Python in C#, genauso wie PyPy eine Implementierung der Sprache Python in Python selbst ist.

    > Ich hab mal eine Ajax-Demo mit
    > IronPython gesehen und hab nur mit dem Kopf
    > geschüttelt.

    Und deswegen schließt du auf die Geschwindigkeit von Mono oder C# zurück? Ich habe dutzende extrem lahme Python-Programme auf der C-Referenzimplementierung gesehen. Ist deswegen C langsam? Nein.

    Die Referenzimplementierung hat einfach ein paar Flaschenhälse, die es IronPython oder sogar PyPy erlauben, in bestimmten Anwendungsfällen schneller zu sein.

    Ganz abgesehen davon, dass bei meinen Tests im Mittel C# deutlich (Faktor 10 bis 100) schneller war als Python (Referenzimplementierung). IronPython vs. C-Python als Argument gegen Mono nutzen zu wollen ist schon eine sehr abenteuerliche Argumentation.

    > C ist ein Fossil aus vergangenen Zeiten. Es hat
    > mal großartige Dienste geleistet, aber dessen Zeit
    > als Universalsprache ist vorbei.

    Ich redete nicht davon, C Programme zu schreiben, sondern vom in C geschriebenen Python-Interpreter.

    > Die Zukunft liegt in hochoptimierten funktionalen
    > Skriptsprachen,

    Für mich sind Programmiersprache Hilfsmittel, kein Selbstzweck. Unterschiedliche Sprachen haben unterschiedliche Stärken und Schwächen, und damit unterschiedliche Anwendungsbereiche. Eine für mich interessante Eigenschaft der CLI ist gerade die Möglichkeit, einfach unterschiedliche Sprachen zu kombinieren.

    > Es macht aber sehr
    > wohl einen Unterschied, ob die .NET- oder
    > Java-Implementierung desselben Programms 30x
    > langsamer läuft (bedingt durch Startzeit,
    > Reflections, Garbage Collections etc.)

    Als ob Python und Freunde keine Reflexion oder Garbage-Collection hätten...

    Willst du im Ernst behaupten, Python sei im Mittel um den Faktor 10 schneller als C#?

    Ich wähle ja selbst meistens Python, wenn ich mir die Sprache aussuchen kann, aber ehrlich sollte man schon bleiben.

  13. Re: CodePlex gehört Microsoft:

    Autor: so-isses 15.06.09 - 10:44

    > Mit "Python-Skripte" meinst du vermutlich die Ausführung der Skripte in der
    > Python Referenz-Implementierung, die in C geschrieben ist.

    Korrekt.

    > C-Python als Argument gegen Mono nutzen zu wollen ist schon eine sehr
    > abenteuerliche Argumentation.

    Nein. Eines der beworbenen Argumente für .NET war ja, daß es sprachunabhängige Programmierung ermöglicht. Das hat in der Praxis aber wenig Sinn, wenn es gravierende Performance-Unterschiede zwischen den Implementierungen gibt. Das führt dann zu Ratschlägen wie in der genannten Ajax-Demo, daß man aus Performancegründen kritische Codefragmente in IronPython durch C# ersetzen sollte.

    Es sind konzeptionelle Schwächen. Der Ansatz von Java und .NET war schon sehr gut. Aber die Praxis zeigt, daß sowas schwieriger mit akzeptabler Performance zu realisieren ist als erwartet. Momentan ist Java IMHO wegen der echten Plattformunabhängigkeit immer noch die bessere Wahl gegenüber .NET und Mono, zumal MS auch den Daumen drauf hält.

    > Eine für mich interessante Eigenschaft der CLI ist gerade die Möglichkeit,
    > einfach unterschiedliche Sprachen zu kombinieren.

    Wenn alle Sprachen etwa gleich performant wären: Ja.

    > Python sei im Mittel um den Faktor 10 schneller als C#?

    Nein. ich habe gesagt, daß

    1) IronPython manchmal (oft?) langsamer läuft als CPython.

    2) .NET- und Java-Anwendungen in der Regel spürbar langsamer laufen als Skripte, bedingt durch lange Startzeiten, Reflections etc.

    Es ist ja schön und gut, wenn eine .NET- und Java-Anwendung in Bytecode oder per Jit in Maschinencode übersetzt wird. Aber in der Praxis sind diese Anwendungen oft langsamer als Skripte. Die eigentliche Langsamkeit der Skripte wird durch die extrem kurzen Startzeiten wettgemacht. Auch die JIT-Compilierung zur Laufzeit führt zu spürbaren Verzögerungen, die bei Skripten nicht vorkommen.

    Gibt es bei .NET/Mono eigentlich eine Cache-Funktion für Binaries?

  14. Re: CodePlex gehört Microsoft:

    Autor: hb 15.06.09 - 11:14

    so-isses schrieb:
    -------------------------------------------------------
    > Nein. Eines der beworbenen Argumente für .NET war
    > ja, daß es sprachunabhängige Programmierung
    > ermöglicht.

    Und genau das tut es auch.

    > Das führt
    > dann zu Ratschlägen wie in der genannten
    > Ajax-Demo, daß man aus Performancegründen
    > kritische Codefragmente in IronPython durch C#
    > ersetzen sollte.

    Es ist generell sinnvoll, Flaschenhälse in Programmen durch eine Implementierung in einer schnelleren Sprache zu ersetzen.

    > Es sind konzeptionelle Schwächen.

    Die da wären? Selbst wenn die IronPython Implementierung langsamer wäre (was die Python Benchmarks, die nicht von MS erfunden wurden, bezweifeln lassen), wäre das noch keine konzeptionelle Schwäche.

    > Momentan ist Java IMHO wegen der echten
    > Plattformunabhängigkeit immer noch die bessere
    > Wahl gegenüber .NET und Mono, zumal MS auch den
    > Daumen drauf hält.

    Ähm, Sun hat Java zwei mal von einem angestreben Standardisierungsprozeß zurückgezogen, weil es befürchtet hat, dann die Alleinherrschaft über Java aufgeben zu müssen. Microsoft hat .NET ECMA und ISO-Standardisiert. Zu viel zum Thema "Daumen drauf haben".

    > Wenn alle Sprachen etwa gleich performant wären:
    > Ja.

    Dann wäre die Kombination nur halb so sinnvoll.

    Vermutlich meinst du: Wenn die .NET Implementierungen der Sprachen genauso performant wie ihre jeweiligen Referenz-Implementierungen wären.

    > 2) .NET- und Java-Anwendungen in der Regel spürbar
    > langsamer laufen als Skripte, bedingt durch lange
    > Startzeiten, Reflections etc.

    Nochmal: Python hat ebenfalls eine Startzeit (bei nicht vorkompilierten Skripte sogar eine erhebliche), und Reflexion satt. Reflexion ist (über Duck-Typing) sogar eins der grundlegenden Konzepte hinter Python.

    > Es ist ja schön und gut, wenn eine .NET- und
    > Java-Anwendung in Bytecode oder per Jit in
    > Maschinencode übersetzt wird. Aber in der Praxis
    > sind diese Anwendungen oft langsamer als Skripte.

    Deine "Praxis" scheint anders zu sein als meine. Wie gesagt: Meine Erfahrungen sind, dass C# um den Faktor 10 bis 100 schneller ist als CPython. Das kommt aber natürlich auf die jeweilige Aufgabenstellung an. Alle Sprachen haben Stärken und Schwächen. Womit wir wieder bei der CLI wären.

    > Die eigentliche Langsamkeit der Skripte wird durch
    > die extrem kurzen Startzeiten wettgemacht.

    Auch hier ist unsere Wahrnehmung unterschiedlich.

    > Auch
    > die JIT-Compilierung zur Laufzeit führt zu
    > spürbaren Verzögerungen, die bei Skripten nicht
    > vorkommen.

    > Gibt es bei .NET/Mono eigentlich eine Cache-Funktion für Binaries?

    In Mono kann man zwischen 3 Ausführungsarten wählen:
    JIT
    AOT (ahead-of-time compiler)
    Interpreter

    Vielleicht solltest du dir das Projekt wenigstens kurz ansehen, bevor du es kritisierst.

  15. Re: CodePlex gehört Microsoft:

    Autor: csharp 15.06.09 - 12:24

    Was ist denn das bitte für eine sinnfreie Auseinandersetzung???
    Das ganze Thema ist irgendwie total am Wald vorbei argumentiert.

    - .NET ist eine Plattform von Microsoft FÜR Microsoft Windows.
    - Java ist Plattformabhängig (solange es eine JVM für deine Plattform gibt)
    - Python ist eine Skriptsprache
    - .NET ist keine Skriptsprache
    - Java ist keine Skriptsprache
    - mono ist aus ursprünglicher Sicht ein Reverse-Engineering Hack von .NET 1.0

    Die senile Behauptung irgend eine Sprache sei schneller als eine andere ist mal sowas von daneben, dass ich nur noch lachen kann.
    Im Ernst: Jede Sprache hat Vorteile und Nachteile. Jede Sprache lässt sich in manchen Gebieten gut, in anderen schlechter und in wenigen Gebieten garnicht einsetzen. Das hängt aber vom Einzelfall ab und nicht von der Meinung des Entwicklers.

    Solche Entscheidungen werden von einem Team aus Projektleiter, Technischem Projektleiter, evtl. Gutachter und dem Kunden festgelegt. Wer glaubt er könne als Entwickler das Zünglein an der Wage spielen, muss sich letzten endes wundern wenn er Arbeitslos ist.

  16. Re: CodePlex gehört Microsoft:

    Autor: so-isses 15.06.09 - 12:36

    > Es ist generell sinnvoll, Flaschenhälse in Programmen durch eine
    > Implementierung in einer schnelleren Sprache zu ersetzen.

    Bei Skriptsprachen ja. Aber nicht bei Mono/.NET/Java, die nach Bytecode/Maschinencode übersetzen. Da darf ich Performance einfach mal voraussetzen.

    > Microsoft hat .NET ECMA und ISO-Standardisiert. Zu viel
    > zum Thema "Daumen drauf haben".

    Das ist der berühmte Unterschied zwischen Theorie und Praxis :-)

    MS hat auch OOXML "standardisiert". Was soll man davon halten?

    http://www.sueddeutsche.de/wirtschaft/319/419083/text/

    > Dann wäre die Kombination nur halb so sinnvoll.

    Wieso? Mehrere Sprachen machen für mich nur Sinn, a) wenn sie für mein Anwendungsgebiet geeignet sind und b) wenn ich ein Team von Entwicklern habe, die unterschiedliche Sprachen gelernt haben. Aber nicht, weil man manche Dinge performanter gestalten muss.

    > Vermutlich meinst du: Wenn die .NET Implementierungen der Sprachen genauso
    > performant wie ihre jeweiligen Referenz-Implementierungen wären.

    Von einer Plattform, die für sich reklamiert, sprachunabhängig zu sein und Anwendungen auf Byte- oder sogar Machinencode-Ebene ausführen zu können, erwarte ich, daß alle Implementierungen ähnliche Ausführungszeiten haben. Wenn die "Referenzimplementierung" C# um Größenordnungen flotter ist als die anderen Implementierungen, dann stimmt entweder am ganzen Mono/NET-Konzept nicht, oder die "Sprachenunabhängigkeit" ist nur eine Werbefloskel. Denn was nützen mir die anderen Sprachen, wenn ich immer wieder Teile nach C# umschreiben muss?

    > Nochmal: Python hat ebenfalls eine Startzeit (bei nicht vorkompilierten
    > Skripte sogar eine erhebliche), und Reflexion satt. Reflexion ist (über
    > Duck-Typing) sogar eins der grundlegenden Konzepte hinter Python.

    Die Startzeiten der Skripte sind um Größenordnungen kleiner als bei Java und Mono.

    > Deine "Praxis" scheint anders zu sein als meine. Wie gesagt: Meine
    > Erfahrungen sind, dass C# um den Faktor 10 bis 100 schneller ist als CPython.
    > Das kommt aber natürlich auf die jeweilige Aufgabenstellung an. Alle Sprachen
    > haben Stärken und Schwächen. Womit wir wieder bei der CLI wären.

    Dein Vergleich C# mit CPython ist wie Äpfel mit Birnen. Ich beziehe mich auf CPython vs. IronPython.

    > In Mono kann man zwischen 3 Ausführungsarten wählen:
    > JIT
    > AOT (ahead-of-time compiler)
    > Interpreter

    Also immer noch kein Cache.

    > Vielleicht solltest du dir das Projekt wenigstens kurz ansehen, bevor du es
    > kritisierst.

    Ich habe mir Mono über die Jahre mehrmals angesehen. Schade, daß soviel Energie in das Projekt gesteckt wird anstatt die Synergien für das freie Java zu nutzen. Wenn ich schon .NET brauche, denn benutze ich auch .NET/Windows und schlage mich nicht mit Mono-Inkompatibilitäten herum. Auf Servern mag das vielleicht noch Sinn machen (Virenresistenz etc.), aber da geht man immer Risiken wegen möglicher Inkompatiblitäten zu .NET ein.

    Wie gesagt, halte ich Java für die bessere Wahl (bzw. das geringere Übel). Da hat man wenigstens noch freie Auswahl betreffs Betriebssystem und Hardware.

  17. Re: CodePlex gehört Microsoft:

    Autor: so-isses 15.06.09 - 12:39

    > Die senile Behauptung irgend eine Sprache sei schneller als eine andere ist mal
    > sowas von daneben, dass ich nur noch lachen kann.

    Offenbar hast du unsere Beiträge nicht gelesen. Kurz gesagt: Es geht um den Vergleich zwischen gleichen Sprachen auf Skriptebene und in .NET/Mono/Java. Also z.B. CPython vs. IronPython vs. JPython.

    > Solche Entscheidungen werden von einem Team aus Projektleiter, Technischem
    > Projektleiter, evtl. Gutachter und dem Kunden festgelegt. Wer glaubt er könne
    > als Entwickler das Zünglein an der Wage spielen, muss sich letzten endes
    > wundern wenn er Arbeitslos ist.

    Genau diese Einstellung ist der Grund, warum so viele IT-Projekte an die Wand gefahren werden. Ich war selbst in großen Unternehmen beschäftigt und weiß, wovon ich rede.

  18. Re: CodePlex gehört Microsoft:

    Autor: hb 15.06.09 - 13:34

    so-isses schrieb:
    -------------------------------------------------------
    > Bei Skriptsprachen ja. Aber nicht bei
    > Mono/.NET/Java, die nach Bytecode/Maschinencode
    > übersetzen. Da darf ich Performance einfach mal
    > voraussetzen.

    > Das ist der berühmte Unterschied zwischen Theorie
    > und Praxis :-)

    Weder ECMA noch ISO sind "Theorie". Das ist Realität.

    > Wieso? Mehrere Sprachen machen für mich nur Sinn,
    [...]
    > Aber nicht, weil man manche Dinge performanter
    > gestalten muss.

    Da unterscheiden wir uns schon wieder. Ich schreib das Number-Cruncher Backend lieber in Fortran oder wenn es sein muss noch in C, und die GUI dazu in Python, oder von mir aus sogar Javascript.

    > Wenn die
    > "Referenzimplementierung" C# um Größenordnungen
    > flotter ist als die anderen Implementierungen,

    Zum 5. Mal: Das ist sie nicht. Siehe Benchmarks.

    > dann stimmt entweder am ganzen Mono/NET-Konzept
    > nicht,

    Was bitte schön hat das mit dem Konzept zu tun?

    Ich kann dir einen Compiler für jede Sprache in C schreiben, die buggy und schnarchlahm ist. Habe ich damit bewiesen, dass mit C etwas "konzeptionell nicht stimmt"?

    Deine Argumentation ist unseriös.

    > Die Startzeiten der Skripte sind um
    > Größenordnungen kleiner als bei Java und Mono.

    Äpfel und Birnen. Oder vergleichst du den Mono Interpreter mit Python?

    > Dein Vergleich C# mit CPython ist wie Äpfel mit
    > Birnen. Ich beziehe mich auf CPython vs.
    > IronPython.

    Dann bist du leider Off-Topic, da du versuchst, angebliche Mängel in IronPython als Mono-Problem, oder sogar als "konzeptionelles" Problem von .NET anzuprangern.


    > Also immer noch kein Cache.

    Das kommt darauf an, was du mit "Cache" meinst. Ein AOT ist ein Cache für einen JIT.

    > Ich habe mir Mono über die Jahre mehrmals
    > angesehen.

    Komisch, dass du dann so wenig darüber weißt.

  19. Re: CodePlex gehört Microsoft:

    Autor: so-isses 15.06.09 - 14:33

    > Äpfel und Birnen. Oder vergleichst du den Mono Interpreter mit Python?

    Lassen wir es bleiben, ich hab keine Lust, mich dauernd zu wiederholen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. SAP Solution Architect (m/w/d)
    IT-Consult Halle GmbH, Halle
  2. Key User ERP (m/w/d)
    Hays AG, Kempten
  3. (Junior) DevOps Engineer (m/w/d)
    DRK-Blutspendedienst Baden-Württemberg - Hessen gem. GmbH, Frankfurt
  4. Spezialist*in als Digitalisierungspartner*in im Landesbüro
    Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH, Kiew (Ukraine)

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. MSI Optix MAG322CQR 31,5 Zoll Curved WQHD 165Hz für 350€, Crucial Ballistix RGB 16GB Kit...
  2. 99,90€ (Vergleichspreis 154€)
  3. 99,99€ (Release 04.03.2022)
  4. (u. a. Cooler Master CK530 V2 Gaming-Tastatur für 59,90€, Apacer AS350X 1TB SATA-SSD für 86...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Zum Tod von Sir Clive Sinclair: Der ewige Optimist
Zum Tod von Sir Clive Sinclair
Der ewige Optimist

Mit Clive Sinclair ist einer der IT-Pioniere Europas gestorben. Der Brite war viel mehr als nur der Unternehmer, der mit den preiswerten ZX-Heimrechnern die Mikrocomputer-Revolution vorantrieb.
Ein Nachruf von Martin Wolf

  1. Molekulardynamik-Simulation Niemand faltet Proteine schneller als Anton
  2. Materialforschung Indische Forscher entwickeln selbstheilenden Kristall
  3. Future Insight Prize 2021 US-Forscher wollen Plastikmüll in Nahrungsmittel verwandeln

Custom Keyboard GMMK Pro: Tastatur selbst bauen macht Spaß
Custom Keyboard GMMK Pro
Tastatur selbst bauen macht Spaß

Wenn die mechanische Tastatur nicht ausreicht, kommt der Selbstbau in Frage. Ich habe klein angefangen und es am GMMK Pro ausprobiert.
Ein Erfahrungsbericht von Oliver Nickel

  1. ZSA Moonlander im Test Das Tastatur-Raumschiff
  2. Alloy Origins Core im Test Full Metal Keyboard
  3. Duckypad Mechanisches Tastenpad ermöglicht Makros und Tastenkürzel

Bundestagswahl 2021: Die Parteien im Datenschutz-Check
Bundestagswahl 2021
Die Parteien im Datenschutz-Check

Gesagt, getan? Wir haben geprüft, was CDU, SPD, Grüne, FDP, Linke und AfD zum Datenschutz fordern - und was sie selbst auf ihren Webseiten umsetzen.
Eine Analyse von Christiane Schulzki-Haddouti

  1. Bundestagswahl Wahl-O-Mat 2021 ist online
  2. Bundestagswahl 2021 Einige Wahlbehörden nur über unsichere Mailserver erreichbar
  3. Kandidaten-Triell Sogar Gendern ist wichtiger als Digitalisierung