3 điểm bởi GN⁺ 2024-09-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Hy 1.0.0, một phương ngữ Lisp được nhúng vào Python, đã được phát hành sau khoảng 12 năm phát triển gián đoạn và sử dụng thực tế
  • Trong Hy 1.x, các thay đổi phá vỡ tương thích đối với các thành phần ngôn ngữ đã được tài liệu hóa sẽ dẫn đến việc tăng phiên bản major; ngoại lệ là việc ngừng hỗ trợ các phiên bản Python mà nhà phát triển CPython không còn hỗ trợ nữa
  • Trọng tâm sắp tới là sửa lỗi mới, bổ sung tương thích với các phiên bản Python mới, và hỗ trợ các tính năng Python mới theo cách không làm hỏng mã Hy 1.x.y hiện có
  • Một người dùng đưa ra ví dụ dùng macro Hy để rút gọn khai báo SQLAlchemy ORM thành dạng defmodel, và giải thích rằng do đây là mở rộng macro nên không có chi phí runtime bổ sung
  • Việc chạy trực tiếp trên MicroPython có vẻ khó khăn do chỉ có một tập con của thư viện chuẩn; tuy vậy, cách chuyển đổi từ CPython bằng hy2py rồi chỉ dùng các thành phần mà MicroPython hỗ trợ có thể khả thi

Phát hành Hy 1.0.0

  • Hy 1.0.0 đã được phát hành
    • Hy là một phương ngữ Lisp được nhúng vào Python
    • Trước khi phát hành, dự án đã có gần 12 năm phát triển gián đoạn và nhiều ứng dụng thực tế
  • Phần giới thiệu và tài liệu có tại Hylang.org
  • Lịch sử phiên bản có thể xem trong NEWS file
  • Một bài viết liên quan đến bản phát hành theo phong cách bớt nghiêm túc hơn cũng được đính kèm: HYPE POST

Chính sách tương thích 1.x

  • Từ nay, các breaking change trong phần ngôn ngữ đã được tài liệu hóa sẽ làm tăng số phiên bản major
  • Ngoại lệ là trường hợp ngừng hỗ trợ các phiên bản Python mà nhà phát triển CPython không còn hỗ trợ nữa
  • Mục tiêu được nêu ra là tránh để việc tăng phiên bản major xảy ra quá thường xuyên
  • Trọng tâm công việc sắp tới là:
    • sửa lỗi mới phát sinh
    • bổ sung tương thích với các phiên bản Python mới
    • hỗ trợ các tính năng Python mới theo cách không làm hỏng mã đang chạy trên Hy 1.x.y trước đó

Ví dụ ứng dụng macro Hy: DSL mô hình SQLAlchemy

  • Một người dùng cho biết họ đang xây dựng ORM và framework web bất đồng bộ bằng Hy; cả hai đều tận dụng các thư viện hiện có và phần lớn được cấu thành từ macro
  • Một ví dụ được đưa ra cho thấy có thể biểu diễn khai báo mô hình trong SQLAlchemy ORM Quick Start Guide ngắn gọn hơn bằng macro defmodel của Hy
    • Các mô hình User, Address và khai báo quan hệ được viết theo dạng Hy S-expression
    • defmodel là macro mở rộng thành mã SQLAlchemy nên không có chi phí runtime bổ sung
  • Người dùng nói rằng sự ổn định của phần nội bộ và API của Hy là điều cần thiết cho kiểu công việc này

Thảo luận về khai báo quan hệ và DSL truy vấn

  • Ví dụ defmodel được mở rộng ra nhiều mẫu quan hệ khác nhau
    • one-to-one: 1->1
    • many-to-many: *->*deflinktable
    • trường timestamp: :timestamp-create, :timestamp-update
  • Sau khi khai báo, các đối tượng vẫn là đối tượng ORM SQLAlchemy 2.0 thông thường, nên có thể chỉ dùng Hy cho phần DSL lược đồ cơ sở dữ liệu và dùng Python cho phần còn lại
  • DSL truy vấn vẫn đang được xây dựng, và có đề cập rằng fluent interface không thực sự phù hợp với S-expression
  • Một bình luận đề xuất nên thiết kế sao cho thứ tự cú pháp và thứ tự ngữ nghĩa của SQL khớp nhau, đồng thời dẫn tới bài của Google Research: SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL
  • Đáp lại, tác giả cho biết các dạng như |> hoặc cách mô phỏng list comprehension có thể khả thi, nhưng thiết kế cuối cùng có lẽ sẽ xuất hiện sau nhiều vòng xây dựng ứng dụng nhỏ rồi refactor lặp lại

Khả năng với MicroPython và phản ứng với bản phát hành

  • Có câu hỏi liệu nó có thể chạy trên MicroPython thay cho CPython hay không
  • Câu trả lời nghiêng về việc điều đó khó khả thi khi chạy trực tiếp, vì MicroPython chỉ bao gồm một tập con nhỏ của thư viện chuẩn Python
  • Tuy nhiên, nếu dùng hy2py trên CPython để chuyển đổi sang mã Python rồi giới hạn trong các thành phần mà MicroPython hỗ trợ, thì có thể chạy được đầu ra đó
  • Cũng ghi nhận rằng trong ngày phát hành, số lượng khách truy cập duy nhất hằng ngày vào máy chủ web đang lưu trữ Hylang.org đã tăng mạnh

1 bình luận

 
GN⁺ 2024-09-23
Ý kiến trên Hacker News
  • Ban đầu hơi khó nắm được Hy thực sự được chuyển đổi sang Python như thế nào, và cũng chưa chắc nó được biên dịch hay thông dịch
    Cuối cùng tôi tìm thấy trên Wikipedia mô tả rằng “Hy là một phương ngữ Lisp được thiết kế để tương tác với Python bằng cách chuyển s-expression thành cây cú pháp trừu tượng (AST) của Python”, và nhìn vào mã trên GitHub thì có vẻ compiler cũng được viết bằng Python: https://github.com/hylang/hy/blob/master/hy/compiler.py
    Có lẽ trên trang chính cũng sẽ rõ ràng hơn nếu giới thiệu là “một phương ngữ Lisp được biên dịch thành Python AST” thay vì “một phương ngữ Lisp nhúng trong Python”. Có nhiều cách nhúng Lisp, như gắn thêm interpreter, biên dịch sang bytecode Python, hoặc chuyển đổi thành mã nguồn Python, và mỗi cách có những đánh đổi khá khác nhau

    • Trên trang README/GitHub đã ghi rằng “Hy là một phương ngữ Lisp nhúng trong Python, chuyển mã Lisp thành đối tượng AST của Python, nhờ đó có thể dùng thế giới Python dưới dạng Lisp”
    • Đúng vậy, compiler này được viết bằng Python và Hy không tự host
      Thông thường mã nguồn Hy trở thành đối tượng AST của Python, rồi Python biên dịch và chạy nó. Tuy nhiên cũng có thể chuyển đối tượng AST của Python thành văn bản mã nguồn Python, và cũng có thể tương tác hai chiều: dùng Python trong Hy hoặc dùng Hy trong Python: https://hylang.org/hy/doc/v1.0.0/interop
    • Cách gọi “nhúng” xuất phát từ việc trong cùng một dự án có thể trộn Python và Hy, đồng thời gọi qua lại hai chiều
      Cuối cùng tất cả đều trở thành bytecode Python nên hoạt động tốt
    • Trong bài giới thiệu Hy ban đầu, điểm Lisp được biên dịch thành bytecode Python để nhúng đã được nêu rõ
      Có thể xem khoảng phút 16:25 trong video dưới đây: https://m.youtube.com/watch?v=1vui-LupKJI
  • Khi Hy trưởng thành qua nhiều năm, thay vì tích lũy cú pháp đường và các trường hợp đặc biệt để trở nên “Lispy” hơn và bớt “Pythony” hơn, có vẻ nó lại tiến gần hơn tới một lớp trừu tượng cú pháp mỏng trên tập tính năng của Python
    Nói cách khác, nó tập trung vào phần cốt lõi khó bắt chước bằng cách khác, đặc biệt là macro. Ví dụ gần đây, match chỉ là match native của Python và không có polyfill cho các phiên bản trước Python 3.10. Trước đây foo? từng là trường hợp đặc biệt được mangle thành is_foo, nhưng đã bị loại bỏ; hy.eval được chỉnh lại để gần với eval của Python hơn; còn các tiện ích không cốt lõi nhưng tiện lợi như unless thường bị đẩy sang gói Hyrule
    Lúc đầu hướng đi này có vẻ trái trực giác, nhưng lợi ích lớn là giảm đường cong học tập khi chuyển từ Python sang Hy và giúp tương tác nhất quán hơn với các gói Python. Có lẽ cũng có lý do là đơn giản hóa việc bảo trì ngôn ngữ; nếu nhớ không nhầm thì let cũng đã phải thử khoảng bốn lần mới làm cho đúng

    • Đến một lúc nào đó tôi nhận ra rằng nếu giảm thiểu những khác biệt không cần thiết với Python thì cả việc bảo trì lẫn sử dụng ngôn ngữ đều trơn tru hơn nhiều
      Khi viết mã Hy, tôi cũng thường xem tài liệu Python hoặc tài liệu của thư viện Python bên thứ ba nhiều hơn hẳn tài liệu Hy. Tôi cảm thấy có nhiều điểm có thể cải thiện Python, nhưng những tính năng như cho phép viết True thành true vì cân nhắc đến Clojure như trước đây chỉ là sự phức tạp không cần thiết
  • Bài HYPE POST thật sự rất hay. Với tư cách một người làm phần mềm doanh nghiệp, tôi thấy cảm quan châm biếm của nó rất xuất sắc
    https://github.com/hylang/hy/discussions/2609

  • Cuối cùng nó cũng ra mắt, nên giờ có thể dọn dẹp https://github.com/rcarmo/sushy được rồi
    Tôi đã mày mò nó từng chút một trong vài năm, nhưng mỗi lần nâng cấp Hy lại có một phần cú pháp bị vỡ, hoặc tính năng chuyển vào rồi lại ra khỏi gói Hyrule, khá phiền
    Nhân tiện, Hy cũng chạy khá tốt bên trong https://holzschu.github.io/a-Shell_iOS trên iPad. Tuy vậy, tô sáng cú pháp của vim/neovim cần bắt kịp các bản phát hành 0.29+ và async
    Tôi cũng đã thử Fennel và Guile trong thời gian đó, nhưng vẫn thích phía có thể truy cập thư viện và hệ sinh thái Python hơn. Nhờ async, làm việc với API hiệu quả cũng tốt; trong nhiều Scheme, việc xử lý HTTPS với khả năng tái sử dụng socket và kiểm soát chi tiết header vẫn còn rườm rà, nên tôi thấy dùng aiohttp tốt hơn nhiều

  • So với điểm khởi đầu giản dị ban đầu thì nó đã đi rất xa
    Trước đây tôi từng xem lightning talk giới thiệu Hy ra thế giới lần đầu ở PyCon, và không lâu sau đó gặp Paul rồi bắt đầu đóng góp cho các phiên bản Hy đầu tiên. Tôi phụ trách kwargs kiểu Common Lisp, một số phần nội bộ, và một hai thư viện
    Tinh thần nghịch ngợm là hữu ích, đặc biệt là giúp duy trì nhiệt huyết. Tôi thích việc hacker có thể hành xử đúng chất hacker và không phải mọi thứ đều cần là kinh doanh. Dù đã không tham gia vài năm rồi, tôi vẫn thấy vui khi dự án tiếp tục tiến lên, và cảm thấy đây là một cột mốc tuyệt vời

  • Nếu là fan Clojure, liên quan đến chủ đề này còn có Basilisp, một phương ngữ Lisp gần tương thích với Clojure, nhắm tới Python 3.8+
    https://github.com/basilisp-lang/basilisp

  • Dù không phải Lisp, từ góc nhìn là một ngôn ngữ lập trình hàm được transpile sang Python thì Coconut cũng thú vị: https://coconut-lang.org/
    Thật sự rất muốn nghe trải nghiệm của những người đã dùng Hy hoặc Coconut trong thực tế

    • Vài năm trước tôi có dùng thử Coconut một chút, và ấn tượng khi đó là compiler chưa đủ thông minh để hữu ích
      Phía trên cùng của mã được sinh ra bị gắn cả đống hàm trợ giúp hard-code, và chương trình chậm hơn nhiều so với khi viết cùng nội dung bằng Python bình thường
      Ngược lại, Hy sinh ra mã khá gần với mã Python mà con người có thể tự viết, ngoại trừ một chút tầng gián tiếp do xử lý scope của let hoặc khác biệt quanh giá trị trả về. Tuy vậy, Coconut cũng đã qua khá lâu rồi nên có thể đã được cải thiện
  • Chúc mừng. Tôi tò mò hai điều: liệu có hỗ trợ phát triển dựa trên REPL không, ví dụ có những thứ như condition system hay breakloop không
    Ngoài ra cũng muốn biết có bản phân phối chạy độc lập không. Vì việc phân phối Python tự nó đã phiền phức, lý tưởng nhất là có thể phân phối một binary Hy duy nhất gồm tất cả dependency. Static link hay file zip giải nén vào thư mục tạm đều được

    • Không phải bản phân phối chạy độc lập, nhưng có thể vào Hy REPL bằng uvx hy@1.0.0
      Sau echo '(print "hi hn")' > hi.hy, chạy uvx hy@1.0.0 hi.hy thì sẽ in ra "hi hn"
      https://docs.astral.sh/uv/guides/tools/#running-tools
      Nhân tiện, uv cũng có thể cài đặt và quản lý phiên bản Python
    • Tôi không rõ breakloop là gì. Hy dùng hệ thống exception của Python, hệ thống này gần với exception system truyền thống hơn là condition system của Common Lisp
      Không có bản phân phối chạy độc lập
    • Tài liệu REPL có nội dung liên quan: https://hylang.org/hy/doc/v1.0.0/repl
      Để debug mã theo kiểu tương tác, bạn có thể đặt (.run (hy.REPL :locals {#\* (globals) #\* (locals)})) vào đoạn mã muốn debug, còn trong Python có thể dùng như import hy; hy.REPL(locals = {\*globals(), \*locals()}).run()
      Tuy nhiên, cũng như code.interact(), nếu bạn thay đổi biến cục bộ bên trong REPL thì thay đổi đó sẽ không được truyền ngược về scope ban đầu
    • Tôi từng làm một thứ gần với mục 2 bằng py2app và một ít hack cẩn thận
      Có thể compile tất cả thành bytecode rồi dùng công cụ phân phối một file của Python
    • Hy hỗ trợ nguyên bộ tính năng mà Python hỗ trợ. Nó khá tốt cho debug từng bước truyền thống hoặc debug hậu kỳ, và CPython cũng có nhiều hook nội bộ nâng cao hơn
      Nhưng không có những thứ như condition system hay handlers/restarts
  • Tôi rất thích phần bớt nghiêm túc. Ước gì nhiều dự án lập trình hơn chấp nhận sự tinh nghịch
    Có lẽ đó cũng là cách tốt nhất để tôn vinh truyền thống Python

    • Vài năm trước, Hy và tài liệu đã loại bỏ khá nhiều yếu tố đùa vui. Vì chúng gây xao nhãng và tạo ra các lỗi test ồn ào
      Tuy nhiên, đến một lúc nào đó tôi thấy mình đã đi quá xa, nên gần đây đang cố đưa chút tinh nghịch trở lại
  • Tôi đã dùng Hy không thường xuyên, và khi thử tạo transformer, tôi cũng đã công bố https://github.com/kunalb/orphism viết bằng Hy
    Có lẽ giờ là lúc lôi nó ra lại và chạy cho đàng hoàng