C# oder Java
-
(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.
-
Achje das ist jetzt ne Begriffsdefinitionsfrage.
MMn. ist es voll OK zu sagen Bytecode wird interpretiert. Man kann argumentieren dass beim Bytecode das Parsen wegfällt und statt eines "Interpretieren" eines Textes einfach nur einfache, klar kodierte Instruktionen ausgeführt werden. Ich weiss aber nicht ob diese Unterscheidung sinnvoll ist.
Ich kenne auch jeden Fall genug Leute die z.T. sehr viel mit Java zu tun haben und z.T. auch sehr "VM-nahe" (Instrumentierung von Bytecode etc.), und viele von denen sagen auch "interpretieren" bzw. "Interpreter" wenn sie klar hervorheben wollen dass es um Code geht der ohne JIT "ausgeführt" wird - "interpretiert" eben.
-
Ich würde sagen es ist eigentlich ganz einfach. Interpretieren ist, wenn das Programm (in welcher Form auch immer es vorliegen mag) von einem anderen Stück Software gelesen und direkt umgesetzt wird. Bytecode oder nicht spielt da keine Rolle. Bytecode kann interpretiert werden, wenn er aber z.B. erst durch einen JIT Compiler geschickt wird und dann direkt auf der Maschine ausgeführt wird, dann ist das kein Interpretieren mehr. Beides ist möglich, beides kommt vor und Hybride gibt's auch...
-
Ich habe ne bessere Definition:
Interpretieren ist, wenn der auszuführende Code noch in seiner Programmiersprachenform vorliegt.
Bei Bytecode ist das nicht mehr der Fall, der ist schon compiliert, auch ohne JIT Compiler. Nämlich compiliert für die VM.
Der JIT Compiler macht ja dann nur noch nativen Maschinencode aus dem "Maschinencode" der VM. Javacode ist das zu dem Zeitpunkt schon längst nicht mehr.
-
Deiner Definition nach is CPython also kein Interpreter? Denn CPython übersetzt den Input in Bytecode welcher dann aber nicht durch einen JIT geht sondern von einer Softwareimplementierung einer VM ausgeführt wird... Was ist BOCHS? Was ist DosBox?
-
dot schrieb:
von einer Softwareimplementierung [...] ausgeführt wird...
und das nennt man dann interpreter.
-
computertrolls schrieb:
Ich habe ne bessere Definition:
Interpretieren ist, wenn der auszuführende Code noch in seiner Programmiersprachenform vorliegt.
Wieso meinst du dass die Definition besser ist? Sie zieht eine schwammige unscharfe Grenze mit höchst fraglichem Nutzen. Was soll daran besser sein?
-
Wade1234 schrieb:
dot schrieb:
von einer Softwareimplementierung [...] ausgeführt wird...
und das nennt man dann interpreter.
eben...
-
Java ist Müll. Die Syntax, die IDE, einfach Minderwertig. Nimm C#, da bist du auf der sicheren Seite. Alternativ noch Kenntnisse in C++ und Python aneignen und passt.
