Dlaczego Scala nie została zaimplementowana w C lub C ++

28

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?

Joshua Partogi
źródło
18
Ponadto możliwość korzystania z istniejących bibliotek Java i ścisła współpraca z kodem Java to ogromna zaleta, a nie drobiazg.
Tamás Szelei,
6
@OP: mówisz tak, jakby źle było mieć język zaimplementowany na JVM (lub CLR w tym przypadku). Dostrajanie, o którym wspominasz, że jest możliwe w C, nie jest zbliżone do strojenia wprowadzonego do CLR lub JVM. A jeśli platforma się poprawi, Twój język automatycznie dostanie ją za darmo. Biorąc pod uwagę wybór, nikt nie powinien już wdrażać swojego języka w stosunku do good'ol C imho.
Chii,
8
@Chii, po prostu przyznać, Java jest nadal wolniejszy niż C
Joshua Partogi
19
@jpartogi, Java nie może być wolniejsza ani szybsza od C. Są to oba języki, a nie ogiery. W niektórych szczególnych warunkach jakiś określony kod skompilowany przez kompilator Java i wykonany za pomocą określonej maszyny JVM jest wolniejszy niż z grubsza porównywalny kod wygenerowany przez kompilator C. W niektórych innych warunkach ten ostatni będzie wolniejszy.
SK-logic
4
Środowisko wykonawcze Scali jest programem C ++; JVM.
mike30

Odpowiedzi:

59

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?

Daniel C. Sobral
źródło
3
@ mike30 Scala działałby na dowolnej maszynie JVM, nawet gdyby nie był napisany w C ++, więc argument ten nie ma zastosowania. A w czasie wykonywania nie ma kodu C ++, tylko kod maszynowy. Nie jestem jednak pewien, o czym jest ten komentarz.
Daniel C. Sobral
3
prawda jest taka: generowanie kodu maszynowego jest znacznie bardziej złożone niż generowanie kodu bajtowego i wymaga specyficznej implementacji dla każdego systemu operacyjnego, a także strojenia procesorów i różnych architektur (ARM, x86, x86_64) oraz instrukcji zaawansowanych (MMX, SSE ...) W ten sposób przekazuje się JVM ten aspekt.
Raffaello,
2
Jeśli tak dużo mówisz o wydajności wykonania, dlaczego nie mówisz o wydajności pamięci? Czy boisz się, że rzeczy nie wyjdą tak dobrze, jak myślisz?
luke1985
3
@ lukasz1985 To poprawia wydajność, ale dyskusja na temat wydajności obejmuje to, więc nie ma znaczenia w tym względzie. Pozostaje tylko to, czy zależy ci na tym, ile pamięci zajmuje aplikacja, a potem musisz wybierać między GC i tym, a ja wybiorę GC za każdym razem, z wyjątkiem bardzo specyficznych przestrzeni programistycznych, z których żadna nie jest zajmowana przez Scalę. A „to nie jest prawda, żeby powiedzieć” to bzdury - wszyscy Mają taką rację. I chociaż C / C ++ jest bardzo istotny ze względu na dziedzictwo, nigdy nie stałyby się popularne, gdyby zostały wydane w ciągu ostatnich pięciu lat.
Daniel C. Sobral
3
@ lukasz1985 Twoim jedynym dowodem na to, że nie rozumiem, że nie zgadzam się z tobą. Alternatywnym wyjaśnieniem jest to, że się mylisz. I jako ktoś żyjący i programujący „wtedy”, mam perspektywę z pierwszej ręki na podejmowanie decyzji związanych z wyborem C i C ++ zamiast współczesnych alternatyw, o których wspominam nie po to, aby udowodnić swój punkt widzenia, ale aby zaoferować jako przeciwny do twojego: podobieństwo język mówiony nie był w żaden sposób istotny, podczas gdy podobieństwo do kodu maszynowego było.
Daniel C. Sobral
31

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

WŁAŚNIE MOJA poprawna OPINIA
źródło
3
Zdajesz sobie sprawę, że C # i CLR są w rzeczywistości otwartym standardem, z którego każdy może korzystać.
Erin,
7
Myślę, że trochę o tym, gdzie „wiem o Mono”, a potem „wciąż uważam, że jest to środowisko blokady dostawcy” powinno dać ci trochę wskazówek, Erin.
WŁAŚNIE MOJA poprawna OPINIA,
3
@Erin nie jest jednak częścią .NET Framework
alternatywnie
1
@alternative: Jeśli to za dużo blokowania, pomyśl, że testy zgodności Java nadal nie są darmowe, a co najwyżej 6 z jednego, pół tuzina innych dla Javy.
Deduplicator
18

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

Jeremiasz
źródło
10

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.

Dean Harding
źródło
2
Opisane zalety to niektóre z powodów, dla których np. Python został ponownie zaimplementowany zarówno dla JVM (Jython), jak i .NET (IronPython).
dancek 20.04.11
2
-1: Zakładając, że nowe języki mogły być zależne od konkretnej platformy (.Net lub JVM), ponieważ byłyby one dostępne, nie wydaje mi się dobrym argumentem. Na przykład nie widzę żadnego dobrego powodu, aby Python lub Erlang działały na takiej platformie. Hystory nie mówią wszystkiego.
Klaim,
1
I nawet PHP nigdy nie byłby w stanie robić tego, co robi za pomocą JVM lub .Net. @Dean Harding> Nie sądzę, aby IronPython lub Jython udowodniły coś wartościowego.
Klaim,
1
Przykro mi, ale nie było jasne, co miałem na myśli to, że nie miałoby to mieć „sukcesu” (PHP lub Python), ponieważ praca nad JVM lub .Net implikuje wiele rzeczy, które zirytowałyby wielu programistów, powodując im bardziej niszowy język niż obecnie. Z technicznego punktu widzenia platforma (.Net lub JVM) byłaby problemem, ponieważ napędza sposób, w jaki budujesz na niej język. Mówienie za pomocą urządzenia to sposób na stworzenie dokładnie takiego języka, jaki chcesz. Więc z dostępną JVM lub bez niej, widzę 0 dobrych powodów, aby budować .Net i JVM. Inne niż szybkie wdrożenie.
Klaim,
2
Mała korekta: Java jest starsza niż PHP. Ale PHP zaczął jako program CGI, później stał się modułem httpd Apache i jako taki stał się duży. Obie rzeczy (moduł cgi i httpd) nie działają dobrze w Javie. Więc nie jest tak łatwo, JVM nie jest platformą do wszystkiego. ;-)
johannes
6

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.

Glen Best
źródło
4

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.

Josh K.
źródło
3

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ę)
artem
źródło
Nie rozumiem, dlaczego moduł śmieciowy nie może zostać zaimplementowany w C lub C ++? Nie uważam tego za dobry powód. Python to zrobił. Ruby to zrobiła. Heck nawet erlang to zrobił. Kto wie, że Scala może skończyć z lepszym śmieciarzem, jeśli jest napisany w C lub C ++?
Joshua Partogi 21.04.11
1
Miałem na myśli „prawdziwe” wywóz śmieci. Nie sądzę, że zbieranie śmieci, które prowokuje pytania, takie jak ten jeden jest wystarczająco dobre. Heck nawet JVM nie jest wystarczająco dobry - inaczej ludzie tacy jak AzulSystems nie byliby w stanie zarabiać na życie, pomagając innym ludziom przezwyciężyć braki JVM.
artem.
Także biblioteki. Naprawdę trudno jest używać bibliotek napisanych do jawnego zarządzania pamięcią w języku z odśmiecaniem pamięci. Jednym ze wskazań jest szczególne naleganie, aby ludzie z java mieli wszystko w „czystej javie”.
artem.
0

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

luke1985
źródło
-2

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

Bruce Stephens
źródło
brzmi to bardziej jak komentarz, patrz Jak odpowiedzieć
gnat