Czy ktoś wie, dlaczego Scala została zaimplementowana w Javie i .NET zamiast C lub C ++? Większość języków jest implementowana w Cor C ++ [tj. Erlang, Python, PHP, Ruby, Perl]. Jakie są zalety Scali zaimplementowanej w Javie i .NET, poza umożliwieniem dostępu do bibliotek Java i .NET?

AKTUALIZACJA

Czy Scala nie zyskałaby więcej korzyści, gdyby został zaimplementowany w C, ponieważ można go lepiej dostroić, niż polegać na JVM?

Pytanie jest mylące, ponieważ C i C ++ są językami , podczas gdy JVM jest maszyną wirtualną, a .Net platformą . Scala może być zaimplementowana w C lub C ++ i może generować kod maszynowy zamiast kodu bajtowego dla maszyny wirtualnej.

Odpowiedź na zadane pytanie:

Scala nie została zaimplementowana w C lub C ++, ponieważ Scala, język, w którym jest faktycznie zaimplementowany, jest znacznie lepszym językiem.

Dlaczego to jest lepsze? Cóż, przeczytaj o celach Oderskiego w języku Scala .

Odpowiedź na pytanie, które mogło być zamierzone:

Scala generuje przede wszystkim kod bajtowy JVM, ponieważ zapewnia doskonałą przenośność, a także takie funkcje, jak niezawodny i wydajny moduł wyrzucania elementów bezużytecznych, optymalizacje w czasie wykonywania oraz kompilacja „na czas” przez JVM .

Powtórzę tę ostatnią rzecz: JVM skompiluje się do kodów maszynowych w uruchomionym kodzie. To jest kompilacja, podobnie jak kompilatory C i C ++.

Dostępne są inne maszyny wirtualne, ale Odersky, twórca Scali, był już bardzo dobrze zaznajomiony z JVM. Zamierzał mieć CLR jako alternatywę, ale wysiłek, aby to osiągnąć, nie przyniósł jeszcze sukcesu.

Odpowiedź na pytanie, które mogło / powinno być zadane:

Kompilacja do kodu maszynowego nie zapewnia wystarczających korzyści w porównaniu z kompilacją do kodu bajtowego JVM.

Z pewnością możliwe jest generowanie mikrodruków w C lub C ++, które pobijają odpowiedniki JVM. Prawdą jest również, że wyjątkowo zoptymalizowany kod w C lub C ++ pobije wyjątkowo zoptymalizowany kod w Javie lub Scali. Różnica nie jest jednak aż tak duża w przypadku programu działającego długo.

Zauważ, że Scala nie jest szczególnie dobrym językiem skryptowym właśnie dlatego, że narzut dla krótkich programów jest zbyt duży.

Jednak w większości przypadków szybkość rozwoju i łatwość konserwacji są ważniejsze niż szybkość wykonania . W tych przypadkach, gdy ludzie są bardziej zainteresowani pisaniem bardzo wysokiego poziomu kodu, który jest łatwy do zrozumienia i zmiany, optymalizacje w czasie wykonywania zapewniane przez JVM mogą z łatwością pokonać optymalizacje w czasie kompilacji wykonane przez kompilatory C lub C ++, tworząc JVM (i CLR ) cel, który faktycznie wykona się szybciej.

Tak więc, bez względu na to, czy pytanie dotyczyło kompilatora Scala jako pliku wykonywalnego kodu maszynowego, czy programów Scala będących kodem maszynowym, potencjalne przyrosty prędkości niekoniecznie przekładają się na rzeczywiste przyrosty prędkości.

A przy okazji,

Dam ci kontrprzykład: Haskell. Haskell generuje kod maszynowy, a jednak programy Haskell gorzej wypadają w strzelaninie Debiana niż w Scali. Biorąc to pod uwagę, czy ktoś może być pewien, że programy Scala byłyby szybsze, gdyby były kompilowane bezpośrednio do kodu maszynowego?

Jedną z największych przeszkód, jakie napotykają języki, gdy wprowadza się je na cały świat, jest dostępność bibliotek. Tradycyjną odpowiedzią na to jest zapewnienie FFI opartego na języku C (interfejs funkcji obcych), aby umożliwić ci dostęp do bibliotek opartych na języku C. Nie jest to idealne z różnych powodów, między innymi:

• Istnieje wiele różnych sposobów interakcji bibliotek, które nie są kompatybilne z wieloma językami wyższego poziomu. Na przykład, jeśli biblioteka chce uzyskać wskaźnik do a struct, jak radzą sobie języki bez wskaźników ORAZ bez structproblemu?
• Występują ostre interakcje między modelami pamięci różnych bibliotek i języków, których często nie da się rozwiązać lub, jeśli można je rozwiązać, są bardzo podatne na błędy i błędy.
• Kod kleju dla wielu FFI jest nietrywialny i zakłada wiedzę, która w rzeczywistości może nie być uniwersalna. (Wierzcie lub nie, nie wszyscy programiści są guru C i ani nie chcą być, ani nie powinni tego wymagać!)

Z C ++ jest jeszcze gorzej. C ++ nie jest nawet kompatybilny z C ++ (to znaczy na poziomie binarnym) od kompilatora do kompilatora na tej samej platformie (!), Nie wspominając o innych językach.

Ukierunkowanie na JVM rozwiązuje wiele z tych problemów, zapewniając jednocześnie dostęp do absolutnie ogromnego pakietu bibliotek opartych na Javie. (Jak ogromny? Po prostu sięgnij po ogromny wybór Fundacji Apache Software Foundation na początek.)

• Konwencje wywoływania i własności Java są bardziej regularne niż C.
• JVM zapewnia również pojedynczy model pamięci (w tym wyrzucanie elementów bezużytecznych) dla języków i bibliotek, z którymi można się komunikować. Nie trzeba śledzić, kto jest właścicielem tego, a co musi gdzie posprzątać. Środowisko wykonawcze robi to za Ciebie.
• Kod kleju dla FFI, dla większości języków zbudowanych na JVM, nie istnieje (ponieważ jest dostarczony jako struktura za kulisami w języku). Na przykład nie ma potrzeby programowania w Javie, aby uzyskać dostęp do bibliotek Java w Scali, Clojure, JRuby itp. Dostęp do obiektów Java uzyskuje się w taki sam sposób, jak do rodzimych „obiektów” (przestraszyć cytaty, ponieważ na przykład Clojure nie mieć rzeczywiste obiekty w sensie OOP) i w swoim ojczystym języku.

Oprócz tych zalet masz także dodatkowe zalety uruchamiania w dowolnym miejscu Java bez rekompilacji (ale z testowaniem !: pisz raz, testuj wszędzie) i mając dostęp do imponującej technologii JIT Javy.

CLR zapewnia podobne mocne strony, ale dodaje słabość IMO: jest to w zasadzie środowisko blokowania dostawcy. (Tak, wiem o Mono. Nadal uważam, że jest to środowisko blokady dostawcy).

Według tego wywiadu głównym powodem był dostęp do istniejącej infrastruktury i bibliotek Java.

... Java jest istniejącym językiem z bardzo trudnymi ograniczeniami. W rezultacie nie mogłem zrobić wielu rzeczy w sposób, w jaki chciałbym to zrobić - w sposób, w jaki byłem przekonany, że byłby to właściwy sposób. Więc po tym czasie, kiedy zasadniczo skupiłem się na ulepszeniu Javy, zdecydowałem, że nadszedł czas, aby cofnąć się o krok. Chciałem zacząć od czystego arkusza i zobaczyć, czy mogę zaprojektować coś lepszego niż Java. Ale jednocześnie wiedziałem, że nie mogę zacząć od zera. Musiałem połączyć się z istniejącą infrastrukturą, ponieważ w innym przypadku po prostu niepraktyczne jest ładowanie się z niczego bez bibliotek, narzędzi i podobnych rzeczy.

Zdecydowałem więc, że chociaż chcę zaprojektować język inny niż Java, zawsze łączy się on z infrastrukturą Java - z JVM i jego bibliotekami . To był pomysł ...

Wszystkie pozostałe języki, o których wspominasz, Erlang, Python, PHP, Ruby, Perl - wszystkie zostały utworzone przed Javą i .NET. Jeśli twórcy tych języków mieli w tym czasie do dyspozycji środowisko wykonawcze Java lub .NET, to możliwe, że wykorzystali je podczas budowania swojego języka.

Oczywiście nie mogę mówić za twórcami tych języków, więc nie mogę powiedzieć z całą pewnością , że użyliby .NET i / lub Java podczas ich tworzenia, gdyby były dostępne, ale wydaje mi się, że dobry pomysł. W końcu, projektując język do kompilacji do kodu bajtowego Java / .NET, zyskujesz wszystkie zalety kompilatorów / optymalizatorów JIT, twój język automatycznie działa na wszystkich platformach, na których działa Java / .NET, masz dostęp do wszystkich biblioteki Java / .NET i tak dalej.

Kod C jest kompilowany statycznie do kodu natywnego (kod maszynowy).

Scala jest kompilowana statycznie do kodu bajtowego java, a następnie, w razie potrzeby, dynamicznie kompilowana do zoptymalizowanego kodu natywnego. Proces:

Kod Scala --- skompilowany statycznie do ---> bajtowy kod JVM --- dynamicznie skompilowany przez JVM-Hotspot-to ---> kod macierzysty

Ogólne opcje budowania / uruchamiania dowolnego języka:

• a) interpretuj kod źródłowy bezpośrednio za pomocą silnika interpretera środowiska wykonawczego
• b) statycznie kompilować kod do kodu natywnego (ewentualnie poprzez etapy pośrednie, np. source -> C -> native)
• c) statycznie kompiluj kod źródłowy do kodu pośredniego niższego poziomu i interpretuj go w czasie wykonywania
• d) statycznie kompiluj kod źródłowy do kodu pośredniego niższego poziomu, następnie użyj wstępnej interpretacji, a następnie dynamicznych technik kompilacji i optymalizacji w celu konwersji na kod macierzysty. Kod jest interpretowany do momentu znalezienia typowych ścieżek wykonania i wąskich gardeł, a następnie kod jest kompilowany w celu najszybszego wykonania w typowych warunkach. Zostanie ponownie skompilowany / zestrojony, gdy warunki wykonania zmienią się wystarczająco, aby to uzasadnić

Twoje pytanie: „Dlaczego Java używa (d) z JVM zamiast (b) z kodem pośrednim C?”

Odpowiedź:

Po pierwsze, zauważ, że Scala to dużojęzyk wyższego poziomu niż C, dający moc programowania, łatwość programowania i zwięzłość. Chodzi o „1 poziom wyżej” niż Java ze względu na funkcje pierwszej klasy i wyższego rzędu, funkcje niejawne, funkcje jako obiekty, zamknięcia i curry, wsparcie kompilacji rekurencji do szybkich pętli zachowujących stos, wszystko jako obiekty, wszystkie operatory jako metody które mogą być (ponownie) zdefiniowane w bibliotekach, klasach przypadków i redukcji (dopasowywanie wzorców), niejawne wyprowadzanie typów, silniejszy polimorfizm poprzez rozszerzone cechy wielokrotnego dziedziczenia i rozszerzone cechy ogólne, wbudowana składnia dla par i krotek i wad (list i drzew ) i mapy, wsparcie dla niezmiennych struktur danych, wsparcie dla potężnego „reaktywnego” przetwarzania równoległego i współbieżnego z kopiowaniem i przekazywaniem wiadomości między aktorami zaawansowane wsparcie dla dowolnych domen DSL, skryptowalności i REPL. Java jest o „1 poziom wyżej” niż C ze względu na orientację obiektową, zarządzanie wskaźnikami i zbieranie śmieci, obsługę łańcuchów, obsługę wielowątkowości i kontrolę współbieżności, a także standardowe biblioteki API.

1. Wydajność: w przypadku języka wysokiego poziomu (d) daje wyższą wydajność niż (a) - (c).
   Bezpośrednio napisany i zoptymalizowany ręcznie kod C jest szybki. Jednak języki wyższego poziomu skompilowane statycznie do C są stosunkowo wolne. Projektanci Java dobrze o tym wiedzieli. Obecny projekt „Hotspot” zwiększa wydajność nawet o rząd wielkości. Na jednym rdzeniu kod Java HotSpot jest średnio „50% tak szybki” jak zoptymalizowany dla człowieka C (w najlepszym przypadku jest to „120% tak szybko”, w najgorszym przypadku „30% tak szybko”). Ale oczywiście to porównanie jabłek z pomarańczami - kod niskiego poziomu v kod wysokiego poziomu. I to by było dużogorzej, jeśli nie zastosowano optymalizacji Hotspot. Aby to potwierdzić, po prostu wyłącz kompilację hotspotów za pomocą argumentów JVM! Lub rozważ wydajność java 1 i 2, gdy punkt dostępu nie istniał lub był niedojrzały. Lub spróbuj skompilować inny język przez C - np. Perlcc. Tak więc powyższe wyniki są świetne dla wydajnego i wydajnego języka. Przy dalszym rozwoju możliwe jest (a nawet prawdopodobne), że JVM może wkrótce wyprzedzić ręcznie kodowane C. Scala jest średnio o 70–80% tak wolna jak java. Ale Scala silnie skaluje się w wielu rdzeniach (z dalszymi ulepszeniami, które będą w toku), podczas gdy Java częściowo, a C nie. Oceniono wydajność jednego rdzenia dla takich języków wysokiego poziomu:

   interpretowane <skompilowane statycznie <skompilowane dynamicznie

   Oceniono wydajność / skalowalność wielordzeniową:

   interpretowany kod dynamiczny <statycznie skompilowany kod imperatywny <statycznie skompilowany kod funkcjonalny / deklaratywny <dynamicznie skompilowany kod funkcjonalny / deklaratywny

   To stawia Scalę na zwycięskim miejscu, ponieważ prędkość procesora przekroczyła swój limit, a teraz liczba rdzeni rośnie zgodnie z prawem Moore'a. Scala jest bardzo szybka na wielu rdzeniach, aw przyszłości może stać się kilka razy szybsza niż C lub Java. Kompilacja statyczna do C nie jest oczywiście najszybszą opcją.

2. Interoperacyjność: języki na szeroko obsługiwanej maszynie wirtualnej mają lepszą interoperacyjność językową niż języki „izolowane”. Scala „automatycznie bawi się” klasami, interfejsami i obiektami Java, po prostu importując je i używając ich tak, jakby były klasami, cechami i obiektami Scala. Podobnie jest w przypadku innych języków JVM, takich jak Groovy, Clojure, JRuby i JPython - z łatwością współdziałania zależną od tego, jak czysto każdy język został przygotowany do kompilacji z zrozumiałymi i użytecznymi klasami / interfejsami / obiektami środowiska Java. Tyle przychodzi za „za darmo” (jak w „blisko”). Scala współpracuje z C poprzez JNA, następcę JNI - który pojawia się z pewnym wysiłkiem, ale z biegiem czasu narzędzia były dość usprawnione. JNA może faktycznie współpracować ze skompilowanym rodzimym kodem z dowolnego dowolnego języka - ale musisz znać dokładną strukturę skompilowanych typów danych i funkcji. Jeśli nie,

3. Przenośność: JVM działa na dziesiątkach platform / wersji systemów operacyjnych „od razu po wyjęciu z pudełka”. Scala jest do nich automatycznie przenoszony. Zauważonym wyjątkiem jest iOS (iPad / iPhone / iPod) - zablokowany „komercyjnie”, a nie „technicznie” przez Apple. Nie można było tego przewidzieć 12 lat wcześniej, podczas wstępnego projektowania JVM. JVM działa dobrze na kilkudziesięciu innych serwerach, komputerach stacjonarnych, telefonach komórkowych i urządzeniach wbudowanych, w tym na tych, które nie obsługują C - w tym Androida z dostosowaną do Google Dalvik VM (50% + sprzedanych nowych telefonów). Jasne, kod C działa na wielu platformach, więc może być oceniany „tam z lub prawdopodobnie poza” Javą (zwłaszcza C jest podzbiorem Objective-C). Ale C będzie kosztować (1), (2) i (3). Oczywiście warstwa prezentacji HTML5 / javascript / webkit (lub Objective-C) na iOS może współpracować ze zdalną aplikacją Scala - więc deweloper powinien to zrobić. Oczywiście będą mniej wydajne.

4. Narzędzia i biblioteki : Oczywiście istnieją tysiące komercyjnych i otwartych bibliotek Java oraz narzędzi, które mogą być wykorzystywane przez Scala - więcej niż w przypadku C.

5. Bezpieczeństwo: - uruchamianie na kontrolowanym serwerze aplikacji lub środowisku JVM zapewnia silniejsze wsparcie dla zasad i ograniczeń bezpieczeństwa, które mogą być bardzo cenne w środowisku korporacyjnym.

JVM / CLR

JVM (i CLR) zapewniają unikalne zalety w zakresie optymalizacji i przenośności kodu.

O ile mi wiadomo, tylko wersja JVM Scali jest aktualizowana, wersja .NET nie.

Wygląda na to, że łączysz dwie niezwiązane ze sobą rzeczy.

Po pierwsze, który język programowania jest używany przez autora (autorów) Scali do implementacji Scali?

Odpowiedź brzmi: sama Scala. To naprawdę jedyna możliwa do zaakceptowania odpowiedź, ponieważ jeśli wymyśliłeś ten nowy język, ale nie używaj go sam do jego implementacji - po co to jest?

Po drugie, jaka jest docelowa platforma do uruchamiania programów napisanych w Scali?

Tutaj wybór staje się bardziej interesujący, ale na razie jedynym celem, który działa w 100%, jest JVM. Obsługa platformy .NET jest nadal w toku. Ponadto niektórzy ludzie pracują, aby Scala skompilowała się z javacsript. Teoretycznie nic nie stoi na przeszkodzie, aby ktoś dodał więcej „backendów” do kompilacji do C, C ++, LLVM, kodu natywnego lub cokolwiek innego.

Dlaczego JVM została wybrana jako platforma podstawowa? Domyślam się, ponieważ

• wszyscy chcą śmieci
• duża liczba dobrych bibliotek gotowych do użycia
• duża liczba programistów znudzonych Javą gotowa skoczyć na coś nowego, ale trzymaj się ograniczeń JVM (nikt nie chce migrować swojego istniejącego kodu na inną platformę)

Po pierwsze - myślę, że naprawdę chciałeś zapytać, dlaczego Scala nie kompiluje języka w sposób ścisły. Powiem ci, że nie wiem. Ale powiem ci również, że nie ma powodu, aby faworyzować JVM w stosunku do kodu natywnego.

Czemu? Powód jest prosty: każda technologia wirtualizacji wymaga pamięci, powoduje niepotrzebne koszty ogólne i kolejną warstwę pośrednictwa. Nie jest to kwestia ich implementacji - jest to logika leżąca u podstaw koncepcji wirtualizacji. Bez względu na to, co robisz, ZAWSZE kończysz na gorszych właściwościach. Zwłaszcza JVM jest głodny pamięci. Nie jest już tak powolny, ponieważ ma swój własny kompilator uruchomieniowy działający z tyłu, ale nadal - musi uruchomić proces kompilatora, aby móc wykryć najbardziej zatłoczone części kodu i przekształcić je w kod binarny.

Powiedział, że - jedynym powodem, dla którego myślę, że był oparty na Scala JVM, była prawdopodobnie popularność tego języka. Sądzę też, że za tą decyzją kryło się trochę lenistwa, ponieważ łatwiej jest zaimplementować język za pomocą JVM, niż dowiedzieć się, jak powinno wyglądać to, jak powinno być złożone na wielu platformach - a nawet użycie istniejących backendów C wymaga dużo więcej pracy z uwagi na fakt że sprawy nie są tak dobrze znormalizowane jak w przypadku JVM.

To jest powód, dla którego mogę myśleć, ale pamiętaj, że mogą istnieć inne powody - na przykład wydawanie licencji i polityka (które są brudnymi rzeczami, w które nigdy nie chciałbym się wdawać).

Nie jest jasne, czy umiejętność lepszego strojenia byłaby dobrym kompromisem. Maszyny JVM mogą przeprowadzać optymalizację w czasie wykonywania, co zwykle jest co najmniej wystarczająco dobre, jeśli nie lepsze niż to, co zwykle dzieje się z kompilacją statyczną. (Oczywiście w zasadzie w przypadku konkretnej aplikacji i obciążenia pracą powinno być możliwe pokonanie JIT za pomocą statycznych optymalizacji, ale w praktyce często nie ma precyzyjnego obciążenia pracą ani nawet całej aplikacji.)