Có cơ chế nào để làm cho ngôn ngữ lập trình ổn định hơn (tương thích) cho các thay đổi không?

Có một số lượng lớn các ngôn ngữ lập trình. Một số trong số họ lớn lên và trở nên rất phổ biến. Mọi người sử dụng ngôn ngữ như vậy ngày càng thường xuyên hơn. Người sáng lập ngôn ngữ đó (hoặc tổ chức / cộng đồng sáng lập) có thể cố gắng thực hiện các thay đổi để làm cho ngôn ngữ tốt hơn. Nhưng đôi khi thật khó để thực hiện một số thay đổi vì khả năng tương thích ngược và những thứ xấu xí như vậy đã tồn tại trong ngôn ngữ trong nhiều năm và được nhiều người dùng sử dụng.

Có bất kỳ nguyên tắc hoặc bước kiến ​​trúc nào, trong giai đoạn thiết kế ngôn ngữ, có thể giúp làm cho nó ổn định hơn để các nhà thiết kế ngôn ngữ sẽ không sợ phá vỡ khả năng tương thích ngược?

Ổn định ngôn ngữ không phải là một quyết định kỹ thuật. Đó là một hợp đồng giữa tác giả ngôn ngữ và người dùng.

Tác giả quảng cáo một phiên bản nhất định là ít nhiều ổn định. Một ngôn ngữ càng kém ổn định, tác giả có thể thực hiện càng nhiều thay đổi. Mỗi người dùng quan tâm đến ngôn ngữ có thể quyết định xem anh ta có muốn đầu tư thời gian vào đó để tìm hiểu các tính năng mới hoặc phát triển các ứng dụng có thể bị phá vỡ bởi bản cập nhật vào tháng tới.

Sử dụng một ngôn ngữ không ổn định có thể thú vị bởi vì bạn quan tâm đến một khái niệm mới hoặc bạn muốn giúp đỡ bằng cách đưa ra phản hồi của bạn. Nếu bạn là một doanh nghiệp, bạn có thể muốn đợi một công nghệ ổn định hơn trước khi đầu tư thời gian vào đó. Bạn quan tâm nhiều hơn đến những thứ như thời gian để tiếp thị và trải nghiệm người dùng.

Vì vậy, đây là một vấn đề truyền thông và niềm tin. Nhìn vào sự phát triển ngôn ngữ rỉ sét. Họ rất rõ ràng về những gì họ đang thay đổi và những gì họ đang giữ. Khi họ muốn trì hoãn quyết định về một tính năng nhất định, họ sử dụng cái mà họ gọi là cổng tính năng. Mặt khác, nhóm nghiên cứu góc cạnh phải đối mặt với rất nhiều sự tức giận về thông báo 2.0 của họ vì những thay đổi lớn hơn dự kiến.

Ngay cả các tác giả thư viện phải truyền đạt về sự ổn định của apis của họ. Khá nhiều công nghệ mà người khác sử dụng phải đạt được sự cân bằng giữa sự ổn định và hoàn hảo. Nhà sản xuất ô tô không thể thay đổi vị trí bàn đạp và nhà thiết kế máy tính xách tay sẽ không phát minh ra bố cục bàn phím mới vì lý do tương tự: bạn không giúp đỡ người dùng nếu bạn không thể đưa ra quyết định về cách họ sẽ sử dụng sản phẩm của bạn.

• Xin lưu ý rằng các ngôn ngữ thay đổi trong suốt cuộc đời của chúng, bất kể nó có thể được thiết kế tốt như thế nào. Thay vì cố gắng vận chuyển ngay ngôn ngữ tuyệt vời nhất trên trái đất, trước tiên hãy cố gắng trở nên hữu ích và có thể mở rộng. Một ngôn ngữ tầm thường mà tôi thực sự có thể sử dụng có giá trị hơn bất kỳ ngôn ngữ lập trình tuyệt vời nào chỉ tồn tại trong lý thuyết.

• Xem xét các phương tiện để làm cho cú pháp có thể mở rộng, ví dụ như macro. Macro không tự động là một điều tốt và có thể quá mạnh mẽ. Một số ngôn ngữ có cú pháp rất linh hoạt ngay từ đầu, giúp giảm nhu cầu về macro. Một vài kịch bản để xem xét:

  • Tôi có thể giới thiệu một toán tử mới như |>không rời ngôn ngữ không? Tôi có thể chọn quyền ưu tiên và kết hợp cho toán tử này không?
  • Tôi phải trải qua bao nhiêu buổi lễ cho một chức năng nội tuyến / lambda / đóng cửa?
  • Tôi có thể sử dụng cú pháp ngôn ngữ hiện có để thực hiện cú pháp vòng lặp foreach không? Ví dụ: Ruby và Scala có thể thực hiện điều này thông qua cú pháp gọi phương thức linh hoạt của họ với lambdas.

• Xem xét các cơ sở để giữ cho ngữ nghĩa mở rộng. Nhu cầu chung là:

  • Quá tải toán tử, trong đó các kiểu do người dùng định nghĩa có thể gán ý nghĩa riêng của chúng cho các toán tử hiện có. Điều này làm cho một ngôn ngữ thú vị hơn nhiều trong các ứng dụng nặng về toán học.
  • Nghĩa đen quá tải. Tôi có thể làm cho chuỗi ký tự là loại chuỗi của riêng tôi không? Tôi có thể làm cho tất cả các chữ số trong phạm vi hiện tại là bignums không?
  • Giao thức Metaobject. Nếu ngôn ngữ không có đặc điểm, tôi có thể triển khai chúng trong hệ thống đối tượng hiện tại không? Tôi có thể thực hiện một thứ tự giải quyết phương pháp khác nhau không? Tôi có thể trao đổi cách lưu trữ các đối tượng hoặc cách gửi phương thức không?
• Có bài kiểm tra hồi quy. Rất nhiều bài kiểm tra. Không chỉ được viết bởi các nhà thiết kế ngôn ngữ, mà còn bởi người dùng. Khi thêm một tính năng phá vỡ các thử nghiệm này, hãy cân nhắc cẩn thận lợi ích của tính năng đó với lợi ích của khả năng tương thích ngược.
• Phiên bản ngôn ngữ của bạn. Không chỉ trong tài liệu của bạn, mà còn trong chính mã nguồn. Khi bạn làm điều đó, phần duy nhất trong ngôn ngữ của bạn không thể thay đổi là cú pháp pragma phiên bản này. Ví dụ: Vợt cho phép bạn chỉ định một phương ngữ. Perl cho phép bạn use v5.20, cho phép tất cả các tính năng không tương thích ngược của Perl v5.20. Bạn cũng có thể tải các tính năng duy nhất rõ ràng như thế nào use feature 'state'. Tương tự: Python's from __future__ import division.
• Xem xét việc thiết kế ngôn ngữ của bạn theo cách dẫn đến một vài từ dành riêng. Chỉ vì classgiới thiệu một lớp không có nghĩa là tôi sẽ không thể có một biến cục bộ được đặt tên class. Trong thực tế, điều này dẫn đến các từ khóa giới thiệu các khai báo biến hoặc phương thức, đối nghịch với truyền thống giống như C sử dụng tên loại để giới thiệu khai báo. Một lựa chọn khác là sử dụng sigils cho bạn $variables, như trong Perl và PHP.

Các phần của câu trả lời này bị ảnh hưởng bởi bài phát biểu của Guy Steele, Phát triển ngôn ngữ (1998) ( pdf ) ( youtube ).

Tôi nghĩ rằng một bước khá quan trọng là thúc đẩy một trình quản lý gói mà cũng có thể tự quản lý phiên bản của ngôn ngữ.

Chẳng hạn, tôi sử dụng SBT cho Scala hoặc Leiningen cho Clojure. Cả hai đều cho phép tôi khai báo phiên bản ngôn ngữ nào tôi muốn sử dụng cho mỗi dự án . Vì vậy, khá dễ dàng để bắt đầu các dự án xanh trong phiên bản mới nhất của ngôn ngữ, đồng thời nâng cấp các dự án hiện tại với tốc độ thoải mái hơn, nếu có.

Tất nhiên, tùy thuộc vào ngôn ngữ, điều này vẫn có thể khiến bạn phải chờ các thư viện có liên quan được chuyển sang phiên bản bạn cần (ví dụ, điều này xảy ra trong Scala), nhưng vẫn giúp mọi việc dễ dàng hơn.