C# vs Java



  • Was sind die Vor-/Nachteile von C# ggüber Java?



  • C# ist wesentlich moderner und hat nicht Designschwächen wie Type Erasure.
    Nachteil: Du bist ziemlich an MS gebunden. Mono ist nicht 100% kompatibel.

    L. G.,
    IBV



  • IBV schrieb:

    C# ist wesentlich moderner und hat nicht Designschwächen wie Type Erasure.

    Kannst du das genauer ausführen?



  • Benutzernamen ein schrieb:

    IBV schrieb:

    C# ist wesentlich moderner und hat nicht Designschwächen wie Type Erasure.

    Kannst du das genauer ausführen?

    http://en.wikipedia.org/wiki/Type_erasure



  • Benutzernamen ein schrieb:

    IBV schrieb:

    C# ist wesentlich moderner und hat nicht Designschwächen wie Type Erasure.

    Kannst du das genauer ausführen?

    Schau dir mal die Features von Java 8 an. Das hat C# schon lange und noch einiges mehr und bis Java 8 mal in Unternehmen angekommen ist, vergehen mind. (!) 5 Jahre!
    Wenn du auf die JVM setzen willst, ist scala deutlich mächtiger. Aber selbst scala hat Einschränkungen, da sich einige Features wie Pattern Matching mit Generics aufgrund von Type Erasure nicht umsetzen lassen. Sun und Oracle wagen es leider auch nicht alter Zöpfe abzuschneiden...

    L. G.,
    IBV





  • Fängt schon mal mit WPF an. Java hat nicht mal ansatzweise etwas vergleichbares.

    Wir arbeiten durchgehend mit .NET und ich finde schon die Visual Studios deutlich angenehmer als Eclipse oder so. .NET ist eben schöner



  • Und aus diesem Grund werden wir auch weiterhin bei den ausgereiften
    HighEnd-Produkten des bewährten Weltmarktführers bleiben, mit denen
    wir in den vergangenen Jahren hervorragende Erfahrungen gemacht
    haben.

    Die kosten zwar ein bisschen mehr, überzeugen aber durch einen
    schnellen Return on Investment durch vorbildliche Sicherheit,
    Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit,
    und Kontinuität in der Produktpolitik.

    Und das ist es schliesslich, worauf es Experten wie meinen
    hochqualifizierten Mitarbeitern und mir im harten Tagesgeschäft des
    internationalen Wettbewerbs ankommt.

    Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert
    durch weltfremde Langzeitstudenten mit Taxischein, hat keinerlei
    Chance, will man sich tagtäglich aufs Neue den Herausforderungen der
    Globalisierung erfolgreich stellen. Da können einfach nur Lösungen
    von Profis für Profis zum Einsatz kommen, die hervorragend durch das
    Portfolio der Redmonder Gastronomie-Spezialisten abgedeckt werden.



  • Chefsoftwareentiwckler schrieb:

    Und aus diesem Grund werden wir auch weiterhin bei den ausgereiften
    HighEnd-Produkten des bewährten Weltmarktführers bleiben, mit denen
    wir in den vergangenen Jahren hervorragende Erfahrungen gemacht
    haben.

    Die kosten zwar ein bisschen mehr, überzeugen aber durch einen
    schnellen Return on Investment durch vorbildliche Sicherheit,
    Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit,
    und Kontinuität in der Produktpolitik.

    Und das ist es schliesslich, worauf es Experten wie meinen
    hochqualifizierten Mitarbeitern und mir im harten Tagesgeschäft des
    internationalen Wettbewerbs ankommt.

    Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert
    durch weltfremde Langzeitstudenten mit Taxischein, hat keinerlei
    Chance, will man sich tagtäglich aufs Neue den Herausforderungen der
    Globalisierung erfolgreich stellen. Da können einfach nur Lösungen
    von Profis für Profis zum Einsatz kommen, die hervorragend durch das
    Portfolio der Redmonder Gastronomie-Spezialisten abgedeckt werden.

    eben, Microsoft Produkte sind von Profis für Profis.
    Das sieht man auch schon bei den entsprechenden Konferenzen, alle schön in Anzug und mit Krawatte. Kein Vergleich mit den Linuxbastlern die mit T Shirt und kurzer Hose, vielleicht sogar mit Hawaii Hemd rumsitzen.

    Mal im Ernst: C# mag zwar eine schöne Sprache sein, aber dies oder jenes tolles Sprachfeature* kann den größten Nachteil niemals wettmachen: C# ist ein Microsoft Produkt, und ist in der Microsoft Welt daheim. Solange man nur für Windows OS programmiert, ist man damit sicher gut bedient.
    Aber wehe es geht mal Richtung Linux oder zu anderen OS. Da wäre man mit Java besser bedient gewesen.

    * noch ein Nachsatz zu den Sprach Features: diese mögen zwar nett sein, aber ich sehe den großen Vorteil irgendwie nicht. Ich bezweifle mal, dass der Produktivitätsgewinn wirklich so groß ist. Viel wichtiger ist Erfahrung in der entsprechenden Sprache und den dazugehörenden Bibliotheken. Vor allem das Vorhandensein von Bibliotheken ist für mich wichtig, viel wichtiger als Sprachfeatures.



  • gfdgfdgfdgd schrieb:

    eben, Microsoft Produkte sind von Profis für Profis.
    Das sieht man auch schon bei den entsprechenden Konferenzen, alle schön in Anzug und mit Krawatte. Kein Vergleich mit den Linuxbastlern die mit T Shirt und kurzer Hose, vielleicht sogar mit Hawaii Hemd rumsitzen.

    Auf wie vielen MS-Konferenzen warst du schon? Also ich habe bisher ein relativ gemischtes Publikum gesehen, Anzüge waren zwar auch vertreten aber ebenso auch lockere Kleidung (okay, kurze Hosen habe ich bislang noch nicht gesehen).

    gfdgfdgfdgd schrieb:

    Mal im Ernst: C# mag zwar eine schöne Sprache sein, aber dies oder jenes tolles Sprachfeature* kann den größten Nachteil niemals wettmachen: C# ist ein Microsoft Produkt, und ist in der Microsoft Welt daheim. Solange man nur für Windows OS programmiert, ist man damit sicher gut bedient.

    Mit C# in Kombination mit Xamarin kommt man schon recht weit (Windows, MacOS, iOS, Android, Windows Phone und WinRT und natürlich auch Web [ASP.Net]).

    gfdgfdgfdgd schrieb:

    noch ein Nachsatz zu den Sprach Features: diese mögen zwar nett sein, aber ich sehe den großen Vorteil irgendwie nicht.

    Ich habe bereits mit beiden Sprachen gearbeitet, ich weiß nicht wo Java aktuell steht (meine kürzlichen Experimente in Zusammenhang mit Minecraft Mods haben mich aber nicht unbedingt begeistert), aber ich sehe schon einige Vorteile von C# - auch in Zusammenhang mit der Produktivität.

    Richtig ist aber durchaus das Erfahrungen in einer Sprache häufig wichtiger sind, wenn man sich in eine davon nicht Einlernen muss, ist das durchaus ein Argument.



  • C# kann nur die falsche Wahl sein.

    Begründung:

    Vor einiger Zeit wurde hier in diesem Forum von D mit der Begründung abgeraten, dass bei D zwischen D 1.0 und D 2.0 ein Bruch besteht und man nicht seine Entwicklung auf eine Sprache bauen könnte, die keine langfristige dauerhafte Konsistenz gewährleistet.
    Wenn man das so betrachtet, dann muss man aber auch den gleichen Maßstab bei C# anlegen, denn C# Programme, die für .Net 1.0 oder .Net 2.0 geschrieben wurden, laufen unter Umständen, je nach den Features die man verwendet hat, z.b. Generics, nicht mehr auf .Net 3.0 und .Net 4.0.

    C# hat durch mehrere Änderungen in der Sprache, die eine Änderung der Runtime bedingten bewiesen, dass es keine Langzeitsicherheit gewährleisten kann.
    Das zeigt auch diese Tabelle mit der Zeile "Migration compatibility":
    http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java#Generics

    Daraus folgt, nur Java gewährleistet Langzeitsicherheit.
    Was früher für Java 1.2 geschrieben und compiliert wurde, läuft heutzutage immer noch auf einer aktuellen JVM.
    Bei C# ist das nicht so, weswegen Microsoft auch x .Net Versionen auf Windows installiert um alle Varianten abdecken zu können.



  • Totschlagargument schrieb:

    Vor einiger Zeit wurde hier in diesem Forum von D mit der Begründung abgeraten, dass bei D zwischen D 1.0 und D 2.0 ein Bruch besteht und man nicht seine Entwicklung auf eine Sprache bauen könnte, die keine langfristige dauerhafte Konsistenz gewährleistet.

    Nach diesem Argument müsste man von den meisten Sprachen abraten.

    Totschlagargument schrieb:

    Wenn man das so betrachtet, dann muss man aber auch den gleichen Maßstab bei C# anlegen, denn C# Programme, die für .Net 1.0 oder .Net 2.0 geschrieben wurden, laufen unter Umständen, je nach den Features die man verwendet hat, z.b. Generics, nicht mehr auf .Net 3.0 und .Net 4.0.

    Aber sie laufen noch immer in der entsprechenden Runtime, die 1.0-1.1, 2.0-3.5 und 4.0-4.5.1 können parallel zueinander installiert werden.

    Totschlagargument schrieb:

    Daraus folgt, nur Java gewährleistet Langzeitsicherheit.
    Was früher für Java 1.2 geschrieben und compiliert wurde, läuft heutzutage immer noch auf einer aktuellen JVM.

    Merkwürdig nur das ich in meiner aktiven Java-Zeit (um 1.4 rum) regelmäßig von Java-Versionsinkompatibilitäten gehört habe (Und zwar von Projektleitern in Java-Projekten). Und heute (aber bin außer kurzen Ausflügen nicht mit Java beschäftigt) höre ich noch immer von Zeit zu Zeit ähnliches. Kann sein das sich dies aber auf vergangene Probleme bezieht.

    Totschlagargument schrieb:

    Bei C# ist das nicht so, weswegen Microsoft auch x .Net Versionen auf Windows installiert um alle Varianten abdecken zu können.

    1. Installiert MS in der Regel eine Version, auch wenn man die anderen zusätzlich installieren kann.
    2. Es gibt aktuell 3 Verschiedene Runtimezweige, in diesem ersetzt die Neueste Version immer die Vorherigen.
    3. Manchmal ist das Entrümpeln einer Sprache kein Nachteil. Problematisch ist nur wenn man dies ständig tut.



  • Wir schreiben das Jahr 2014 und GC Sprachen sind immer noch am Leben. Witzig.
    Sogar die Objective-C Leute haben erkannt, dass das alles Mist ist.



  • Kellerautomat schrieb:

    Wir schreiben das Jahr 2014 und GC Sprachen sind immer noch am Leben. Witzig.

    Und die ganzen neuen Sprachen haben auch nen GC. Heute nimrod angeschaut. Echt genial bis auf den GC.



  • IBV schrieb:

    Schau dir mal die Features von Java 8 an. Das hat C# schon lange und noch einiges mehr und bis Java 8 mal in Unternehmen angekommen ist, vergehen mind. (!) 5 Jahre!

    Wir verwenden Java 8 in Produktivcode. Ist ein großes Projekt.

    Java ist einfach eine optimale Wahl für cross Platform + high Performance.



  • Ethon schrieb:

    cross Platform + high Performance

    selten so gelacht 😃



  • Kellerautomat schrieb:

    Ethon schrieb:

    cross Platform + high Performance

    selten so gelacht 😃

    Was ist besser?
    Jetzt kommt sicher C++ oder etwas ähnliches. 🙄


  • Mod

    Ethon schrieb:

    Kellerautomat schrieb:

    Ethon schrieb:

    cross Platform + high Performance

    selten so gelacht 😃

    Was ist besser?

    Besser? Java erfüllt doch gerade diese Punkte nicht. Man ist an eine Plattform gebunden und der erste Gedanke den die meisten Leute zu Java haben ist "langsam". Letzteres mag zwar nicht mehr ganz so schlimm sein wie vor 15 Jahren, aber wenn man von High Performance redet, dann meint man normalerweise etwas, wo die Unterschiede zwischen Fortran und C(++) relevant sind, um mal ein Beispiel aus einem kürzlich vorgekommenen Thread zu zitieren. Java spielt da in einer ganz anderen Liga.

    Jetzt kommt sicher C++ oder etwas ähnliches.

    Im Prinzip ja. Ebenso die anderen großen compilierten Sprachen wie C und Fortran. Plattformvoraussetzung ist eben nicht das Vorhandensein einer fetten JVM, sondern bloß die Möglichkeit, einen Compiler auf der Plattform zu bootstrappen. Letzteres hat man immer, denn sonst wäre die Plattform nutzlos*. Und wie schon gesagt, auch wenn Java mächtig aufgeholt hat, kann es designbedingt niemals diese Sprachen von der Performance einholen.

    *: Es gibt ja sogar C-Compiler für die JVM 🙂



  • SeppJ schrieb:

    Und wie schon gesagt, auch wenn Java mächtig aufgeholt hat, kann es designbedingt niemals diese Sprachen von der Performance einholen.

    Das ist uebrigens ein guter Punkt. Ich koennte mir durchaus vorstellen, dass eine C++ VM statisch kompiliertes C++ outperformen kann durch Optimierungen zur Laufzeit. Das collapsen von Laufzeit-Konstanten koennte beispielsweise sehr interessant sein.
    Ich vermute mal, dass das einfach nur deshalb nicht gemacht wird, weil die C++ Programmierer eine VM direkt mit langsam verbinden. Ich bin davon ueberzeugt, dass das nicht so sein muss.



  • Die VM sehe ich weniger als das Problem - zumindest nicht grundsätzlich. LLVM erzeugt auch erstmal VM Code, und dass der daraus erzeugte Maschinencode recht schnell läuft ist ja nix neues.

    Ich schätze die grösseren Bremsen bei Java sind eher "keine value types", das Memory-Model, der GC, "alles virtual" und "alles safe" (Bounds-Checks, nur checked Casts etc.). Und vielleicht dass das Ding als Stack-Machine statt als Unlimited-Register-Machine ausgelegt ist.
    Die Effekte können durch die VM und die verzögerte JIT Kompilierung zwar deutlich gelindert werden, aber so richtig flott wird die Sache dadurch halt nicht.

    Allerdings werden die Startup-Zeiten dadurch *furchtbar*.
    OK, für Server oder lang laufende Programme ist das natürlich egal.


Anmelden zum Antworten