Dlaczego nie ma innych języków programowania, które kompilują się do kodu bajtowego Pythona?

51

W Javie istnieje wiele języków, które kompilują się do kodu bajtowego Java i mogą działać na JVM - Clojure, Groovy i Scala są głównymi, które pamiętam z głowy.

Jednak Python zamienia się również w kod bajtowy (pliki .pyc) przed uruchomieniem przez interpreter Pythona. Mogę być po prostu ignorantem, ale dlaczego nie ma innych języków programowania, które kompilują się do kodu bajtowego Pythona?

Czy to tylko dlatego, że nikt się tym nie przejmował, czy też istnieje jakieś nieodłączne ograniczenie lub bariera utrudniająca to?

python virtual-machine virtual-machine-languages

— Michael0x2a
źródło

30

... bo nie chcą się zajmować GIL? ;)

— Mason Wheeler

4

Instynkt powiedziałby mi, że ma to wiele wspólnego z tym, jak dojrzała jest JVM, dobrze określona, a JVM jest na praktycznie wszystkich platformach lub jest głupia, łatwa do zdobycia.

— Rig

4

Podejrzewam również, że większość JVM jest znacznie szybsza niż interpretery Pythona.

— Peter Smith

19

Wybierając kod bajtowy Java, uzyskujesz wszystkie funkcje JVM (bezpieczeństwo, wydajność, przenośność, skalowalność itd.). Kierowanie na kod bajtowy Pythona nie daje zbyt wiele.

— David Schwartz

3

Kod bajtowy Pythona nie jest rozpoznawany przez późniejsze wersje interpretera Pythona. Jak ktokolwiek może wdrożyć język programowania kompilujący się do kodu bajtowego Pythona?

— Gus,

77

Proste - ostatnim razem, gdy sprawdzałem, Python nie miał formalnej specyfikacji, w tym kodu bajtowego. CPython jest specyfikacją, a przenośność kodu bajtowego jest IIRC nie jest wymagana. Jest to więc ruchomy, nieudokumentowany cel zaprojektowany dla określonego języka.

— p_l
źródło

22

W rzeczywistości szczegóły formatu kodu bajtowego często zmieniają się między mniejszymi wersjami, a nawet PyPy kompatybilny w 99% nawet nie próbuje (w rzeczywistości dodają własne instrukcje kodu bajtowego).

Uwaga: Python - język - ma formalną specyfikację (patrz „PEP”). „Maszyna wirtualna Python” nie ma. Jest to w rzeczywistości odmienna (np.) Java, w której oba są określone.

— Albert

56

Istnieje wiele języków JVM, ponieważ byli utalentowani ludzie, którzy chcieli pisać kod, który działałby z istniejącym kodem Java, ale nie chcieli pisać Java .

Najwyraźniej nie ma programistów, którzy chcieliby pracować z istniejącym kodem Python, ale nienawidzą języka Python na tyle, aby przenieść inny język na interpreter kodu bajtowego Python.

Można na to spojrzeć na dwa sposoby: istnieją alternatywne języki dla JVM, ponieważ Java jest tak rozpowszechniona, lub nie ma alternatywnych języków dla interpretera kodu bajtowego Python, ponieważ Python nie jest do kitu.

— Kevin Cline
źródło

7

Mam nadzieję, że nie sugerujesz, że Java jest do bani lub Java jest do więcej niż Python :-)

— Giorgio

8

@Giorgio: Sugeruję, że twórcy Groovy, Scali, Clojure itp. Uważali, że istnieje wiele możliwości poprawy. Czy sugerujesz, że Python jest do bani?

— kevin cline

8

Po pracy z pytonem powiedziałbym, że „niski współczynnik ssania” byłby niedokładny. To kosztuje zbyt wiele powszechnie akceptowanych rzeczy, a cała ta „własna” rzecz jest wyjątkowo bezproduktywna. W rzeczywistości głupi. Skąd metoda klasy nie wie, gdzie należy?

— Rig

6

@Rig Osobiście uważam, że podejście Pythona jest bardziej eleganckie. OO wynika organicznie ze składni, zamiast wymagać specjalnego słowa kluczowego, które wygląda jak zmienna. To, dlaczego metody klas nie wiedzą, gdzie się znajdują, to dlatego, że definicje klas Pythona są tylko kodem, a ten kod nie jest uprzywilejowany, ponieważ zdarza się, że znajduje się w definicji klasy. Możesz zdefiniować metody w dowolnym miejscu i dodać je do klasy w czasie wykonywania. W rzeczywistości możesz wziąć tę samą funkcję i używać jej jako metody w wielu klasach, co tak naprawdę nie działałoby z tym thisparadygmatem.

— Antimony

6

Myślę, że to kwestia maszyn wirtualnych, a nie języków. JVM jest wydajną maszyną wirtualną z generacyjnym śmieciarzem, JIT itp. Podczas gdy CPython korzysta z liczenia referencji i jest interpreterem. To CPython jest do bani jako platforma. Btw hyhy istnieje.

— PuercoPop

26

Istnieją pewne braki techniczne, takie jak GIL w CPython, ale niewiele dostrzega braki językowe , więc środowisko uruchomieniowe nie jest zaletą społeczności Python. Dokładnie odwrotnie, istnieje więcej opcji środowiska wykonawczego backend z powodu niezadowolenia z implementacji GIL / CPython.

Język Java jest znacznie bardziej złośliwy niż JVM (nawet w społeczności Java).

JVM jest dość dobrze postrzegany w większości kręgów; stąd pragnienie różnych / lepszych interfejsów językowych z korzyściami wysoce zoptymalizowanego zaplecza JVM.

10

Mówię, że Mason Wheeler ma rację. Jest to głównie problem z blokadą globalnego interpretera, co sprawia, że współbieżność jest bardzo trudnym problemem. Ponieważ istnieją inne maszyny wirtualne, które wykonują współbieżność naprawdę naprawdę dobrze, warto opracować dla nich języki. Również Python przeszedł ostatnio znaczną zmianę językową i wiele bibliotek nie nadrobiło zaległości, przez co kompatybilność była czasem koszmarem. Na przykład, ponieważ używam PIL do pracy z wizją, muszę kodować w Pythonie 2.7 lub starszym. Nie dotyczy to konfiguracji JVM lub CLI, które szczególnie w tym ostatnim przypadku zostały zaprojektowane z myślą o współpracy językowej.

Zrobiłem więcej badań i najwyraźniej istnieją dwa GIL-y, nie tylko jeden. Inne elementy sterujące Importuje .

— Inżynier świata
źródło

1

„GIL free” jest jednym z technicznych powodów wymienionych w „Powodach, dla których programiści CPython mogą być zainteresowani IronPython” na wiki Python .

— yannis

1

@YannisRizos: Z pewnością dostęp do platformy .NET nie jest całkowicie nieistotny. Oczywiście możliwe jest, że użytkownicy CPython nie będą tym zainteresowani.

— Robert Harvey

@RobertHarvey Ninja to edytował. Chociaż nie uważam „dostępu do nowych fantazyjnych zabawek” za techniczny powód (nie dlatego, że zabawki nie są świetne), wiki wspomina również, że IronPython jest łatwiejszy do rozszerzenia.

— yannis

8

Inne odpowiedzi mają wiele sensu, ale obecnie istnieją języki, które kompilują się do Pythona. Gdzie jest wola ...

Nie wiem nic o tych językach, ale wydaje się, że działają, transponując swój kod źródłowy do Pythona AST i pozwalając Pythonowi skompilować drzewa do kodu bajtowego, unikając problemów wymienionych w innych odpowiedziach.

Opierając się na komentarzach, obecnie znamy trzy alternatywne języki, które używają maszyny wirtualnej Python (możesz dodać tutaj inne):

Mochi opisuje się jako dynamicznie typowany język programowania do programowania funkcjonalnego i programowania w stylu aktorskim .
Hy : Opisuje się jako dialekt Lisp osadzony w Pythonie .
dg : Opisuje się jako (technicznie) prosty język, który kompiluje się do kodu bajtowego CPython .

— Carl Smith
źródło

2

Warto również wspomnieć o HyLang

— ideasman42

1

I dg .

— hakatashi

6

Innym powodem jest to, że JVM jest wysoce zoptymalizowanym, dobrze rozwiniętym i niezwykle kompletnym ekosystemem. Samodzielnie konkuruje wyjątkowo dobrze z dowolnym innym skompilowanym językiem. (Nie powiem, że jest to najlepsza maszyna wirtualna ogólnego przeznaczenia, ale z pewnością oparłem na tym swoją karierę). Dlatego uzyskanie dostępu do JVM, bez pisania kodu bajtowego, jest samo w sobie pożądane.

Jednak maszyna wirtualna Python jest dobra, ale (nic przeciwko Pythonowi) ma poważne wady. Środowisko wykonawcze Python dobrze pasuje do dynamicznej natury języka, ale może naprawdę Cię zaskoczyć, gdy zapoznasz się z jego użyciem pamięci, globalnym blokowaniem lub modelem wątków.

W bezpośrednich porównaniach maszyna JVM jest zwykle dwa razy szybsza niż maszyna wirtualna Python. JVM (zaskakująco) nawet dobrze konkuruje z natywnie skompilowanym kodem, bazując na „gorących” optymalizacjach, które wykonuje. I to nie liczy się nawet z bardziej zaawansowaną obsługą wątków itp.

Uwielbiam Pythona, naprawdę to lubię i nie chcę tego mówić, ale czasami wydajność po prostu mnie uderza w zęby - w przeciwnym razie dlaczego krytyczne biblioteki Pythona, takie jak numpy lub scipy, musiałyby wracać do kodu C?

Innymi słowy, ludzie, którzy lubią Python, robią to, ponieważ lubią ten język . Ale jeśli chcesz napisać zupełnie nowy język odpowiadający twoim preferencjom, lepiej jest skompilować do JVM, ponieważ twój nowy idiosynkratyczny język zacznie się w jednym z najlepszych (subiektywnie, być może najlepszych) dostępnych środowisk operacyjnych.

— Obrabować
źródło