Một dự án trình thông dịch LISP đơn giản đã bất ngờ châm ngòi cho một cuộc tranh luận kỹ thuật gay gắt về hành vi không xác định trong ngôn ngữ lập trình Odin . Dự án có tên komplott , trình diễn một triển khai LISP tối giản bằng cả C và Odin , nhưng cuộc thảo luận nhanh chóng chuyển từ sự đơn giản thanh lịch của LISP sang những câu hỏi cơ bản về an toàn bộ nhớ và triết lý thiết kế ngôn ngữ.
So sánh triển khai LISP
Tính năng | Phiên bản C (komplott.c) | Phiên bản Odin (komplodin.odin) |
---|---|---|
Số dòng code | ~500 dòng | ~600 dòng |
Số lượng file | File đơn | File đơn |
Garbage Collector | Copying semi-space ( Cheney's Algorithm ) | Copying semi-space ( Cheney's Algorithm ) |
Tối ưu hóa Tail Call | TCO hạn chế | TCO hạn chế |
Xử lý lỗi | Gần như không có | Gần như không có |
Thread Safety | Không có | Không có |
Tranh cãi về hành vi không xác định
Tranh chấp trung tâm xoay quanh tuyên bố của Ginger Bill , người tạo ra Odin , rằng ngôn ngữ này không có hành vi không xác định. Những người chỉ trích cho rằng điều này gây hiểu lầm, chỉ ra các ví dụ cụ thể nơi Odin thể hiện cùng những vấn đề an toàn bộ nhớ như C , đặc biệt là các tình huống sử dụng sau khi giải phóng. Một thành viên cộng đồng đã chứng minh rằng việc hủy một hash map và sau đó truy cập nó có thể tiết lộ nội dung từ các hash map hoàn toàn khác, tạo ra hành vi không thể dự đoán và có khả năng nguy hiểm.
Cuộc tranh luận làm nổi bật sự bất đồng cơ bản về thuật ngữ. Trong khi Odin có thể không khai thác hành vi không xác định để tối ưu hóa trình biên dịch như C , nó vẫn cho phép các chương trình đi vào trạng thái mà hành vi không được xác định bởi đặc tả ngôn ngữ. Cuộc tranh luận ngữ nghĩa này có những tác động thực tế đối với các nhà phát triển có thể cho rằng có những đảm bảo an toàn mạnh mẽ hơn so với những gì ngôn ngữ thực sự cung cấp.
Các tính năng của ngôn ngữ Odin so với C
- Không có hành vi không xác định (còn tranh cãi)
- Các kiểu dữ liệu chuỗi, mảng động và slice được tích hợp sẵn
- Kiểu map được tích hợp sẵn
- Kiểm tra giới hạn với tùy chọn phát hiện rò rỉ bộ nhớ
- Tagged unions với các câu lệnh switch đầy đủ
- Framework kiểm thử đơn vị được tích hợp sẵn
- Hỗ trợ toán học 3D với các phép toán swizzling và ma trận
- Cú pháp gán nhiều giá trị (giống Python)
- Phân biệt giữa phép gán (=) và khai báo (:=)
Căng thẳng cộng đồng nổi lên
Cuộc thảo luận kỹ thuật đã phơi bày những mối quan ngại sâu sắc hơn của cộng đồng về phong cách lãnh đạo của dự án Odin . Nhiều người tham gia báo cáo những trải nghiệm tiêu cực với cách tiếp cận giao tiếp của người tạo ra ngôn ngữ, mô tả những phản hồi thờ ơ đối với các đóng góp và pull request. Những lời kể này vẽ nên bức tranh về một người duy trì tài năng nhưng khó chịu, có thể đang cản trở sự phát triển cộng đồng thông qua phản hồi khắc nghiệt không cần thiết.
Tôi đóng PR này vì viết binding riêng sẽ nhanh hơn là giải thích mọi thứ sai trong đó và sau đó hy vọng chúng được sửa đúng cách.
Tranh cãi mở rộng ra ngoài các tương tác cá nhân đến những câu hỏi về quản trị dự án và trải nghiệm người đóng góp. Một số thành viên cộng đồng lưu ý rằng mặc dù công việc kỹ thuật ấn tượng, nhưng động lực xã hội xung quanh dự án tạo ra rào cản cho người mới và những người đóng góp tiềm năng.
Sức hấp dẫn bền bỉ của LISP
Bất chấp cuộc tranh luận gay gắt, dự án trình thông dịch LISP gốc cho thấy tại sao ngôn ngữ này vẫn hấp dẫn các lập trình viên. Việc triển khai chỉ cần ít hơn 500 dòng code trong C , thể hiện sự thanh lịch toán học và yêu cầu cốt lõi tối thiểu của LISP . Sự đơn giản xuất phát từ cú pháp thống nhất của LISP sử dụng s-expression và nhu cầu chỉ ba dạng đặc biệt thiết yếu: quote, cond và lambda.
Dự án bao gồm cả trình thông dịch giống Scheme hiện đại và một triển khai trung thành của LISP 1.5 từ năm 1962, hoàn chỉnh với bộ thu gom rác sao chép dựa trên Thuật toán Cheney . Kết nối lịch sử này minh họa cách các khái niệm khoa học máy tính cơ bản vẫn có liên quan qua nhiều thập kỷ tiến hóa công nghệ.
Tranh cãi xung quanh các tuyên bố hành vi không xác định của Odin phục vụ như lời nhắc nhở rằng độ chính xác kỹ thuật và giao tiếp rõ ràng là rất quan trọng trong phát triển ngôn ngữ lập trình. Trong khi các cuộc tranh luận ngữ nghĩa về thuật ngữ có thể có vẻ học thuật, chúng có hậu quả thực tế đối với kỳ vọng của nhà phát triển và an toàn code. Cộng đồng lập trình tiếp tục vật lộn với việc cân bằng đổi mới, an toàn và khả năng tiếp cận trong thiết kế ngôn ngữ.
Tham khảo: komplott / komplodin