Vấn đề của triển khai thay thế (Alternative Implementation Problem)

 (pointersgonewild.com)
2 điểm bởi GN⁺ 2024-05-13 | 1 bình luận | Chia sẻ qua WhatsApp

Vấn đề của triển khai thay thế

Tác giả nói về vấn đề triển khai thay thế lặp đi lặp lại trong thế giới phần mềm. Kinh nghiệm của tác giả chủ yếu là tối ưu hóa các ngôn ngữ lập trình kiểu động.

  • Dự án PyPy đã phát triển một trình biên dịch JIT tiên tiến cho Python, nhưng trên thực tế hầu như không được sử dụng. Vì Python liên tục thay đổi khi bổ sung tính năng mới, nên PyPy khó có thể theo kịp.
  • LuaJIT được đánh giá rất cao, nhưng do ngôn ngữ Lua tiếp tục thêm các tính năng mới nên LuaJIT đang bị chậm hơn vài phiên bản.
  • TruffleRuby JIT từng cho thấy hiệu năng ấn tượng nhất, nhưng do thiếu khả năng tương thích tính năng so với CRuby nên chỉ được triển khai ở mức hạn chế.

Bài học: triển khai thay thế là một lựa chọn gần như tất yếu sẽ thất bại

  • Khi tạo ra một triển khai thay thế, bạn không thể tránh khỏi việc bị phụ thuộc vào những thay đổi của triển khai chính thức.
  • Triển khai chính thức kiểm soát hướng đi của dự án, còn triển khai thay thế chỉ có thể chạy theo.
  • Theo truyền thống, khi tạo một triển khai JIT cho ngôn ngữ thông dịch, việc thêm tính năng mới vào trình thông dịch nhanh hơn rất nhiều, vì vậy triển khai chính thức có thể vượt lên trước JIT.

YJIT: triển khai trình biên dịch JIT cho Ruby bên trong CRuby

  • YJIT cũng là một Ruby JIT khác, nhưng đã chọn được triển khai ngay bên trong chính CRuby.
  • Nhờ đó, YJIT có thể tương thích 100% với mọi tính năng của CRuby ngay từ đầu.
  • Hiện nay nó đã trở thành JIT chính thức của Ruby và đang được triển khai tại Shopify, Discourse, GitHub và nhiều nơi khác.

Bài học ở góc nhìn rộng hơn

  • Crystal, một ngôn ngữ tương tự ngôn ngữ hiện có nhưng không tương thích, cũng chỉ đạt được thành công hạn chế.
  • Việc trông giống ngôn ngữ hiện có nhưng lại không tương thích chỉ khiến mọi người bối rối.
  • Khi tạo ra một ngôn ngữ lập trình mới, tốt hơn là không nên cố trở thành một tập con của ngôn ngữ hiện có mà hãy đi con đường riêng của mình.
  • Có như vậy, nó mới có thể tiến hóa theo tốc độ và định hướng riêng mà không bị ràng buộc bởi hiệu năng, tính năng hay thư viện của triển khai khác.

Ý kiến của GN⁺

  • “Vấn đề triển khai thay thế” được mô tả trong bài viết này là điều cần lưu ý không chỉ với ngôn ngữ lập trình mà còn khi xây dựng nhiều loại hệ thống phần mềm và phần cứng khác nhau.
  • Nếu chỉ chú trọng vào tính ổn định và khả năng tương thích thì đổi mới có thể trở nên khó khăn. Tuy nhiên, từ góc nhìn người dùng thực tế, khả năng tương thích là một yếu tố rất quan trọng. Điều quan trọng là phải cân bằng giữa công nghệ mới và tính thân thiện với người dùng.
  • Ở góc nhìn dài hạn, cần suy nghĩ kỹ rằng một dự án mới sẽ “tương thích với ai” và “sẽ tiến hóa theo hướng nào”.
  • Khi tạo ra một ngôn ngữ lập trình mới, việc chỉ làm cho cú pháp giống ngôn ngữ hiện có sẽ càng làm tăng thêm sự nhầm lẫn. Thay vào đó, nên làm rõ triết lý và định hướng riêng của mình.
  • Có vẻ như về lâu dài, việc đưa ra các giải pháp sáng tạo và độc đáo thay vì cạnh tranh trực diện trên thị trường sẽ có khả năng thành công cao hơn.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-13
Ý kiến trên Hacker News
  • Khi phát triển một triển khai thay thế mới, nếu nó có kiến trúc khác với phiên bản hiện có thì những việc dễ ở phiên bản cũ có thể trở nên rất khó ở phiên bản mới. Ví dụ, nếu phần mềm proprietary tải/lưu theo từng section còn phiên bản mới lại đưa toàn bộ tài liệu vào bộ nhớ, thì để hỗ trợ tính năng thêm tệp đính kèm có thể phải sửa toàn bộ kiến trúc của phiên bản mới.
  • Định vị mình như một phương án thay thế cho triển khai hiện có là một luận điểm dễ thua. Những dự án được tiếp thị là "Python + X" khó cạnh tranh với phiên bản chính thức. Nhưng nếu, như MicroPython, nó được thiết kế cho microcontroller và không cạnh tranh với CPython mà cạnh tranh với các môi trường lập trình microcontroller khác, thì có thể thành công.
  • Trái với tuyên bố về tính tương thích, trên thực tế nhiều trường hợp lại có mức tương thích thấp ngay cả với các tính năng ngôn ngữ cũ, và đây là lý do khiến các triển khai thay thế thất bại. Với Ruby và Python, ví dụ là việc thiếu hỗ trợ cho native C extension.
  • Theo kinh nghiệm khởi nghiệp startup, lẽ ra nên tập trung chứng minh rằng kiến trúc có thể hỗ trợ các tính năng dành cho doanh nghiệp, thay vì theo đuổi các chức năng cơ bản, và tập trung vào điều gì đó khác biệt.
  • Các nhà phát triển coi trọng tính năng ngôn ngữ và khả năng tương tác hơn JIT. Tạo dự án song song của riêng mình thì dễ hơn là đóng góp cho dự án hiện có, nhưng cần tự hỏi nó là vì ai. Cần cẩn thận để không rơi vào tự mãn.
  • Mã wrapper gây đau đầu vì lệch khỏi tiêu chuẩn và thiếu tài liệu. Tốt nhất chỉ thêm những tính năng thật sự cần thiết và dùng các giá trị mặc định.
  • Điều này tương tự với những vấn đề TiDB gặp phải vì tính tương thích MySQL. Về lý thuyết thì đó là một giao thức mở, nhưng trên thực tế Chrome là bên dẫn dắt.
  • Không có đề cập nào về Kotlin.