Tại sao không có ngôn ngữ lập trình khác biên dịch sang mã byte Python?

51

Trong Java, có nhiều ngôn ngữ biên dịch thành mã byte Java và có thể chạy trên JVM - Clojure, Groovy và Scala là những ngôn ngữ chính mà tôi có thể nhớ ra khỏi đỉnh đầu.

Tuy nhiên, Python cũng biến thành mã byte (tệp .pyc) trước khi được trình thông dịch Python chạy. Tôi có thể không biết gì, nhưng tại sao không có ngôn ngữ lập trình nào khác biên dịch thành mã python?

Có phải chỉ vì không ai bận tâm, hoặc có một số loại hạn chế hoặc rào cản cố hữu tại chỗ khiến cho việc thực hiện rất khó khăn?

python virtual-machine virtual-machine-languages

— Michael0x2a
nguồn

30

... bởi vì họ không muốn đối phó với GIL? ;)

— Mason Wheeler

4

Các bản năng sẽ cho tôi biết rằng nó có liên quan nhiều đến việc JVM trưởng thành như thế nào, được chỉ định rõ và JVM hầu như trên tất cả các nền tảng hoặc dễ dàng có được.

— Giàn khoan

4

Tôi cũng nghi ngờ rằng hầu hết các JVM đều nhanh hơn nhiều so với các trình thông dịch của python.

— Peter Smith

19

Bằng cách nhắm mục tiêu mã byte Java, bạn có được tất cả các tính năng của JVM (bảo mật, hiệu năng, tính di động, khả năng mở rộng, v.v.). Nhắm mục tiêu Python bytecode không giúp bạn có được nhiều.

— David Schwartz

3

Python bytecode không được nhận dạng bởi các phiên bản sau của trình thông dịch Python. Làm thế nào bất cứ ai cũng có thể thực hiện một ngôn ngữ lập trình biên dịch sang mã byte Python?

— Gus

77

Đơn giản - lần trước tôi đã kiểm tra, Python không có đặc tả chính thức, bao gồm cả mã byte. CPython là thông số kỹ thuật và tính di động của mã byte là IIRC không bắt buộc. Do đó, đây là mục tiêu di động, không có giấy tờ được thiết kế cho một ngôn ngữ cụ thể.

— p_l
nguồn

22

Trên thực tế, các chi tiết của định dạng mã byte thường thay đổi giữa các phiên bản nhỏ và thậm chí PyPy tương thích 99% thậm chí không thử (trên thực tế, họ thêm các hướng dẫn mã byte riêng).

Lưu ý: Python - ngôn ngữ-- có thông số chính thức (xem phần "PEP"). 'Máy ảo Python' thì không. Điều này thực sự không giống (ví dụ) Java, trong đó cả hai đều được chỉ định.

— Albert

56

Có nhiều ngôn ngữ JVM vì có những người tài năng muốn viết mã sẽ hoạt động với mã Java hiện có, nhưng họ không muốn viết Java .

Rõ ràng không có lập trình viên nào muốn làm việc với mã Python hiện có, nhưng ghét Python đủ để chuyển một ngôn ngữ khác sang trình thông dịch mã byte của Python.

Bạn có thể xem xét điều này theo hai cách: có các ngôn ngữ thay thế cho JVM vì Java rất phổ biến hoặc không có ngôn ngữ thay thế nào cho trình thông dịch mã byte của Python vì Python không hút.

— kevin cline
nguồn

7

Tôi hy vọng bạn không ngụ ý rằng Java hút hoặc Java hút nhiều hơn Python :-)

— Giorgio

8

@Giorgio: Tôi đang ám chỉ rằng những người tạo ra Groovy, Scala, Clojure, v.v. nghĩ rằng có nhiều chỗ để cải thiện. Bạn đang ám chỉ rằng Python hút?

— kevin cline

8

Sau khi làm việc với python tôi sẽ nói "hệ số hút thấp" sẽ không chính xác. Nó chi trả quá nhiều thứ thường được chấp nhận và toàn bộ điều 'tự' là cực kỳ phản tác dụng. Trong thực tế câm. Làm thế nào không một phương thức lớp biết nó thuộc về đâu?

— Giàn

6

@Rig Cá nhân, tôi nghĩ cách tiếp cận của Python thanh lịch hơn. OO tuân theo một cách hữu cơ từ cú pháp thay vì yêu cầu một từ khóa đặc biệt trông giống như một biến. Về lý do tại sao các phương thức lớp không biết chúng ở đâu, đó là vì các định nghĩa lớp Python chỉ là mã và mã này không được bảo mật bởi vì nó nằm trong một định nghĩa lớp. Bạn có thể định nghĩa các phương thức ở bất cứ đâu và thêm chúng vào một lớp khi chạy. Trong thực tế, bạn có thể thực hiện cùng một chức năng và sử dụng nó như một phương thức trong nhiều lớp, một cái gì đó sẽ không thực sự hoạt động với thismô hình.

— Antimon

6

Tôi nghĩ đó là vấn đề của máy ảo chứ không phải ngôn ngữ. JVM là một VM hoạt động với trình thu gom rác thế hệ, JIT, v.v. Trong khi CPython sử dụng tính năng tham chiếu và là một trình thông dịch. Đó là CPython hút như một plataform. Hy sinh Btw tồn tại.

— PuercoPop

26

Có những thiếu sót về kỹ thuật như GIL trong CPython, nhưng rất ít thiếu sót về ngôn ngữ , vì vậy thời gian chạy không phải là điểm bán hàng của cộng đồng Python. Chính xác thì ngược lại, có nhiều tùy chọn thời gian chạy phụ trợ hơn do không hài lòng với việc triển khai GIL / CPython.

Ngôn ngữ Java sai hơn nhiều so với JVM (ngay cả trong cộng đồng Java).

JVM được đánh giá khá tốt trong hầu hết các vòng tròn; do đó, mong muốn về mặt trước ngôn ngữ khác biệt / tốt hơn kết thúc với các lợi ích của JVM back end được tối ưu hóa cao.

10

Tôi nói rằng Mason Wheeler đã đúng. Đây chủ yếu là một vấn đề với Khóa phiên dịch toàn cầu khiến cho vấn đề đồng thời trở thành một vấn đề rất nhức nhối. Vì có những máy ảo khác thực hiện đồng thời thực sự thực sự tốt, nên việc phát triển ngôn ngữ cho những máy đó là điều hợp lý. Ngoài ra Python gần đây đã có một sự thay đổi ngôn ngữ lớn và nhiều thư viện đã không bắt kịp khiến khả năng tương thích trở thành một cơn ác mộng nhẹ. Chẳng hạn, vì tôi sử dụng PIL cho công việc tầm nhìn, tôi phải viết mã bằng Python 2.7 trở xuống. Đây không phải là trường hợp với các thiết lập JVM hoặc CLI, đặc biệt trong trường hợp sau được thiết kế với ngôn ngữ xen kẽ.

Đã làm một số nghiên cứu thêm và rõ ràng thực sự có hai GIL không chỉ là một. Các điều khiển khác Nhập khẩu .

— Kỹ sư thế giới
nguồn

1

"GIL free" là một trong những lý do kỹ thuật được đề cập trên "Lý do mà các lập trình viên CPython có thể quan tâm đến IronPython" trong wiki Python .

— yannis

1

@YannisRizos: Chắc chắn quyền truy cập vào .NET framework không hoàn toàn không quan trọng. Tất nhiên, có thể người dùng CPython có thể hoàn toàn không quan tâm đến điều đó.

— Robert Harvey

@RobertHarvey Ninja đã chỉnh sửa điều đó. Mặc dù tôi không nghĩ rằng "truy cập vào đồ chơi mới lạ mắt" là một lý do kỹ thuật (không phải là đồ chơi không tuyệt vời), wiki cũng đề cập rằng IronPython dễ dàng mở rộng hơn.

— yannis

8

Các câu trả lời khác có rất nhiều ý nghĩa, nhưng thực sự có những ngôn ngữ hiện đang biên dịch thành Python. Nơi nào có ý chí ...

Tôi không biết gì về các ngôn ngữ này, nhưng chúng dường như hoạt động bằng cách dịch mã nguồn của chúng sang Python AST và để Python biên dịch cây thành mã byte, tránh các vấn đề được đề cập trong các câu trả lời khác.

Dựa trên các nhận xét, chúng tôi hiện biết ba ngôn ngữ thay thế sử dụng Python VM (vui lòng thêm bất kỳ ngôn ngữ nào khác vào đây):

Mochi Mô tả chính nó như một ngôn ngữ lập trình được gõ động cho lập trình chức năng và lập trình theo kiểu diễn viên .
Hy : Mô tả chính nó như một phương ngữ của Lisp được nhúng trong Python .
dg : Mô tả chính nó như một ngôn ngữ đơn giản (về mặt kỹ thuật) biên dịch thành mã byte CPython .

— Carl Smith
nguồn

2

Cũng đáng đề cập đến HyLang

— ideaman42

1

Và dg .

— hakatashi

6

Một lý do khác là JVM được tối ưu hóa cao, phát triển tốt và hệ sinh thái cực kỳ hoàn chỉnh. Về bản thân, nó cạnh tranh cực kỳ tốt với bất kỳ ngôn ngữ được biên dịch nào khác. (Tôi sẽ không nói rằng đó là VM có mục đích chung tốt nhất ngoài kia, nhưng tôi chắc chắn đã đánh dấu sự nghiệp của mình vào điều đó.) Vì vậy, việc truy cập vào JVM, viết tắt mã byte, là điều đáng mong đợi.

Tuy nhiên, Python VM là tốt, nhưng (không có gì chống lại Python) có một số thiếu sót nghiêm trọng. Môi trường thời gian chạy Python phù hợp với tính chất động của ngôn ngữ, nhưng thực sự có thể làm bạn ngạc nhiên khi bạn làm quen với việc sử dụng bộ nhớ, khóa toàn cầu hoặc mô hình luồng.

Trong các so sánh trực tiếp, JVM thường nhanh gấp đôi so với Python VM. JVM (surprizingly) thậm chí cạnh tranh tốt với mã được biên dịch nguyên gốc, dựa trên các tối ưu hóa "nóng" mà nó thực hiện. Và đó thậm chí còn không tính đến việc xử lý luồng tinh vi hơn, v.v.

Tôi yêu Python, tôi thực sự làm và ghét nói điều đó, nhưng đôi khi hiệu suất chỉ làm tôi khó chịu - nếu không, tại sao các thư viện Python quan trọng như numpy hay scipy lại phải rơi vào mã C?

Nói cách khác, những người hấp dẫn Python làm như vậy vì họ thích ngôn ngữ này . Nhưng nếu bạn muốn viết một ngôn ngữ hoàn toàn mới phù hợp với sở thích của mình, tốt hơn hết bạn nên biên dịch sang JVM, bởi vì ngôn ngữ bình dị mới của bạn sẽ bắt đầu ở một trong những môi trường hoạt động tốt nhất (chủ quan, có thể là tốt nhất).

— Cướp
nguồn