Warum wurde Scala nicht mit C oder C ++ implementiert?

28

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?

Joshua Partogi
quelle
18
Die Möglichkeit, vorhandene Java-Bibliotheken zu verwenden und eng mit Java-Code zusammenzuarbeiten, ist ein RIESIGER Vorteil und keine Kleinigkeit.
Tamás Szelei
6
@OP: Sie sprechen so, als ob es schlecht wäre, eine Sprache über der JVM (oder CLR) zu implementieren. Die Abstimmung, die Sie in C erwähnen, ist bei weitem nicht annähernd so umfangreich wie die Abstimmung in CLR oder JVM. Und wenn sich die Plattform verbessert, erhält Ihre Sprache diese automatisch kostenlos. Wenn man die Wahl hat, sollte niemand mehr seine Sprache auf good'ol C implementieren.
Chii
8
@ Chii, nur zugeben, Java ist immer noch langsamer als C.
Joshua Partogi
19
@jpartogi, Java kann nicht langsamer oder schneller als C sein. Sie sind beide Sprachen, keine Hengste. Unter bestimmten Bedingungen ist ein bestimmter Code, der vom Java-Compiler kompiliert und mit einer bestimmten JVM ausgeführt wird, langsamer als ein ungefähr vergleichbarer Code, der von einem C-Compiler generiert wird. In einigen anderen Fällen ist letzteres langsamer.
SK-logic
4
Die Laufzeitumgebung von Scala ist ein C ++ - Programm. die JVM.
mike30

Antworten:

59

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?

Daniel C. Sobral
quelle
3
@ mike30 Scala würde auf jeder JVM ausgeführt, auch wenn sie nicht in C ++ geschrieben wäre, sodass dieses Argument nicht zutrifft. Und zur Laufzeit gibt es keinen C ++ - Code, sondern nur Maschinencode. Ich bin mir jedoch nicht sicher, worum es in diesem Kommentar geht.
Daniel C. Sobral
3
Der eigentliche Punkt ist: Das Generieren von Maschinencode ist wesentlich komplexer als das Generieren von Byte-Code und erfordert eine spezifische Implementierung für alle Betriebssysteme sowie das Optimieren von CPUs und verschiedenen Architekturen (ARM, x86, x86_64) und erweiterten Anweisungen (MMX, SSE) ...). Auf diese Weise wird dieser Aspekt an die JVM delegiert.
Raffaello
2
Wenn Sie so viel über die Ausführungsleistung sprechen, warum sprechen Sie nicht über die Speicherleistung? Haben Sie Angst, dass die Dinge nicht so gut werden, wie Sie es sich vorstellen?
Luke1985
3
@ lukasz1985 Es treibt die Leistung an, aber die Leistungsdiskussion deckt dies ab, daher ist es in dieser Hinsicht irrelevant. Alles was bleibt ist, ob es Sie interessiert, wie viel Speicher eine Anwendung benötigt, und dann müssen Sie zwischen GC und dem wählen, und ich werde jedes Mal GC auswählen, mit Ausnahme von sehr spezifischen Entwicklungsbereichen, von denen keiner von Scala belegt wird. Und "ist nicht jedermanns Recht zu erzählen" ist Bullshit - jeder hat das Recht. Und obwohl C / C ++ aufgrund des Erbes sehr relevant ist, würden sie niemals populär werden, wenn sie in den letzten fünf Jahren veröffentlicht worden wären.
Daniel C. Sobral
3
@ lukasz1985 Dein einziger Beweis, dass ich das nicht verstehe, ist, dass ich mit dir nicht einverstanden bin. Eine alternative Erklärung dafür ist, dass Sie falsch liegen. Und als jemand, der "damals" lebt und programmiert, habe ich eine Perspektive aus erster Hand auf die Entscheidungsfindung bei der Auswahl von C und C ++ gegenüber zeitgemäßen Alternativen, die ich erwähne, um meinen Standpunkt nicht zu beweisen, sondern als Gegenpol zu Ihrem zu bieten: Ähnlichkeit die gesprochene Sprache war in keiner Weise relevant, während die Ähnlichkeit mit Maschinencode war.
Daniel C. Sobral
31

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.)

Nur meine richtige Meinung
quelle
3
Sie erkennen, dass C # und die CLR tatsächlich ein offener Standard sind, den jeder verwenden kann.
Erin
7
Ich denke, das bisschen darüber, wo ich "über Mono Bescheid weiß" und dann "immer noch denke, dass es sich um eine Vendor Lock-In-Umgebung handelt", sollte dir einen kleinen Hinweis geben, Erin.
NUR MEINE STELLUNGNAHME
3
@Erin nicht alles von .NET Framework ist aber
Alternative
1
@alternative: Wenn das zu viel Lockin ist, denken Sie daran, dass die Java-Konformitätstests immer noch nicht kostenlos sind und es für Java bestenfalls 6 von einem, ein halbes Dutzend von dem anderen sind.
Deduplikator
18

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 ...

Jeremiah
quelle
10

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.

Dean Harding
quelle
2
Die beschriebenen Vorteile sind einige der Gründe, warum z. B. Python sowohl für JVM (Jython) als auch für .NET (IronPython) neu implementiert wurde.
Dancek
2
-1: Unter der Annahme, dass neue Sprachen von einer bestimmten Plattform (.Net oder JVM) abhängen könnten, weil sie verfügbar wären, scheint mir kein gutes Argument zu sein. Zum Beispiel sehe ich keinen guten Grund für Python oder Erlang, auf einer solchen Plattform zu laufen. Hystory sag nicht alles.
Klaim am
1
Und selbst PHP wäre niemals in der Lage, das zu tun, was es über die JVM oder .Net macht. @Dean Harding> Ich glaube nicht, dass IronPython oder Jython irgendetwas Wertvolles bewiesen haben.
Klaim am
1
Tut mir leid, mir war nicht klar, was ich damit meinte, dass es keinen Erfolg gehabt hätte (PHP oder Python), weil das Arbeiten über eine JVM oder .Net eine Menge Dinge impliziert, die viele Entwickler gestört hätten sie mehr Nischensprache als sie derzeit sind. Auf der technischen Seite wäre die Plattform (.Net oder JVM) ein Problem gewesen, da sie die Art und Weise beeinflusst, wie Sie eine Sprache darüber erstellen. Wenn Sie mit der Maschine angeben, können Sie genau die Sprache erstellen, die Sie möchten. Also mit oder ohne JVM, ich sehe 0 gute Gründe, um über .Net und JVM aufzubauen. Abgesehen von einer schnellen Implementierung.
Klaim am
2
Kleine Korrektur: Java ist älter als PHP. Aber PHP begann als CGI-Programm, wurde später ein Apache-httpd-Modul und als solches wurde es groß. Beide Dinge (CGI- und httpd-Modul) funktionieren für Java nicht gut. Es ist also nicht so einfach, eine JVM ist nicht die Plattform für alles. ;-)
Johannes
6

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.

Glen Best
quelle
4

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.

Josh K
quelle
3

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).
artem
quelle
Ich verstehe nicht, warum ein Garbage Collector nicht mit C oder C ++ implementiert werden kann. Ich sehe das nicht als guten Grund. Python haben es geschafft. Ruby hat es geschafft. Heck sogar erlang haben es geschafft. Wer weiß, dass Scala möglicherweise einen besseren Garbage Collector hat, wenn es mit C oder C ++ geschrieben ist?
Joshua Partogi
1
Ich meinte "echte" Müllabfuhr. Ich glaube nicht , dass die Garbage Collection , dass provoziert Fragen wie diese gut genug ist. Selbst JVM ist nicht gut genug - andernfalls könnten Leute wie AzulSystems ihren Lebensunterhalt nicht damit verdienen, anderen Menschen zu helfen, JVM-Mängel zu überwinden.
Artem
Auch Bibliotheken. Es ist wirklich schwierig, Bibliotheken zu verwenden, die für die explizite Speicherverwaltung in einer Sprache mit Garbage Collection geschrieben wurden. Ein Indiz dafür ist das eigenartige Bestehen der Java-Leute, alles in „reinem Java“ zu haben.
Artem
0

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).

luke1985
quelle
-2

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.)

Bruce Stephens
quelle
Dies liest sich eher wie ein Kommentar, siehe Wie man antwortet
Mücke