Làm thế nào một số cộng đồng ngôn ngữ (ví dụ: Ruby và Python) có thể ngăn chặn sự phân mảnh trong khi các cộng đồng khác (ví dụ: Lisp hoặc ML) thì không?

Thuật ngữ "Lisp" (hoặc "giống như Lisp") là một chiếc ô cho rất nhiều ngôn ngữ khác nhau, như Common Lisp, Scheme và Arc. Có sự phân mảnh tương tự trong các cộng đồng ngôn ngữ khác, như trong ML.

Tuy nhiên, Ruby và Python đều đã tránh được số phận này, nơi mà sự đổi mới xảy ra nhiều hơn khi triển khai (như PyPy hoặc YARV) thay vì tự thay đổi ngôn ngữ.

Có phải cộng đồng Ruby và Python đã làm điều gì đó đặc biệt để ngăn chặn sự phân mảnh ngôn ngữ?

Cả Ruby và Python đều có những kẻ độc tài nhân từ ở vị trí lãnh đạo của chúng. Họ là những ngôn ngữ bắt nguồn sâu sắc trong mối quan tâm thực dụng. Đó có lẽ là những yếu tố quan trọng nhất ức chế sự phân mảnh. Lisp và ML, mặt khác, giống như các ngôn ngữ "thiết kế bởi ủy ban", được hình thành trong giới học thuật, cho mục đích lý thuyết.

Lisp ban đầu được thiết kế bởi John McCarthy như một ký hiệu toán học thực tế cho các chương trình máy tính. Ông không bao giờ thực hiện nó như một ngôn ngữ lập trình thực tế; triển khai đầu tiên được phát triển bởi Steve Russell , nhưng ông không phải là một nhà độc tài nhân từ. Theo thời gian, nhiều triển khai khác nhau của Lisp đã xuất hiện; Lisp thông thường là một nỗ lực để tiêu chuẩn hóa chúng.

Lisp là một "gia đình" ngôn ngữ. ML cũng vậy, đi theo con đường tiến hóa tương tự Lisp.

Một yếu tố có khả năng chỉ đơn giản là tuổi tác. Lisp và ML cũ hơn Python và Ruby rất nhiều:

• Lisp: 1958

• ML: 1973

• Con trăn: 1991

• Ruby: 1995

Lisp và ML rõ ràng đã thấy sự thay đổi lớn hơn nhiều về khả năng phần cứng, nhiều xu hướng hơn trong khoa học máy tính và rất nhiều sinh viên tiến sĩ đang tìm kiếm thứ gì đó để làm việc.

Về cơ bản, tất cả các ngôn ngữ được xác định thực hiện

Khi dễ dàng tạo ra một triển khai mới của một ngôn ngữ tương thích phần lớn với mã hiện có, thì tin tặc là tin tặc, họ tiếp tục và thực hiện nó. Mọi người đều viết một triển khai Lisp tại một số điểm. Trình biên dịch ML gần như là bắt buộc đối với học sinh tốt nghiệp trong thiết kế ngôn ngữ - ngôn ngữ này sau tất cả là tài liệu nổi tiếng .

Mặt khác, chúng tôi có các ngôn ngữ ad hoc và xác định thực hiện. Hoặc các ngôn ngữ quá phức tạp đến nỗi nó là một rào cản quan trọng đối với việc tạo ra một triển khai thay thế khả thi:

• hồng ngọc; perl; python - tất cả quá xác định thực hiện để tạo ra các lựa chọn thay thế khả thi
• ghc haskell và erlang - được xác định rõ, nhưng rất khó để làm bất cứ điều gì cạnh tranh với ghc (hoặc erlang) mà mọi người thường không bận tâm

Điều này có vẻ nhược điểm - các ngôn ngữ quá khó để tạo ra các lựa chọn thay thế khả thi, có một mặt trái lớn : tài nguyên nhà phát triển khan hiếm tập trung vào một triển khai thực sự.

Như một ghi chú lịch sử, một số người trong cộng đồng Haskell đã tích cực theo đuổi việc sáp nhập và tập trung nỗ lực của nhà phát triển, nhận ra rằng bất kỳ sự chia rẽ nào của cộng đồng nhà phát triển đều có nghĩa là chúng tôi sẽ không thành công. GHC đã được chọn và vô địch.

Tôi muốn nói một yếu tố là một nền tảng xác định . Đối với Haskell, nền tảng là tiêu chuẩn Haskell và GHC (tôi sẽ tưởng tượng). Đối với Ruby, Ruby on Rails đã "định nghĩa" nền tảng phát triển Ruby. Đối với C, đó là Unix.

So sánh điều đó với Lisp, nơi không có nền tảng kick-ass ban đầu xác định ngôn ngữ là gì. Nếu tôi nhớ lại chính xác thì mỗi máy Lisp có sự khác biệt nhỏ tùy thuộc vào kiểu máy và nhà sản xuất. Lisp thông thường là vì một số lý do không xác định. Có thể vì quá nhiều cạnh tranh và miễn cưỡng chuyển sang nền tảng khác.

Tất nhiên, đây là suy đoán hoàn toàn từ phía tôi. Ý nghĩ xuất phát từ những bình luận trả lời về câu trả lời của Harvey. Tuy nhiên, có vẻ như nền tảng xác định có nhiều hình dạng, nhưng tài sản chung dường như là thứ thu hút được sự phổ biến từ đó.

Đừng quên cân nhắc văn hóa thúc đẩy sự phát triển của ngôn ngữ

Tôi cũng sẽ cân nhắc thực tế rằng việc phát triển trên python / php được tích cực thực hiện ở nơi công cộng. Bạn có một nhóm các cá nhân đóng đinh một đặc điểm kỹ thuật tiêu chuẩn có sẵn miễn phí cho bất kỳ ai / mọi người.

Giống như W3C làm với tiêu chuẩn HTML / CSS. Bạn có một nhóm nhỏ các cá nhân có động lực kiểm soát các chi tiết tốt hơn về những gì ngôn ngữ được thiết kế để thực hiện. Tất cả mọi thứ đi vào một đặc điểm kỹ thuật được xác định rõ ràng trước khi nó được phát hành ra công chúng.

OTOH, các ngôn ngữ như LISP bị chặn bởi các giáo sư hoặc cá nhân khác thực sự tin rằng quan điểm của họ về 'sử dụng tốt nhất' ngôn ngữ là đúng. Chúng có thể đồng thời đúng và sai cùng một lúc vì một số triển khai là tuyệt vời ở những điều nhất định; trong khi không ai là tốt nhất trong tất cả mọi thứ

Đó không hẳn là một điều xấu bởi vì sự đa dạng tạo ra sự đổi mới. Các ngôn ngữ như LISP là, và sẽ vẫn là ngôn ngữ tuyệt vời để học tập và nghiên cứu vì chúng đẩy ranh giới của sự hiểu biết.

Nhưng những phẩm chất tạo ra một môi trường tốt cho sự đổi mới không nhất thiết có lợi cho sự ổn định; ngược lại, những phẩm chất tạo nên một môi trường tốt cho sự ổn định không nhất thiết phải tốt cho sự sáng tạo.

Khi phát triển dựa trên sự hợp tác tích cực, đôi khi các cá nhân buộc phải thừa nhận vì lợi ích của toàn bộ. Xấu cho nghiên cứu / tốt cho sự nhất quán.

Thực tế là, chúng ta vẫn đang sống ở phía tây hoang dã của sự phát triển ngôn ngữ lập trình. Vấn đề thiết kế "ngôn ngữ lý tưởng" lớn đến nỗi, mặc dù có những nỗ lực to lớn, nhưng không ai đến gần để giải quyết nó.

Trong lĩnh vực nghiên cứu / học thuật, vẫn còn rất nhiều cơ hội để cải tiến và đổi mới. Trong lĩnh vực thương mại, nơi có sự tăng trưởng theo cấp số nhân của phần mềm đang được sử dụng trong các ứng dụng thực tế và động lực là sự đơn giản và nhất quán.

Một số ngôn ngữ chuyên về cái trước, một số ngôn ngữ chuyên về cái sau. Những người cố gắng chuyên môn hóa cả hai thường không làm tốt lắm và chết đi.

Bởi cả hai, tôi đang đề cập đến các ngôn ngữ nguyên khối như VB / C # / Java. Vẫn còn quá sớm để nói nhưng tôi muốn xem C # và Python trông như thế nào sau 10 năm nữa. Ở tốc độ hiện tại, C # đang phát triển chức năng và sự không nhất quán ở tốc độ khiến nó trông khá nghiệt ngã. Ngay cả với tài liệu tuyệt vời, thật khó để nhớ tất cả các chi tiết và sự kỳ quặc tinh tế có trong ngôn ngữ. Thật tuyệt vời cho một nhà phát triển duy nhất nhưng ngay khi bạn ném vào nhiều nhà phát triển hơn với các phong cách độc đáo, sự không nhất quán trong codebase tăng lên, chất lượng bị ảnh hưởng và không ai chiến thắng. Tôi nghĩ rằng có rất nhiều điều phải học hỏi từ những khó khăn mà Perl thể hiện trong môi trường sản xuất.

Tôi không nghĩ là chính xác khi nói rằng các ngôn ngữ như Python và Ruby không bị phân mảnh. Chúng ta đã bắt đầu thấy một số hiệu ứng phân mảnh. Chẳng hạn, Python 3 không hoàn toàn tương thích ngược với Python 2, vì vậy cả hai phiên bản cần được duy trì và rất nhiều mã hiện có chỉ hoạt động với Python 2. Cũng có một số spinoff Python, bao gồm cả PyPy.

Một yếu tố khác là tuổi của các ngôn ngữ. Những ngôn ngữ bị phân mảnh nhiều nhất là các ngôn ngữ cũ và do đó chịu áp lực của sự tiến hóa và sửa đổi. Lisp đã được phát minh ra cách đây vài thập kỷ, vì vậy đã có nhiều thời gian để đưa ra một số ý tưởng của nó và kết hợp chúng vào các ngôn ngữ mới. C là một ví dụ khác về ngôn ngữ phân mảnh. Mặc dù C chỉ có một bản sửa đổi thực sự lớn đối với chính ngôn ngữ (K & R thành ANSI), đã có rất nhiều spinoff bao gồm C ++, Not Quite C và tất cả các bản khác có chung cú pháp giống C.

Bản thân Ruby là một "phân mảnh" (nếu bạn muốn) của các ngôn ngữ trước đó. Vì nó kết hợp các ý tưởng từ C, Smalltalk và Perl (trong số những người khác), nên hiện tại ngôn ngữ đang phân mảnh. Tôi không thấy lý do tại sao chúng ta có thể không thấy sự kết hợp của Ruby với các ngôn ngữ khác trong tương lai.

Lisp bị phân mảnh bởi vì nó là một mô hình mạnh mẽ, ngôn ngữ tuyệt vời nhất từng được hình thành. Hầu hết các ngôn ngữ ngày nay đều mượn những thứ lần đầu tiên được triển khai ở Lisp, vì vậy theo cách bạn có thể nói rằng mọi ngôn ngữ là một phần của sự phân mảnh cụ thể này. Ví dụ, Smalltalk được truyền cảm hứng rất nhiều từ Lisp và Ruby được truyền cảm hứng rất nhiều từ Smalltalk. JavaScript là Lisp trong một cách ngụy trang Java, v.v. Tất cả đều được kết nối và mọi nhà phát minh ngôn ngữ đều chọn các tác phẩm yêu thích của mình từ các ngôn ngữ khác.

Một yếu tố khác là Lisp có lẽ là khái niệm lập trình dễ thực hiện nhất - đó là lý do tại sao nó được thực hiện lặp đi lặp lại.

Các ngôn ngữ giống như Lisp là quá cơ bản và lý thuyết để được thay đổi đáng kể. Thay đổi ngữ pháp (tôi không có nghĩa là chỉ thay đổi tên của các lệnh) sẽ không phù hợp với lý thuyết lập trình chức năng đằng sau chúng.

Nhưng thực tế là có những ngôn ngữ như lisp cho thấy "những thay đổi" đã được thực hiện thành lisp dù sao đi nữa. Nói cách khác, có những ngôn ngữ được tạo ra bởi những người được truyền cảm hứng bởi lisp hoặc đó là lý thuyết đằng sau nó và tạo ra một ngôn ngữ mới tương tự theo cách khác.

Ngoài ra còn có rất nhiều ngôn ngữ lấy cảm hứng từ Python. Ví dụ: Julia, CoffeeScript, v.v ... sẽ tạo thành họ ngôn ngữ hướng đối tượng nhạy cảm với khoảng trắng.

Tôi nghĩ, những điều cơ bản cơ bản của một ngôn ngữ như Python sẽ không bao giờ thực sự thay đổi. Python hướng đối tượng và do đó có những điểm tương đồng với C ++ và Java nhưng nó động và do đó cũng tương tự như rất nhiều ngôn ngữ script.

Ai thực sự quan tâm đến ngôn ngữ? Điều quan trọng là mục đích: tiếng Pháp tương tự như tiếng Latin nhưng những cô gái hiểu tiếng Pháp thì nóng hơn;)