파이썬 바이트 코드로 컴파일되는 다른 프로그래밍 언어가없는 이유는 무엇입니까?

Java에는 Java 바이트 코드로 컴파일되고 JVM에서 실행할 수있는 여러 언어가 있습니다. Clojure, Groovy 및 Scala는 머리 꼭대기에서 기억할 수있는 주요 언어입니다.

그러나 파이썬은 또한 파이썬 인터프리터에 의해 실행되기 전에 바이트 코드 (.pyc 파일)로 바뀝니다. 방금 모르지만 파이썬 바이트 코드로 컴파일되는 다른 프로그래밍 언어가없는 이유는 무엇입니까?

그 누구도 귀찮게하지 않았거나 그렇게하는 데 방해가되는 어떤 종류의 고유 한 제한이나 장벽이 없기 때문입니까?

단순-마지막으로 확인했을 때 Python에는 바이트 코드를 포함하여 공식적인 사양이 없었습니다. CPython이 스펙이며 바이트 코드 이식성은 IIRC가 필요하지 않습니다. 따라서 특정 언어를 위해 설계된 문서화되지 않은 이동 대상입니다.

기존 Java 코드와 함께 작동하는 코드를 작성하려는 재능있는 사람들이 있었지만 Java를 작성하고 싶지 않았기 때문에 여러 JVM 언어가 있습니다 .

분명히 기존의 파이썬 코드로 작업하고 싶은 프로그래머는 없지만 파이썬 바이트 코드 인터프리터에 다른 언어를 포팅하기에 충분한 파이썬을 싫어합니다.

이것을 두 가지 방법으로 볼 수 있습니다. Java가 널리 보급되어 있기 때문에 JVM에 대한 대체 언어가 있거나 Python이 빨지 않기 때문에 Python 바이트 코드 인터프리터에 대한 대체 언어가 없습니다.

CPython의 GIL과 같은 기술적 결함이 있지만 인식 된 언어 결함은 거의 없으므로 런타임은 Python 커뮤니티의 판매 지점이 아닙니다. 정확히 반대의 경우, GIL / CPython 구현에 대한 불만으로 인해 더 많은 백엔드 런타임 옵션이 있습니다.

Java 언어는 JVM보다 훨씬 더 어둡습니다 (Java 커뮤니티에서도).

JVM은 대부분의 서클에서 잘 알려져 있습니다. 따라서 고도로 최적화 된 백엔드 JVM의 이점으로 다른 언어 /보다 나은 언어 프론트 엔드에 대한 요구가 있습니다.

메이슨 휠러가 옳다고 말합니다. 그것은 대부분 통역을 매우 가시적 인 문제로 만드는 Global Interpreter Lock의 문제입니다. 동시성을 실제로 수행하는 다른 VM이 실제로 비교적 우수하므로 해당 VM을위한 언어를 개발하는 것이 좋습니다. 또한 파이썬은 최근에 언어가 크게 바뀌었고 많은 라이브러리가 때때로 가벼운 악몽과 호환되지 않습니다. 예를 들어 비전 작업에 PIL을 사용하기 때문에 Python 2.7 이하로 코딩해야합니다. 특히 후자의 경우 언어 interop을 염두에두고 설계된 JVM 또는 CLI 설정의 경우에는 해당되지 않습니다.

더 많은 연구를 해본 결과 실제로 하나의 GIL이 아닌 두 개의 GIL이 있습니다. 다른 컨트롤은 가져 오기를 제어합니다 .

다른 대답은 의미가 있지만 실제로 파이썬으로 컴파일되는 언어가 있습니다. 의지가있는 곳 ...

나는이 언어들에 대해 아무것도 모른다. 그러나 그들은 소스 코드를 파이썬 AST로 변환하고 파이썬이 다른 답변에서 언급 된 문제를 피하면서 트리를 바이트 코드로 컴파일하도록 허용함으로써 작동하는 것처럼 보인다.

의견을 바탕으로 현재 Python VM을 사용하는 세 가지 대체 언어를 알고 있습니다 (여기에 다른 언어를 자유롭게 추가하십시오).

• Mochi 함수형 프로그래밍 및 액터 스타일 프로그래밍을위한 동적 유형의 프로그래밍 언어 로 설명합니다 .
• Hy : 파이썬에 내장 된 Lisp의 방언으로 설명합니다 .
• dg : CPython 바이트 코드로 컴파일하는 (기술적으로) 간단한 언어로 설명합니다 .

또 다른 이유는 JVM이 고도로 최적화되고, 진화하며, 완벽한 생태계이기 때문입니다. 자체적으로 다른 컴파일 언어와 경쟁이 치열합니다. (저는 그것이 최고의 범용 VM 이라고는 말할 수 없지만 확실히 저의 경력을 쌓았습니다.) 따라서 바이트 코드 작성이 부족한 JVM에 액세스하는 것이 그 자체로 바람직합니다.

그러나 Python VM은 좋지만 (Python에 대한 것은 없음) 심각한 단점이 있습니다. Python 런타임 환경은 언어의 동적 특성에 잘 맞지만 메모리 사용, 전역 잠금 또는 스레딩 모델에 익숙해지면 놀랄 수 있습니다.

일대일 비교에서 JVM은 일반적으로 Python VM보다 두 배 빠릅니다. JVM은 (놀랍게도) 수행하는 "핫"최적화를 기반으로 기본 컴파일 된 코드와 잘 경쟁합니다. 그리고 더 복잡한 스레드 처리 등은 계산하지 않습니다.

나는 파이썬을 좋아하고 정말로하고 말하기를 싫어하지만 때로는 성능이 나에게 도움이됩니다. 그렇지 않으면 numpy 또는 scipy와 같은 중요한 Python 라이브러리가 C 코드로 돌아 가야하는 이유는 무엇입니까?

다시 말해서, 파이썬 을 좋아하는 사람들은 언어를 좋아하기 때문에 그렇게 합니다 . 그러나 환경 설정에 맞게 새로운 언어를 작성하려면 JVM으로 컴파일하는 것이 훨씬 좋습니다. 새 특유의 언어는 사용 가능한 최상의 (주관적으로, 아마도 최상의) 운영 환경 중 하나에서 시작하기 때문입니다.