Weiß jemand, warum Scala in Java und .NET anstelle von C oder C ++ implementiert wurde? Die meisten Sprachen werden mit Cor C ++ implementiert [dh Erlang, Python, PHP, Ruby, Perl]. Welche Vorteile bietet Scala, das in Java und .NET implementiert ist, außer den Zugriff auf Java- und .NET-Bibliotheken?

AKTUALISIEREN

Wäre Scala nicht vorteilhafter, wenn es in C implementiert wäre, weil es besser abgestimmt werden kann, als sich auf JVM zu verlassen?

Die Frage ist verwirrend, da C und C ++ Sprachen sind , während JVM eine virtuelle Maschine ist und .Net eine Plattform ist . Scala könnte in C oder C ++ implementiert sein und für eine virtuelle Maschine Maschinencode anstelle von Bytecode generieren.

Beantwortung der gestellten Frage:

Scala wurde nicht in C oder C ++ implementiert, da Scala, die Sprache, in der es tatsächlich implementiert ist, eine viel bessere Sprache ist.

Warum ist es besser? Nun, lesen Sie etwas über Oderskys Ziele für die Scala-Sprache .

Beantwortung der möglicherweise beabsichtigten Frage:

Scala generiert hauptsächlich JVM-Bytecode, da dies eine hervorragende Portabilität sowie Funktionen wie einen zuverlässigen und effizienten Garbage Collector, Laufzeitoptimierungen und eine Just-in-Time-Kompilierung bietet durch die JVM .

Lassen Sie mich das letzte wiederholen: JVM wird kompiliert , um Code-Hotspots in dem Code zu verarbeiten, den es ausführt. Das ist kompilieren, genau wie es C- und C ++ - Compiler tun.

Es gibt andere virtuelle Maschinen, aber Odersky, der Erfinder von Scala, war mit JVM bereits sehr vertraut. Er wollte CLR als Alternative haben, aber die Bemühungen, dies in Gang zu bringen, haben noch keinen Erfolg gebracht.

Beantwortung der Frage, die hätte gestellt werden können / sollen:

Das Kompilieren in Maschinencode bietet nicht genügend Vorteile gegenüber dem Kompilieren in JVM-Bytecode.

Es ist sicherlich möglich, Mikrobenchmarks in C oder C ++ zu generieren, die JVM-Äquivalente übertreffen. Es ist auch wahr, dass extrem optimierter Code in C oder C ++ extrem optimierten Code in Java oder Scala schlagen wird. Der Unterschied ist jedoch nicht allzu groß für ein lang laufendes Programm.

Beachten Sie, dass Scala gerade deshalb keine besonders gute Skriptsprache ist, weil der Aufwand für kurzfristige Programme zu groß ist.

In den meisten Fällen sind jedoch die Entwicklungsgeschwindigkeit und die Wartungsfreundlichkeit wichtiger als die Ausführungsgeschwindigkeit . In den Fällen, in denen die Leute mehr daran interessiert sind, einfach zu verstehenden und zu ändernden Code auf höchster Ebene zu schreiben, können die von der JVM bereitgestellten Laufzeitoptimierungen die von C- oder C ++ - Compilern vorgenommenen Kompilierzeitoptimierungen leicht übertreffen, was zu JVM (und CLR führt ) das Ziel, das tatsächlich schneller ausgeführt wird.

Unabhängig davon, ob es sich bei Scala Compiler um eine ausführbare Maschinencode-Datei oder bei Scala- Programmen um Maschinencode handelte, werden die potenziellen Geschwindigkeitsgewinne nicht unbedingt in echte Geschwindigkeitsgewinne umgesetzt.

Und nebenbei,

Ich gebe Ihnen ein Gegenbeispiel: Haskell. Haskell generiert Maschinencode, und dennoch schneiden Haskell-Programme bei Debians Schießerei schlechter ab als bei Scala. Kann jemand sicher sein, dass Scala-Programme schneller wären, wenn sie direkt in Maschinencode kompiliert würden?

Eine der großen Hürden für Sprachen bei der Einführung in die Welt ist die Verfügbarkeit von Bibliotheken. Die traditionelle Antwort darauf bestand darin, eine C-basierte FFI (Foreign Function Interface) bereitzustellen, mit der Sie auf C-basierte Bibliotheken zugreifen können. Dies ist aus verschiedenen Gründen nicht ideal, vor allem aus folgenden Gründen:

• Bibliotheken möchten auf viele verschiedene Arten interagieren, die mit vielen übergeordneten Sprachen nicht kompatibel sind. Zum Beispiel, wenn die Bibliothek einen Zeiger auf a haben möchte struct, wie gehen die Sprachen ohne Zeiger UND ohne structzurecht?
• Es gibt harte Wechselwirkungen zwischen Speichermodellen verschiedener Bibliotheken und Sprachen, die oft nicht auflösbar oder, falls sie auflösbar sind, sehr fehler- und fehleranfällig sind.
• Der Klebercode für viele FFIs ist nicht trivial und setzt Wissen voraus, das möglicherweise nicht universell ist. (Ob Sie es glauben oder nicht, nicht alle Programmierer sind C-Gurus, und sie wollen es auch nicht und sollten es auch nicht müssen!)

Dies wird mit C ++ noch schlimmer. C ++ ist nicht einmal mit C ++ kompatibel (auf einer binären Ebene, meine ich) von Compiler zu Compiler auf derselben Plattform (!), Ganz zu schweigen von anderen Sprachen.

Durch die Ausrichtung auf die JVM werden viele dieser Probleme gelöst, und Sie erhalten Zugriff auf die absolut enorme Suite von Java-basierten Bibliotheken. (Wie riesig? Sehen Sie sich die riesige Auswahl der Apache Software Foundation für den Anfang an.)

• Javas Calling- und Ownership-Konventionen sind regelmäßiger als die von C.
• Die JVM bietet auch ein einziges Speichermodell (einschließlich Garbage Collection) für Sprachen und Bibliotheken, mit denen beide zusammenarbeiten können. Es ist nicht nötig zu verfolgen, wem was gehört und wer wo aufräumen muss. Die Laufzeit erledigt das für Sie.
• Der Glue-Code für FFI ist für die meisten auf der JVM basierenden Sprachen nicht vorhanden (da er als Framework hinter den Kulissen der Sprache bereitgestellt wird). Es ist nicht erforderlich, Java zu programmieren, um beispielsweise auf Java-Bibliotheken in Scala, Clojure, JRuby usw. zuzugreifen. Sie greifen auf die Java-Objekte auf die gleiche Weise zu wie auf native "Objekte" (erschrecken Sie Anführungszeichen, weil beispielsweise Clojure dies nicht tut haben aktuelle Objekte im OOP-Sinne) und in Ihrer Muttersprache.

Zusätzlich zu diesen Vorteilen haben Sie die zusätzlichen Vorteile, dass Sie Java überall dort ausführen können, wo es ohne Neukompilierung ausgeführt wird (aber mit Testen !: einmal schreiben, überall testen) und auf die beeindruckende Java-JIT-Technologie zugreifen können.

Die CLR bietet ähnliche Stärken, fügt aber hinzu, was IMO als Schwäche bezeichnet: Es ist so ziemlich eine Vendor Lock-In-Umgebung. (Ja, ich weiß über Mono Bescheid. Ich denke immer noch, dass es sich um eine vendor lock-in-Umgebung handelt.)

Nach diesem Interview war der Zugriff auf die vorhandene Java-Infrastruktur und -Bibliotheken der Hauptgrund.

... Java ist eine existierende Sprache mit sehr harten Einschränkungen. Infolgedessen konnte ich nicht viele Dinge so machen, wie ich es gewollt hätte - die Art und Weise, wie ich überzeugt war, wäre die richtige Art, sie zu machen. Nach dieser Zeit, als der Schwerpunkt meiner Arbeit im Wesentlichen auf der Verbesserung von Java lag, entschied ich, dass es Zeit war, einen Schritt zurück zu machen. Ich wollte mit einem leeren Blatt anfangen und sehen, ob ich etwas entwerfen könnte, das besser ist als Java. Gleichzeitig wusste ich, dass ich nicht von vorne anfangen konnte. Ich musste eine Verbindung zu einer vorhandenen Infrastruktur herstellen, da es sonst einfach unpraktisch ist, sich ohne Bibliotheken, Tools und ähnliches aus dem Nichts zu stürzen.

Deshalb habe ich beschlossen, dass eine andere Sprache als Java immer mit der Java-Infrastruktur verbunden ist - mit der JVM und ihren Bibliotheken . Das war die Idee ...

Alle anderen Sprachen, die Sie erwähnen, Erlang, Python, PHP, Ruby, Perl - diese wurden alle vor Java und .NET erstellt. Wenn den Erstellern dieser Sprachen zu diesem Zeitpunkt die Java- oder .NET-Laufzeitumgebung zur Verfügung stand, ist es möglich, dass sie diese beim Erstellen ihrer Sprache genutzt haben.

Natürlich kann ich nicht für die Entwickler dieser Sprachen sprechen, daher kann ich nicht sicher sagen , dass sie .NET und / oder Java verwendet hätten, wenn sie verfügbar gewesen wären, aber es scheint mir wie ein gute Idee. Wenn Sie Ihre Sprache so gestalten, dass sie mit Java / .NET-Bytecode kompiliert wird, erhalten Sie alle Vorteile der JIT-Compiler / -Optimierer. Ihre Sprache wird automatisch auf allen Plattformen ausgeführt, auf denen Java / .NET ausgeführt wird. Sie haben Zugriff auf alle die Java / .NET-Bibliotheken und so weiter.

C-Code wird statisch zu nativem Code (Maschinencode) kompiliert.

Scala wird statisch zu Java-Bytecode kompiliert und dann nach Bedarf dynamisch zu optimiertem nativem Code kompiliert. Der Prozess:

Scala-Code --- statisch-kompiliert-nach ---> JVM-Byte-Code --- dynamisch-kompiliert-nach-JVM-Hotspot-nach ---> nativer Code

Allgemeine Optionen zum Erstellen / Ausführen einer beliebigen Sprache:

• a) Interpretieren Sie den Quellcode direkt über eine Laufzeit-Interpreter-Engine
• b) Code statisch zu nativem Code kompilieren (möglicherweise über Zwischenstufen, z. B. Quelle -> C -> nativ)
• c) Kompilieren Sie den Quellcode statisch in einen Zwischencode niedrigerer Ebene und interpretieren Sie ihn zur Laufzeit
• d) Kompilieren Sie den Quellcode statisch in einen Zwischencode niedrigerer Ebene, und verwenden Sie dann die ursprüngliche Interpretation, gefolgt von dynamischen Kompilierungs- und Optimierungstechniken zur Konvertierung in systemeigenen Code. Der Code wird interpretiert, bis typische Ausführungspfade und Engpässe gefunden wurden. Anschließend wird der Code kompiliert, um unter typischen Bedingungen die schnellste Ausführung zu erzielen. Es wird neu kompiliert / angepasst, wenn sich die Ausführungsbedingungen genug ändern, um dies zu gewährleisten

Ihre Frage: "Warum verwendet Java (d) mit einer JVM und nicht (b) mit C-Zwischencode?"

Antworten:

Erstens, beobachten Sie, dass Scala eine Menge istEine höhere Programmiersprache als C, die Programmierleistung, einfache Programmierung und Prägnanz bietet. Es ist etwa eine Ebene höher als Java, da es erstklassige und höherwertige Funktionen, implizite Funktionen, Funktionen als Objekte, Closures und Currying, Unterstützung für die Schwanzrekursionskompilierung zu schnellen stapelerhaltenden Schleifen, alles als Objekte und alle Operatoren als Methoden bietet Dies kann in Bibliotheken, Fallklassen und Reduktionen (Pattern Matching), impliziten Typableitungen, stärkerem Polymorphismus durch erweiterte mehrfach vererbbare Merkmale und erweiterte Generika, integrierter Syntax für Paare und Tupel und Nachteile (Listen und Bäume) (neu) definiert werden ) & maps, Unterstützung für unveränderliche Datenstrukturen, Unterstützung für leistungsfähiges 'reaktives' paralleles und gleichzeitiges Rechnen mit Nachrichtenkopieren und Weitergeben zwischen Akteuren, Erweiterte Unterstützung für beliebige domänenspezifische DSLs, Skriptfähigkeit und die REPL. Aufgrund der Objektorientierung, der Zeigerverwaltung und der Speicherbereinigung, der Zeichenfolgenunterstützung, der Multithreading-Unterstützung und der Parallelitätskontrolle sowie der Standard-API-Bibliotheken ist Java etwa 1 Stufe höher als C.

1. Leistung: Für eine Hochsprache bietet (d) eine schnellere Leistung als (a) - (c).
   Direkt geschriebener und handoptimierter C-Code ist schnell. In C statisch kompilierte übergeordnete Sprachen sind jedoch relativ langsam. Die Java-Designer wussten das gut. Ihr aktuelles "Hotspot" -Design steigert die Leistung um eine Größenordnung. Auf einem einzelnen Kern ist Java HotSpot-Code im Durchschnitt 50% so schnell wie von Menschen optimiertes C (im besten Fall 120% so schnell, im schlimmsten Fall 30% so schnell). Aber das ist natürlich ein Vergleich zwischen Äpfeln und Orangen - Low-Level-Code und High-Level-Code. Und das wäre vielSchlimmer, wenn die Hotspot-Optimierung nicht verwendet wurde. Deaktivieren Sie zur Bestätigung einfach die Hotspot-Kompilierung über JVM-Argumente! Oder erwägen Sie die Leistung von Java 1 & 2, wenn der Hotspot nicht existierte oder noch nicht ausgereift war. Oder versuchen Sie eine andere Sprache über C zu kompilieren - zB perlcc. Dies sind großartige Ergebnisse für eine leistungsfähige und produktive Sprache. Mit der weiteren Entwicklung ist es möglich (oder sogar wahrscheinlich), dass JVM das handcodierte C im Durchschnitt bald übertreffen wird. Scala ist im Durchschnitt nur 70-80% so langsam wie Java. Aber Scala skaliert stark über mehrere Kerne (mit weiteren Verbesserungen, die noch andauern), wohingegen Java teilweise und C nicht. Die Single Core-Leistung für solche Hochsprachen wird wie folgt bewertet:

   interpretiert <statisch kompiliert <dynamisch kompiliert

   Multi-Core-Leistung / Skalierbarkeit wird bewertet:

   interpretierter dynamischer Code <statisch kompilierter imperativer Code <statisch kompilierter funktionaler / deklarativer Code <dynamisch kompilierter funktionaler / deklarativer Code

   Dies bringt die Scala auf den ersten Platz, da die Prozessorgeschwindigkeit an ihre Grenzen stößt und die Anzahl der Kerne nun nach Moores Gesetz zunimmt. Scala ist auf Multi-Cores sehr schnell und könnte in Zukunft um ein Vielfaches schneller als C oder Java werden. Das statische Kompilieren nach C ist eindeutig nicht die schnellste Option.

2. Interoperabilität: Sprachen auf einer weitgehend unterstützten virtuellen Maschine weisen eine bessere Sprachinteroperabilität auf als isolierte Sprachen. Scala "spielt" automatisch mit Java-Klassen, Interfaces und Objekten, indem sie sie einfach importiert und verwendet, als wären sie Scala-Klassen, Merkmale und Objekte. Ähnliches ist mit anderen JVM-Sprachen wie Groovy, Clojure, JRuby und JPython möglich - wobei die Interoperabilität davon abhängt, wie sauber jede Sprache für die Kompilierung zu verständlichen und verwendbaren Java-Laufzeitklassen / -Interfaces / -Objekten erstellt wurde. So viel ist kostenlos (wie in "in der Nähe von"). Scala arbeitet über JNA, dem Nachfolger von JNI, mit C zusammen - was mit einigem Aufwand verbunden ist, aber die Tools wurden im Laufe der Zeit recht gut optimiert. JNA kann tatsächlich mit kompiliertem nativem Code aus jeder beliebigen Sprache zusammenarbeiten. Sie müssen jedoch die genaue Struktur kompilierter Datentypen und Funktionen kennen. Wenn nicht,

3. Portabilität: JVM läuft auf Dutzenden Betriebssystemplattformen / -versionen "out of the box". Scala wird automatisch auf diese portiert. Als Ausnahme gilt iOS (iPad / iPhone / iPod), das von Apple "kommerziell" und nicht "technisch" blockiert wird. Dies war 12 Jahre zuvor bei der ersten Entwicklung von JVM nicht zu erwarten. JVM läuft problemlos auf Dutzenden anderer Server, Desktops, Handys und eingebetteten Geräten, einschließlich solcher, die C nicht unterstützen - einschließlich Android mit Google-angepasster Dalvik-VM (50% + der neu verkauften Telefone). Sicher, C-Code funktioniert auf einer Vielzahl von Plattformen, daher kann er mit Java oder möglicherweise darüber hinaus bewertet werden (insbesondere ist C eine Teilmenge von Objective-C). Aber C würde auf Kosten von (1), (2) und (3) kommen. Natürlich kann die Präsentationsebene HTML5 / Javascript / Webkit (oder Objective-C) unter iOS mit einer Remote-Scala-App zusammenarbeiten. Entwickler sollten dies also unbedingt tun. Natürlich werden sie weniger produktiv sein.

4. Tools und Bibliotheken : Offensichtlich gibt es Tausende von kommerziellen und Open-Source-Java-Bibliotheken und -Tools, die von Scala genutzt werden können - mehr als bei C.

5. Sicherheit: - Die Ausführung auf einem kontrollierten App-Server oder einer JVM-Umgebung bietet eine stärkere Unterstützung für Sicherheitsrichtlinien und -einschränkungen, die in einer Unternehmensumgebung von großem Wert sein können.

JVM / CLR

Die JVM (und die CLR) bieten einzigartige Vorteile in Bezug auf Optimierung und Code-Portabilität.

Soweit ich weiß, wird nur die JVM-Version von Scala auf dem neuesten Stand gehalten, die .NET-Version nicht.

Es sieht so aus, als mischen Sie zwei Dinge, die nichts miteinander zu tun haben.

Die erste ist, welche Programmiersprache wird von Scala-Autoren verwendet, um Scala zu implementieren?

Worauf die Antwort lautet: Scala selbst. Und das ist die einzig akzeptable Antwort, denn wenn Sie diese neue Sprache erfunden haben, sie aber nicht selbst für die Implementierung verwenden - wofür ist sie gut?

Zweitens: Auf welcher Zielplattform können in Scala geschriebene Programme ausgeführt werden?

Hier wird die Auswahl interessanter, aber das einzige Ziel, das zu 100% funktioniert, ist JVM. Die Unterstützung für .NET ist noch in Arbeit. Außerdem arbeiten einige Leute daran, Scala dazu zu bringen, dass es sich zu Javacsript kompiliert. Theoretisch hindert nichts jemanden daran, weitere 'Backends' zum Kompilieren in C, C ++, LLVM, nativem Code oder was auch immer hinzuzufügen.

Warum wurde JVM als primäre Plattform ausgewählt? Ich vermute, weil

• Jeder will Müllabfuhr
• Viele gute Bibliotheken sind einsatzbereit
• Eine große Anzahl von Programmierern langweilt sich mit Java und ist bereit, zu etwas Neuem zu springen, ohne dabei die Grenzen von JVM zu überschreiten (niemand möchte seinen vorhandenen Code auf eine andere Plattform migrieren).

Zuallererst - was Sie wohl wirklich fragen wollten, ist, warum Scala nicht streng kompiliert wird. Ich werde dir sagen, dass ich es nicht weiß. Aber ich werde Ihnen auch sagen, dass es keinen Grund gibt, JVM gegenüber nativem Code vorzuziehen.

Warum? Der Grund ist einfach: Jede Virtualisierungstechnologie ist speicherhungrig, verursacht unnötigen Overhead und eine weitere Indirektionsebene. Dies ist keine Frage der Implementierung - dies ist eine Frage der Logik, die hinter dem Kernkonzept der Virtualisierung steckt. Egal, was Sie tun, Sie werden IMMER mit minderwertigen Eigenschaften enden. Besonders JVM ist speicherhungrig. Es ist nicht mehr so ​​langsam, weil es einen eigenen Laufzeit-Compiler hat, der hinter dem Hintergrund läuft, aber dennoch - es muss den Compiler-Prozess ausführen, um die am stärksten überlasteten Teile des Codes zu erkennen und sie in Binärcode umzuwandeln.

Gesagt - der einzige Grund, warum ich Scala JVM-basiert gemacht habe, war wahrscheinlich die Popularität der Sprache. Ich vermute auch, dass diese Entscheidung etwas träge war, da es einfacher ist, eine Sprache über die JVM zu implementieren, als herauszufinden, wie die Dinge plattformübergreifend zusammengestellt aussehen sollten - und selbst die Verwendung vorhandener C-Backends erfordert viel mehr Arbeit dass die Dinge nicht so gut standardisiert sind wie bei JVM.

Das ist der Grund, an den ich denken kann, aber denken Sie daran, dass es auch andere Gründe geben kann - wie Lizenzvergabe und damit verbundene Politik (die schmutzige Dinge sind, auf die ich nie Lust habe).

Es ist nicht klar, dass es ein guter Kompromiss wäre, die Fähigkeit zur besseren Abstimmung zu haben. JVMs können zur Laufzeit optimiert werden. Dies ist in der Regel mindestens ausreichend, wenn nicht sogar besser als bei der statischen Kompilierung. (Grundsätzlich sollte es für eine bestimmte Anwendung und Auslastung möglich sein, JIT mit statischen Optimierungen zu übertreffen, aber praktisch haben Sie nicht oft die genaue Auslastung oder sogar die gesamte Anwendung.)