Чому немає інших мов програмування, які компілюються в байт-код Python?

У Java є кілька мов, які компілюються в байт-код Java і можуть працювати на JVM - Clojure, Groovy і Scala - основні з яких я запам'ятаю вгорі голови.

Однак Python також перетворюється на байт-код (.pyc-файли), перш ніж запускати інтерпретатор Python. Я можу бути просто неосвіченим, але чому немає інших мов програмування, які компілюються в байт-код python?

Це лише тому, що ніхто не турбується, або є якесь вроджене обмеження чи бар'єр, який ускладнює це?

Просто: останній раз, коли я перевіряв, Python не мав жодної формальної специфікації, включаючи його байт-код. CPython - це специфікація, а переносимість байт-коду - IIRC не потрібна. Таким чином, це рухома, недокументована ціль, розроблена для певної мови.

Існує кілька мов JVM, оскільки були талановиті люди, які хотіли написати код, який би працював з існуючим кодом Java, але вони не хотіли писати Java .

Мабуть, немає програмістів, які хочуть працювати з існуючим кодом Python, але ненавидять Python, щоб передати іншу мову інтерпретатору байт-коду Python.

Ви можете подивитися на це двома способами: існують альтернативні мови для JVM, оскільки Java настільки поширений, або немає альтернативних мов для інтерпретатора байт-коду Python, оскільки Python не смокче.

Є такі технічні недоліки, як GIL у CPython, але мало сприйнятих мовних недоліків, тому час виконання не є точкою продажу спільноти Python. З точністю до навпаки, є більше варіантів виконання запуск через незадоволення реалізацією GIL / CPython.

Мова Java набагато злісніше, ніж JVM (навіть у спільноті Java).

JVM досить добре розглядається в більшості кіл; таким чином, прагнення до іншого / кращого мовного фронту закінчується перевагами високооптимізованого заднього кінця JVM.

Я кажу, що Мейсон Вілер має рацію. Це здебільшого проблема глобального блоку інтерпретаторів, що робить паралельність дуже тернистою проблемою. Оскільки існують й інші віртуальні машини, які роблять сумісність дуже добре порівняно, є сенс розробити для них мови. Також останнім часом Python зазнав серйозних зрушень у мові, і багато бібліотек часом не сприйняли можливість сумісності бути легким кошмаром. Наприклад, оскільки я використовую PIL для роботи із зором, мені доведеться кодувати в Python 2.7 або нижче. Це не стосується налаштувань JVM чи CLI, які, особливо у випадку останнього, були розроблені з урахуванням мовного інтеропу.

Провели ще кілька досліджень і, мабуть, насправді є два GIL, не лише одна. Інші елементи контролю імпорту .

Інші відповіді мають багато сенсу, але насправді існують мови, які збираються на Python. Де є воля ...

Я нічого не знаю про ці мови, але вони, здається, спрацьовують, перекладаючи свій вихідний код в ASTs Python і дозволяючи Python складати дерева в байт-код, уникаючи проблем, згаданих в інших відповідях.

Виходячи з коментарів, в даний час ми знаємо три альтернативні мови, які використовують Python VM (сміливо додайте сюди будь-які інші):

• Мочі описує себе як динамічно типізовану мову програмування для функціонального програмування та програмування в акторському стилі .
• Hy : Охарактеризує себе як діалект Ліспа, вбудований у Python .
• dg : Описує себе як (технічно) просту мову, яка компілюється в байт-код CPython .

Інша причина полягає в тому, що СВМ є високооптимізованою, розвиненою та надзвичайно повною екосистемою. Сам по собі він надзвичайно добре конкурує з будь-якою з інших складених мов. (Я не скажу, що це найкращий VM загального призначення там, але я, безумовно, заробив свою кар’єру на цьому.) Тож отримання доступу до JVM, не маючи написання байт-коду, бажано саме по собі.

Однак, Python VM хороший, але (нічого проти Python) не має серйозних недоліків. Навколишнє середовище виконання Python добре відповідає динамічному характеру мови, але може насправді здивувати вас, коли ви ознайомитесь із його використанням пам'яті, глобальним блокуванням або нарізкою.

У порівнянні між собою, JVM, як правило, вдвічі швидший, ніж Python VM. JVM (надмірно) навіть добре конкурує з власне складеним кодом на основі "гарячих" оптимізацій, які він виконує. І це навіть не рахуючи складнішої обробки ниток тощо.

Я люблю Python, я справді це роблю, і ненавиджу це говорити, але іноді вистава просто кидає мені в зуби - інакше чому б критичні бібліотеки Python, як numpy або scipy, повинні повернутися до коду С?

Іншими словами, люди, які тяжіють до Python, роблять це, тому що їм подобається мова . Але якщо ви хочете написати абсолютно нову мову відповідно до ваших уподобань, вам набагато краще скласти компіляцію до JVM, оскільки ваша нова ідіосинкратична мова розпочнеться в одному з найкращих (суб'єктивно, можливо, найкращих) операційних середовищ.