Joachim Durchholz schrieb am 17. Mai 2011 20:22
> Jein.
> "Wesentlich" - eher nicht. Beide VMs sind von der Architektur her für
> manche Sprachen besser, für andere schlechter geeignet. Beide VMs
> haben sich auch in Richtung besserer Unterstützung für mehr Sprachen
> bewegt.
> "Große" Unterschiede gibt es immer noch. Sun hat für weniger Sprachen
> angefangen und sich auch danach eher zögerlich bewegt, .net war von
> vornherein für mehr Sprachen ausgelegt.
Mal abgesehen davon, wie gut das Typsystem von der Quellsprache auf
das Typsystem des Bytecodes (Java bzw. CLI) abgebildet werden können,
ist der Hauptunterschied zwischen mehr und weniger geeigneten
Quellsprachen, ob da alle Bereiche statisch kompiliert werden können
oder nicht.
Bei dynamischen Sprachen werden Typen erst zur Laufzeit ermittelt -
und auch z.B., welche Methoden aufgerufen werden. - Das war erst in
Java und .NET erst nicht nativ vorgesehen, wurde zwar durch
Introspection zur Laufzeit ermöglicht, war aber langsam.
Java SE 7, das in ein paar Monaten erscheinen soll, wird dafür
"invokedynamic" mitbringen, eine zusätzliche Klasse von Bytecode, die
dynamische Aufrufe nativ unterstützt. Dynamische Sprachen werden so
in vielen Fällen annähernd gleich schnell laufen wie statische
(inklusive dem Feature, vom JIT-Compiler erfaßt zu werden). - Ein
Äquivalent hatte .NET allerdings schon früher.
Und wie Du schon angedeutet hast: Bei .NET wird es nicht aktiv
genutzt. - Mir fiele Python für .NET ein, aber sonst eigentlich auch
lange nichts. - Bei Java wird Groovy stark profitieren (und JPython
und JRuby).
Scala kompiliert ja sowie vollständig statisch (und nach meinen
bisherigen Erfahrungen aus dem Ansehen des dekompilierten
Java-Bytecodes auch ohne viele Extra-Schlenker).
- Insgesamt denke ich, daß sich - Javas "invokedynamic" vorausgesetzt
- .NET und Java in der Umsetzung der Sprachunterstützung
grundsätzlich überhaupt nicht unterscheiden. -
Dagegen die aktiven Sprachen betrachtet: Bei .NET gibt's C#, später
VB.NET, und dann lange gar nichts. Bei Java gibt's Java, später
Groovy und Scala, und dann nach langer Zeit noch JPython, JRuby,
Clojure und BeanShell (der "Zoo" ist größer).
> Jein.
> "Wesentlich" - eher nicht. Beide VMs sind von der Architektur her für
> manche Sprachen besser, für andere schlechter geeignet. Beide VMs
> haben sich auch in Richtung besserer Unterstützung für mehr Sprachen
> bewegt.
> "Große" Unterschiede gibt es immer noch. Sun hat für weniger Sprachen
> angefangen und sich auch danach eher zögerlich bewegt, .net war von
> vornherein für mehr Sprachen ausgelegt.
Mal abgesehen davon, wie gut das Typsystem von der Quellsprache auf
das Typsystem des Bytecodes (Java bzw. CLI) abgebildet werden können,
ist der Hauptunterschied zwischen mehr und weniger geeigneten
Quellsprachen, ob da alle Bereiche statisch kompiliert werden können
oder nicht.
Bei dynamischen Sprachen werden Typen erst zur Laufzeit ermittelt -
und auch z.B., welche Methoden aufgerufen werden. - Das war erst in
Java und .NET erst nicht nativ vorgesehen, wurde zwar durch
Introspection zur Laufzeit ermöglicht, war aber langsam.
Java SE 7, das in ein paar Monaten erscheinen soll, wird dafür
"invokedynamic" mitbringen, eine zusätzliche Klasse von Bytecode, die
dynamische Aufrufe nativ unterstützt. Dynamische Sprachen werden so
in vielen Fällen annähernd gleich schnell laufen wie statische
(inklusive dem Feature, vom JIT-Compiler erfaßt zu werden). - Ein
Äquivalent hatte .NET allerdings schon früher.
Und wie Du schon angedeutet hast: Bei .NET wird es nicht aktiv
genutzt. - Mir fiele Python für .NET ein, aber sonst eigentlich auch
lange nichts. - Bei Java wird Groovy stark profitieren (und JPython
und JRuby).
Scala kompiliert ja sowie vollständig statisch (und nach meinen
bisherigen Erfahrungen aus dem Ansehen des dekompilierten
Java-Bytecodes auch ohne viele Extra-Schlenker).
- Insgesamt denke ich, daß sich - Javas "invokedynamic" vorausgesetzt
- .NET und Java in der Umsetzung der Sprachunterstützung
grundsätzlich überhaupt nicht unterscheiden. -
Dagegen die aktiven Sprachen betrachtet: Bei .NET gibt's C#, später
VB.NET, und dann lange gar nichts. Bei Java gibt's Java, später
Groovy und Scala, und dann nach langer Zeit noch JPython, JRuby,
Clojure und BeanShell (der "Zoo" ist größer).