C# oder Java
-
Hallo,
worauf wuerdet ihr euch spezialisieren. Java oder C# ?
C# ist ja schon komplizierter als Java. Aber mir kommt es so vor als ob Java weit mehr Entwickler hat. Sind C# Stellen genauso intressant wie Java Stellen?
-
C#
-
die Frage ist jetzt echt wichtig. Ich bewerbe mich gerade als Softwareentwickler und persoenlich wuerde ich Java bevorzugen, es ist weit einfacher als C# und das Oekosystem ist schon umfangreicher. Java ist glaub ich auch performanter oder. C# bedeutet was backend betrifft am Ende ja dann ASP.NET .
-
C# ist mächtiger, läuft aber nicht auf so vielen Plattformen.
-
worauf wuerdet ihr euch spezialisieren. Java oder C# ?
Ich bewerbe mich gerade als Softwareentwickler und persoenlich wuerde ich Java bevorzugen,Ich würde weder Java noch C# als "Spezialisierung" bezeichnen. Gute Kenntnisse in mindestens einer OO-fähigen Programmiersprache gehören zum Grundlagenwissen für Softwareentwickler.
Wenn du beide Sprachen noch nicht kennst (was ich daraus schließe, dass du fragst, welche du lernen sollst), womit bewirbst du dich dann eigentlich?
-
nee ich kenn beide und stufe mich in beiden als mittelpraechtig ein.
Nun moechte ich mich aber spezialisieren. Das heisst danach beherrsche ich diese Sprache zu 100% und auch die ganzen Dinge darum . Eigentlich sollte man ja noch JavaScript hinzunehmen oder Scala. Ach es ist echt verrueckt mit diesen hunderten von Sprachen
-
C++
-
Nachfrage gibts für beide Sprachen. Beachte, dass du dich mit C# wahrscheinlich auch auf Windows festlegst. Mit Java bist du unabhängiger vom Betriebssystem (falls das für dich eine Rolle spielt).
-
(C# == Windows stimmt seit .NET Core nicht mehr. Just FYI.)
MfG SideWinder
-
Ich hab ca 20 Vorstellungsgespraeche fuer Java.
Nur morgen da soll ich zu einer Firma die mit PHP entwickelt. Ich halte ja von PHP nicht so wahnsinnig viel. Oft sind Projekte historisch gewachsen und muessen es halt noch benutzen. Java ist doch viel besser als PHP oder. Jedenfalls wollte der Entwicklungsleiter meiner alten Firma die gesamte ueber 10 Jahre gewachsene Software in Java umschreiben
-
Irgendwie bist du aber auch so ein Javafanboy.
Warum fragst du eigentlich, wenn du es sowieso schon weißt.
Dir wird C# empfohlen. C++ nahegelegt.
Und trotzdem bleibst du bei deiner Java-Meinung.
Dein einziges Argument für Java waren bisher Plattformunabhängigkeit, Einfachheit und Performance.
Java ist an die JRE gebunden. Diese muss für die entsprechenden Plattformen verfügbar sein. Das ist nicht unbedingt meine Definition von Unabhängigkeit.
Wenn du außerdem eine einfache Sprache haben willst, dann nimm Javascript. Noch einfacher.
Je einfacher aber eine Sprache wird, desto weniger mächtig wird sie üblicherweise.
Wenn du es ganz einfach haben willst, kannst du dir auch deine GUIs zusammenklicken und den Backendpart mit Javascript schreiben. Einfach sollte absolut kein Kriterium sein.
Und zuletzt zur Performance: Java ist nicht einmal unbedingt schneller als C# und deutlich langsamer als C und C++.
C# ist tatsächlich in einigen Bereichen schneller, in anderen ein wenig langsamer. Wenn du aber eine zu interpretierende Sprache nimmst, dann ist dir in der Regel die Performance sowieso egal. Sonst würdest du schlauerweise keine solche wählen.
Java ist bei weitem nicht so toll wie du zu denken scheinst.
-
ja aber was ist mit PHP
Wuerde jemand heute fuer ein neues System PHP verwenden. Oder ist PHP tot ?
-
WhoIsMichael schrieb:
ja aber was ist mit PHP
-
Not-You schrieb:
...
Und zuletzt zur Performance: Java ist nicht einmal unbedingt schneller als C# und deutlich langsamer als C und C++.
C# ist tatsächlich in einigen Bereichen schneller, in anderen ein wenig langsamer. Wenn du aber eine zu interpretierende Sprache nimmst, dann ist dir in der Regel die Performance sowieso egal. Sonst würdest du schlauerweise keine solche wählen.
Java ist bei weitem nicht so toll wie du zu denken scheinst.Wieso hält sich immer noch dieser Mythos von "interpretierende Sprache" bei C# und Java? Es gibt schon seit Jahren Just-in-time compilation (JIT), der nativen Code erzeugt (welcher in Teilen sogar schneller als statisch kompilierter C bzw C++ Code ist).
-
C# und Java waren ohnehin nie eine interpretierte Sprache, da immer der Bytecode für die Java VM compiliert wurde.
Das war auch schon vor der Zeit der Just in Time Compiler so.
-
Der Bytecode muss nun einmal immer wieder interpretiert werden. Die JRE ist schließlich auch nur eine Art Interpreter.
Und eben die Erzeugung von nativem Code sorgt für den Overhead.
Wie genau soll so etwas bitteschön schneller sein können als eine bereits in nativem Code vorhandenes Programm?
Eigentlich alle Benchmarks, die ich kenne, zeigen einen Vorsprung von C und C++ gegenüber Java. Java und C# sind rein von der Geschwindigkeit sehr ähnlich.
-
Not-You schrieb:
Wie genau soll so etwas bitteschön ...
Ich habe nicht die geringste Lust, Fragen zu beantworten, die in derart arrogantem Tonfall hingerotzt werden.
-
Not-You schrieb:
Der Bytecode muss nun einmal immer wieder interpretiert werden. Die JRE ist schließlich auch nur eine Art Interpreter.
Und eben die Erzeugung von nativem Code sorgt für den Overhead.
Wie genau soll so etwas bitteschön schneller sein können als eine bereits in nativem Code vorhandenes Programm?
Eigentlich alle Benchmarks, die ich kenne, zeigen einen Vorsprung von C und C++ gegenüber Java. Java und C# sind rein von der Geschwindigkeit sehr ähnlich.Überleg mal, warum erzeugte Java Bytecode, wenn es vor Java schon interpretierte Skriptsprachen gab?
Vielleicht kommst du selbst auf die Antwort, ich schließe mich Printes Kommentar somit an.
-
Ich versteh aber auch nicht warum das Ausführen von Bytecode ohne JIT kein Interpretieren mehr sein soll. Die Referenzimplementierung von Python erzeugt auch Bytecode, der dann aber trotzdem interpretiert und nicht JIT compiled wird.
Allgemein finde ich die Diskussion im Bezug von Sprachen aber eh hinfällig. C++ ist nicht AOT compiled wenn man den von CLang generierten LLVM-IR Bytecode mit dem LLVM Interpreter oder LLVM JIT ausführt. Java ist nicht mehr JIT compiled, wenn ich den GCJ verwende um es AOT zu compilen. Lua ist nicht mehr interpretiert wenn ich LuaJit verwende.
Die Bezeichnungen passen nur wenn man sich Implementierungen anguckt, keine Sprachen.
-
Tobiking2 schrieb:
Ich versteh aber auch nicht warum das Ausführen von Bytecode ohne JIT kein Interpretieren mehr sein soll. Die Referenzimplementierung von Python erzeugt auch Bytecode, der dann aber trotzdem interpretiert und nicht JIT compiled wird.
Eigentlich hat es historische Gründe.
Heute kannst du eine Skriptsprache natürlich nativ compilieren, früher war das aber eher nicht so, da liefen die alle im Interpreter.BASIC lief im Interpreter
C wurde compiliert
Java war Mitte der 90er mit dem eigenen Bytecode und der VM was neues und von der Performance irgendwo zwischen Interpreter und Compiler.Interpretiert wurde die Hochsprache, der Bytecode läuft dagegen eher in einer virtuellen Maschine und bei echten nativen Binaries werden eben die Opcodes von der CPU ausgewertet, aber interpretieren nennt man das nicht.
Wenn man so will, dann könnte man sagen, dass der Interpreter beliebige Strings auswertet und das deswegen ein interpretieren ist.
Bei Bytecode hat man dagegen nur eine 4 Byte breite Wortlänge und keine beliebig langen Bytefolgen für einen Befehl mehr.Die Bezeichnungen passen nur wenn man sich Implementierungen anguckt, keine Sprachen.
Heute kann man das so sagen, ja.
