Qualcuno sa perché Scala è stata implementata in Java e .NET anziché in C o C ++? La maggior parte delle lingue sono implementate con Cor C ++ [ovvero Erlang, Python, PHP, Ruby, Perl]. Quali sono i vantaggi per Scala implementati in Java e .NET oltre a consentire l'accesso alle librerie Java e .NET?

AGGIORNARE

Scala non otterrebbe maggiori benefici se fosse implementato in C perché può essere sintonizzato meglio piuttosto che fare affidamento su JVM?

La domanda è confusa, poiché C e C ++ sono linguaggi , mentre JVM è una macchina virtuale e .Net è una piattaforma . Scala potrebbe essere implementato in C o C ++ e potrebbe generare codice macchina anziché bytecode per una macchina virtuale.

Rispondere alla domanda che è stata posta:

Scala non è stato implementato in C o C ++ perché Scala, il linguaggio in cui è effettivamente implementato, è un linguaggio molto migliore.

Perché è meglio? Bene, leggi gli obiettivi di Odersky per il linguaggio Scala .

Rispondere alla domanda che potrebbe essere stata intesa:

Scala genera principalmente il bytecode JVM perché offre una grande portabilità e funzionalità come un garbage collector affidabile ed efficiente, ottimizzazioni di runtime e compilazione just-in-time da parte della JVM .

Consentitemi di ripetere l'ultima cosa: JVM si compila nei punti attivi del codice macchina nel codice in esecuzione. È compilato proprio come fanno i compilatori C e C ++.

Ci sono altre macchine virtuali disponibili, ma Odersky, il creatore di Scala, conosceva già JVM. Intendeva avere il CLR come alternativa, ma lo sforzo per farlo non ha ancora raggiunto il successo.

Rispondere alla domanda che avrebbe potuto / dovuto essere posto:

La compilazione in codice macchina non offre abbastanza vantaggi rispetto alla compilazione con bytecode JVM.

È certamente possibile generare microbenchmark in C o C ++ che superano gli equivalenti JVM. È anche vero che il codice estremamente ottimizzato in C o C ++ batterà il codice estremamente ottimizzato in Java o Scala. La differenza non è poi così eccezionale per un programma di lunga durata.

Nota che Scala non è un linguaggio di scripting particolarmente buono proprio perché l'overhead per i programmi a esecuzione breve è troppo grande.

Tuttavia, nella maggior parte dei casi la velocità di sviluppo e la facilità di manutenzione sono più importanti della velocità di esecuzione . In quei casi, in cui le persone sono più preoccupate di scrivere codice di livello molto alto che sia facilmente comprensibile e modificabile, le ottimizzazioni di runtime fornite dalla JVM possono facilmente battere le ottimizzazioni di compilazione effettuate dai compilatori C o C ++, rendendo JVM (e CLR ) l'obiettivo che verrà effettivamente eseguito più velocemente.

Quindi, indipendentemente dal fatto che la domanda riguardasse il fatto che il compilatore Scala fosse o meno un codice macchina eseguibile o che i programmi Scala fossero codice macchina, i potenziali guadagni di velocità non si traducono necessariamente in guadagni di velocità reali .

E comunque,

Ti darò un contro-esempio: Haskell. Haskell genera codice macchina e, tuttavia, i programmi Haskell vanno peggio sulla sparatoria di Debian rispetto a quella di Scala. Detto questo, qualcuno può essere sicuro che i programmi Scala sarebbero più veloci se compilati direttamente sul codice macchina?

Una delle maggiori difficoltà che le lingue affrontano quando viene introdotta nel mondo in generale è la disponibilità delle biblioteche. La risposta tradizionale a questa è stata quella di fornire un FFI (interfaccia con funzioni esterne) basato su C per consentire l'accesso alle librerie basate su C. Questo non è l'ideale per una serie di motivi, tra cui il principale:

• Ci sono molti modi diversi in cui le biblioteche vogliono interagire che non sono compatibili con molti linguaggi di livello superiore. Ad esempio, se la libreria desidera un puntatore a struct, come fanno le lingue senza puntatori E senza fare structfronte?
• Esistono dure interazioni tra modelli di memoria di librerie e linguaggi diversi che spesso non sono risolvibili o, se risolvibili, sono altamente inclini a errori e errori.
• Il codice della colla per molti SFI non è banale e presuppone una conoscenza che potrebbe non essere universale. (Che ci crediate o no, non tutti i programmatori sono guru C, e né vogliono essere né dovrebbero essere tenuti a esserlo!)

Questo peggiora ancora con C ++. Il C ++ non è nemmeno compatibile con il C ++ (a livello binario, intendo) dal compilatore al compilatore sulla stessa piattaforma (!), Per non parlare degli altri linguaggi.

Il targeting per JVM risolve molti di questi problemi offrendo al contempo l'accesso all'enorme suite di librerie basate su Java. (Che enorme? Basta esplorare la vasta selezione di Apache Software Foundation per i principianti.)

• Le convenzioni di chiamata e proprietà di Java sono più regolari di quelle di C.
• JVM fornisce anche un singolo modello di memoria (inclusa la garbage collection) per le lingue e le librerie con cui interfacciarsi. Non è necessario tenere traccia di chi possiede cosa e quale deve ripulire dove. Il runtime lo fa per te.
• Il codice colla per FFI, per la maggior parte dei linguaggi costruiti sulla JVM, è inesistente (come in esso è fornito come un quadro dietro le quinte nella lingua). Non è necessario programmare in Java, ad esempio, per accedere alle librerie Java in Scala, Clojure, JRuby, ecc. Si accede agli oggetti Java nello stesso modo in cui si accede agli "oggetti" nativi (virgolette perché, ad esempio, Clojure non lo fa avere oggetti reali nel senso OOP) e nella tua lingua madre.

Oltre a questi vantaggi, hai anche i vantaggi di eseguire ovunque Java venga eseguito senza ricompilazione (ma con i test !: scrivere una volta, testare ovunque) e avere accesso alla tecnologia JIT piuttosto impressionante di Java.

Il CLR offre punti di forza simili, ma aggiunge ciò che è un punto debole dell'IMO: è praticamente un ambiente di blocco del fornitore. (Sì, lo so di Mono. Penso ancora che sia un ambiente di blocco del fornitore.)

Secondo questa intervista , l'accesso all'infrastruttura e alle librerie Java esistenti era il motivo principale.

... Java è un linguaggio esistente con vincoli molto rigidi. Di conseguenza, non potevo fare molte cose nel modo in cui avrei voluto farle: il modo in cui ero convinto sarebbe stato il modo giusto di farle. Quindi dopo quel momento, quando essenzialmente il mio lavoro era focalizzato sul miglioramento di Java, ho deciso che era tempo di fare un passo indietro. Volevo iniziare con un foglio pulito e vedere se potevo progettare qualcosa di meglio di Java. Ma allo stesso tempo sapevo che non potevo ricominciare da zero. Ho dovuto connettermi a un'infrastruttura esistente, perché altrimenti non è pratico avviare il bootstrap dal nulla senza librerie, strumenti e cose del genere.

Così ho deciso che, anche se volevo progettare un linguaggio diverso da Java, si sarebbe sempre connesso all'infrastruttura Java, alla JVM e alle sue librerie . Questa era l'idea ...

Tutte le altre lingue che menzioni, Erlang, Python, PHP, Ruby, Perl - sono state tutte create prima di Java e .NET. Se i creatori di tali lingue avessero a loro disposizione l'ambiente di runtime Java o .NET, allora è possibile che abbiano sfruttato quelli durante la creazione della loro lingua.

Certo, non posso parlare per gli sviluppatori di quelle lingue, quindi non posso dire con certezza che avrebbero usato .NET e / o Java durante la loro costruzione se fossero stati disponibili, ma mi sembra un buona idea. Dopotutto, progettando la tua lingua per la compilazione in bytecode Java / .NET, ottieni tutti i vantaggi dei compilatori / ottimizzatori JIT, la tua lingua viene eseguita automaticamente su tutte le piattaforme su cui è in esecuzione Java / .NET, hai accesso a tutti i le librerie Java / .NET e così via.

Il codice C viene compilato staticamente in codice nativo (codice macchina).

Scala viene compilato staticamente in bytecode java e quindi, se necessario, compilato in modo dinamico in codice nativo ottimizzato. Il processo:

Codice scala --- compilato staticamente in ---> codice byte JVM --- compilato dinamicamente da JVM-Hotspot-in ---> codice nativo

Opzioni generali per creare / eseguire qualsiasi lingua:

• a) interpretare il codice sorgente direttamente tramite un motore di interprete di runtime
• b) compilare staticamente il codice in codice nativo (possibilmente tramite fasi intermedie, ad es. sorgente -> C -> nativo)
• c) compilare staticamente il codice sorgente in codice intermedio di livello inferiore e interpretarlo in fase di esecuzione
• d) compilare staticamente il codice sorgente in codice intermedio di livello inferiore, quindi utilizzare l'interpretazione iniziale, seguita da tecniche di compilazione dinamica e ottimizzazione per la conversione in codice nativo. Il codice viene interpretato fino a quando non vengono rilevati percorsi di esecuzione e colli di bottiglia tipici, quindi il codice viene compilato per l'esecuzione più rapida in condizioni tipiche. Viene ricompilato / risintonizzato quando le condizioni di esecuzione cambiano abbastanza da giustificarlo

La tua domanda: "Perché Java usa (d) con una JVM, piuttosto che (b) con il codice intermedio C?"

Risposta:

Innanzitutto, osserva che Scala è moltolinguaggio di livello superiore rispetto a C, che offre potenza di programmazione, facilità di programmazione e concisione. Si tratta di "1 livello superiore" rispetto a Java a causa di funzioni di prima classe e di ordine superiore, funzioni implicite, funzioni come oggetti, chiusure e curry, supporto per la compilazione ricorsiva della coda in loop veloci che conservano lo stack, tutto come oggetti, tutti gli operatori come metodi che può essere (ri) definito in librerie, classi di casi e riduzione (pattern matching), derivazione di tipo implicita, polimorfismo più forte attraverso tratti multi-ereditari espansi e generici espansi, sintassi integrata per coppie e tuple e contro (elenchi e alberi) ) e mappe, supporto per strutture di dati immutabili, supporto per elaborazioni parallele e simultanee "reattive" con copia e passaggio di messaggi tra attori, supporto avanzato per DSL arbitrari specifici del dominio, scriptabilità e REPL. Java è circa "1 livello superiore" rispetto a C a causa dell'orientamento agli oggetti, gestione dei puntatori e garbage collection, supporto delle stringhe, supporto multi-thread e controllo della concorrenza, oltre a librerie API standard.

1. Prestazioni: per un linguaggio di alto livello, (d) fornisce prestazioni più veloci di (a) - (c).
   Il codice C scritto direttamente e ottimizzato a mano è veloce. Tuttavia, le lingue di livello superiore compilate staticamente in C sono relativamente lente. I designer Java lo sapevano bene. Il loro attuale design "Hotspot" aumenta le prestazioni fino all'ordine di grandezza. Su un singolo core, il codice Java HotSpot è in media "50% più veloce" rispetto alla C ottimizzata per l'uomo (nel migliore dei casi è "120% più veloce", nel peggiore dei casi "30% più veloce"). Ma ovviamente questo sta confrontando le mele con le arance - codice di basso livello contro codice di alto livello. E sarebbe moltopeggio se non è stata utilizzata l'ottimizzazione dell'hotspot. Per confermare, basta disabilitare la compilazione di hotspot tramite args JVM! Oppure considera le prestazioni java 1 e 2, quando l'hotspot non esisteva o era immaturo. Oppure prova a compilare un'altra lingua tramite C, ad esempio perlcc. Quindi quanto sopra sono ottimi risultati per un linguaggio potente e produttivo. Con un ulteriore sviluppo, è possibile (o addirittura probabile) che JVM possa presto superare in media C codificato a mano. Scala è solo il 70-80% più lento di java in media. Ma scala scala fortemente su più core (con ulteriori miglioramenti in corso), mentre java lo fa parzialmente e C no. Le prestazioni Single Core per tali linguaggi di alto livello sono classificate:

   interpretato <compilato staticamente <compilato dinamicamente

   Le prestazioni / scalabilità multi-core sono classificate:

   codice dinamico interpretato <codice imperativo compilato staticamente <codice funzionale / dichiarativo compilato staticamente <codice funzionale / dichiarativo compilato dinamicamente

   Questo pone Scala al posto vincente perché la velocità del processore ha raggiunto il limite e ora il numero di core sta aumentando secondo la legge di Moore. Scala è molto veloce su multi-core e in futuro potrebbe diventare più volte più veloce di C o Java. Compilare staticamente in C non è chiaramente l'opzione più veloce.

2. Interoperabilità: le lingue su una VM ampiamente supportata hanno una migliore interoperabilità delle lingue rispetto alle lingue "isolate". Scala "gioca automaticamente con" classi, interfacce e oggetti java semplicemente importandoli e utilizzandoli come se fossero classi scala, tratti e oggetti. Simile è possibile con altri linguaggi JVM come Groovy, Clojure, JRuby e JPython - con facilità di interoperabilità dipendente da quanto ogni lingua è stata creata per compilare in classi / interfacce / oggetti comprensibili e utilizzabili di Java. Questo viene per "libero" (come in "vicino a"). Scala interagisce con C via JNA, il successore di JNI, che viene fornito con un certo sforzo, ma gli strumenti sono stati abbastanza ottimizzati nel tempo. JNA può effettivamente interagire con il codice nativo compilato da qualsiasi linguaggio arbitrario, ma è necessario conoscere la struttura esatta dei tipi di dati e delle funzioni compilati. Altrimenti,

3. Portabilità: JVM funziona su decine di piattaforme / versioni del sistema operativo "out of the box". Scala viene automaticamente portato su questi. Eccezione nota è iOS (iPad / iPhone / iPod) - bloccato "commercialmente", piuttosto che "tecnicamente" da Apple. Ciò non avrebbe potuto essere previsto 12 anni prima, durante la progettazione iniziale di JVM. JVM funziona perfettamente su dozzine di altri server, desktop, cellulari e dispositivi incorporati, compresi quelli che non supportano C - incluso Android con Dalvik VM adattato a Google (50% + di nuovi telefoni venduti). Certo, il codice C funziona su una moltitudine di piattaforme, quindi può essere valutato "lassù o probabilmente oltre" Java (in particolare, C è un sottoinsieme di Objective-C). Ma C verrebbe al costo di (1), (2) e (3). Ovviamente, il livello di presentazione HTML5 / javascript / webkit (o obiettivo-C) su iOS può interagire con un'app scala remota, quindi lo sviluppatore dovrebbe farlo. Certo, saranno meno produttivi.

4. Strumenti e librerie : Ovviamente ci sono migliaia di librerie e strumenti Java commerciali e open source che possono sfruttare / essere sfruttati da Scala - più che per C.

5. Sicurezza: - l'esecuzione su un server di app controllato o un ambiente JVM offre un supporto più forte per le politiche e le restrizioni di sicurezza, che possono essere estremamente utili in un ambiente aziendale.

JVM / CLR

JVM (e CLR) offrono vantaggi unici in termini di ottimizzazione e portabilità del codice.

Per quanto ne so, solo la versione JVM di Scala viene mantenuta aggiornata, la versione .NET no.

Sembra che tu stia mescolando due cose non correlate.

Il primo è quale linguaggio di programmazione viene utilizzato dagli autori di Scala per implementare Scala?

A cui la risposta è, Scala stessa. Ed è l'unica risposta accettabile, davvero, perché se hai inventato questo nuovo linguaggio, ma non lo usi tu stesso per implementarlo, a cosa serve?

La seconda cosa è: qual è la piattaforma target per l'esecuzione dei programmi scritti in Scala?

Qui la scelta diventa più interessante, ma per ora l'unico obiettivo che funziona al 100% è JVM. Il supporto per .NET è ancora in fase di elaborazione. Inoltre, alcune persone stanno lavorando per convincere Scala a compilare in javacsript. In teoria, nulla impedisce a qualcuno di aggiungere più "backend" per la compilazione in C, C ++, LLVM, codice nativo o altro.

Perché JVM è stata scelta come piattaforma principale? La mia ipotesi è perché

• tutti vogliono la raccolta dei rifiuti
• un gran numero di buone librerie pronte per l'uso
• un gran numero di programmatori annoiati da Java pronti a saltare a qualcosa di nuovo, ma rimangono entro i limiti di JVM (nessuno vuole migrare il loro codice esistente su un'altra piattaforma)

Prima di tutto, ciò che immagino volessi davvero chiederti è perché Scala non è un linguaggio compilato in modo rigoroso. Ti dirò che non lo so. Ma ti dirò anche che non c'è motivo di favorire JVM rispetto al codice nativo.

Perché? Il motivo è semplice: qualsiasi tecnologia di virtualizzazione è affamata di memoria, produce sovraccarico non necessario e un altro livello di indiretta. Non si tratta della loro implementazione - è un dato di fatto, della logica che sta alla base del concetto centrale di virtualizzazione. Indipendentemente da ciò che fai, finirai SEMPRE con caratteristiche inferiori. Soprattutto JVM ha fame di memoria. Non è più così lento, perché ha il proprio compilatore di runtime in esecuzione dietro la schiena, ma comunque - deve eseguire il processo di compilazione per essere in grado di individuare le parti più congestionate del codice e trasformarle in codice binario.

Detto questo, l'unica ragione per cui penso che fosse lì per realizzare la Scala JVM era probabilmente la popolarità della lingua. Immagino anche che alla base di questa decadenza ci fosse una certa pigrizia perché è più semplice implementare un linguaggio sulla JVM piuttosto che capire come dovrebbero essere le cose assemblate per lavorare su più piattaforme - e anche l'uso di backend C esistenti richiede molto più lavoro a causa del fatto che le cose non sono così standardizzate come con JVM.

Questo è il motivo che mi viene in mente, ma tieni presente che potrebbero esserci altri motivi - come l'emissione di licenze e la politica coinvolta lì (che sono cose sporche in cui non mi piacerebbe mai entrare).

Non è chiaro che avere una capacità di messa a punto migliore sarebbe un buon compromesso. Le JVM possono eseguire l'ottimizzazione in fase di runtime, e questo è almeno abbastanza buono, se non superiore a ciò che accade in genere con la compilazione statica. (Ovviamente in linea di principio per un'applicazione e un carico di lavoro specifici dovrebbe essere possibile battere JIT con ottimizzazioni statiche, ma praticamente non si dispone spesso del carico di lavoro preciso o dell'intera applicazione.)