Tại sao các ngôn ngữ lập trình cũ tiếp tục được sửa đổi?

Câu hỏi này không phải là "Tại sao mọi người vẫn sử dụng các ngôn ngữ lập trình cũ?" Tôi hiểu điều đó khá tốt. Trong thực tế, hai ngôn ngữ lập trình mà tôi biết rõ nhất là C và Scheme, cả hai ngôn ngữ này đều có từ những năm 70.

Gần đây tôi đã đọc về những thay đổi trong C99 và C11 so với C89 (dường như vẫn là phiên bản C được sử dụng nhiều nhất trong thực tế và phiên bản tôi học được từ K & R). Nhìn xung quanh, có vẻ như mọi ngôn ngữ lập trình được sử dụng nhiều đều có một đặc điểm kỹ thuật mới ít nhất một lần mỗi thập kỷ hoặc lâu hơn. Ngay cả Fortran vẫn nhận được các bản sửa đổi mới, mặc dù thực tế là hầu hết mọi người sử dụng nó vẫn đang sử dụng FORTRAN 77.

Tương phản điều này với cách tiếp cận của hệ thống sắp chữ TeX. Năm 1989, với việc phát hành TeX 3.0, Donald Knuth tuyên bố rằng TeX đã hoàn thiện tính năng và các bản phát hành trong tương lai sẽ chỉ chứa các bản sửa lỗi. Thậm chí, ông đã tuyên bố rằng sau khi chết, "tất cả các lỗi còn lại sẽ trở thành tính năng" và hoàn toàn không có bản cập nhật nào nữa sẽ được thực hiện. Những người khác được tự do rẽ nhánh TeX và đã làm như vậy, nhưng các hệ thống kết quả được đổi tên để chỉ ra rằng chúng khác với TeX chính thức. Điều này không phải vì Knuth nghĩ TeX là hoàn hảo, mà bởi vì anh ta hiểu giá trị của một hệ thống ổn định, có thể dự đoán được sẽ làm điều tương tự trong năm mươi năm như hiện tại.

Tại sao hầu hết các nhà thiết kế ngôn ngữ lập trình không theo cùng một nguyên tắc? Tất nhiên, khi một ngôn ngữ còn khá mới, sẽ có ý nghĩa rằng nó sẽ trải qua giai đoạn thay đổi nhanh chóng trước khi lắng xuống. Và không ai có thể thực sự phản đối những thay đổi nhỏ không làm được gì nhiều ngoài việc mã hóa các tiêu chuẩn giả hiện có hoặc sửa các bài đọc ngoài ý muốn. Nhưng khi một ngôn ngữ dường như vẫn cần cải thiện sau mười hoặc hai mươi năm, tại sao không chỉ rẽ nhánh hoặc bắt đầu lại, thay vì cố gắng thay đổi những gì đã được sử dụng? Nếu một số người thực sự muốn lập trình hướng đối tượng trong Fortran, tại sao không tạo ra "Fortive khách quan" cho mục đích đó và để Fortran một mình?

Tôi cho rằng người ta có thể nói rằng, bất kể phiên bản nào trong tương lai, C89 đã là một tiêu chuẩn và không có gì ngăn cản mọi người tiếp tục sử dụng nó. Đây là loại đúng, nhưng ý nghĩa có hậu quả. Trong chế độ pedantic, GCC sẽ cảnh báo về cú pháp bị phản đối hoặc có ý nghĩa khác biệt trong C99, điều đó có nghĩa là các lập trình viên C89 hoàn toàn không thể bỏ qua tiêu chuẩn mới. Vì vậy, phải có một số lợi ích trong C99 đủ để áp đặt chi phí này cho mọi người sử dụng ngôn ngữ.

Đây là một câu hỏi thực sự, không phải là một lời mời để tranh luận. Rõ ràng là tôi có ý kiến ​​về vấn đề này, nhưng hiện tại tôi chỉ đang cố gắng để hiểu tại sao đây không phải là cách mọi thứ đã được thực hiện. Tôi cho rằng câu hỏi là:

Những lợi thế (thực tế hoặc nhận thức) của việc cập nhật một tiêu chuẩn ngôn ngữ, trái ngược với việc tạo ra một ngôn ngữ mới dựa trên ngôn ngữ cũ là gì?

Tôi nghĩ rằng động lực để các nhà thiết kế ngôn ngữ sửa đổi các ngôn ngữ hiện tại là để giới thiệu sự đổi mới trong khi đảm bảo rằng cộng đồng nhà phát triển mục tiêu của họ ở lại với nhau và chấp nhận ngôn ngữ mới: chuyển một cộng đồng hiện tại sang một phiên bản mới của ngôn ngữ hiện tại có hiệu quả hơn là tạo ra một cộng đồng mới xung quanh một ngôn ngữ mới. Tất nhiên, điều này buộc một số nhà phát triển phải áp dụng tiêu chuẩn mới ngay cả khi họ vẫn ổn với cái cũ: trong một cộng đồng đôi khi bạn phải áp đặt một số quyết định nhất định cho thiểu số nếu bạn muốn giữ cộng đồng cùng nhau.

Ngoài ra, hãy xem xét rằng một ngôn ngữ có mục đích chung cố gắng phục vụ càng nhiều lập trình viên càng tốt và thường nó được áp dụng trong các lĩnh vực mới mà nó không được thiết kế cho. Vì vậy, thay vì hướng đến sự đơn giản và ổn định của thiết kế, cộng đồng có thể chọn kết hợp các ý tưởng mới (thậm chí từ các ngôn ngữ khác) khi ngôn ngữ chuyển sang các lĩnh vực ứng dụng mới. Trong một kịch bản như vậy, bạn không thể mong đợi có được nó ngay lần thử đầu tiên.

Điều này có nghĩa là các ngôn ngữ có thể trải qua thay đổi sâu sắc trong nhiều năm và phiên bản mới nhất có thể trông rất khác so với ngôn ngữ đầu tiên. Tên của ngôn ngữ không được giữ vì lý do kỹ thuật, nhưng vì cộng đồng các nhà phát triển đồng ý sử dụng tên cũ cho ngôn ngữ mới. Vì vậy, tên của ngôn ngữ lập trình xác định cộng đồng người dùng của nó chứ không phải là ngôn ngữ.

IMO động lực tại sao nhiều nhà phát triển thấy điều này chấp nhận được (hoặc thậm chí là mong muốn) là việc chuyển dần sang một ngôn ngữ hơi khác sẽ dễ dàng và ít gây nhầm lẫn hơn so với việc nhảy sang một ngôn ngữ hoàn toàn mới sẽ khiến họ mất nhiều thời gian và nỗ lực hơn để thành thạo. Hãy xem xét rằng có một số nhà phát triển có một hoặc hai ngôn ngữ yêu thích và không thích học ngôn ngữ mới (hoàn toàn khác biệt). Và ngay cả đối với những người thích học những thứ mới, học một ngôn ngữ lập trình mới luôn là một hoạt động khó khăn và tốn thời gian.

Ngoài ra, nó có thể là một phần của một cộng đồng lớn và hệ sinh thái phong phú hơn là một cộng đồng rất nhỏ sử dụng một ngôn ngữ ít được biết đến. Vì vậy, khi cộng đồng quyết định tiến lên, nhiều thành viên quyết định làm theo để tránh bị cô lập.

Là một nhận xét phụ, tôi nghĩ rằng đối số cho phép tiến hóa trong khi duy trì khả năng tương thích với mã kế thừa là khá yếu: Java có thể gọi mã C, Scala có thể dễ dàng tích hợp với mã Java, C # có thể tích hợp với C ++. Có nhiều ví dụ cho thấy rằng bạn có thể dễ dàng giao tiếp với mã kế thừa được viết bằng ngôn ngữ khác mà không cần tương thích mã nguồn.

GHI CHÚ

Từ một số câu trả lời và nhận xét tôi dường như hiểu rằng một số độc giả đã giải thích câu hỏi là "Tại sao ngôn ngữ lập trình cần phải phát triển."

Tôi nghĩ rằng đây không phải là điểm chính của câu hỏi, vì rõ ràng là ngôn ngữ lập trình cần phát triển và tại sao (yêu cầu mới, ý tưởng mới). Câu hỏi đặt ra là "Tại sao sự tiến hóa này phải xảy ra bên trong một ngôn ngữ lập trình thay vì sinh ra nhiều ngôn ngữ mới?"

Tương thích ngược là câu trả lời của bạn. Một ngôn ngữ nhất định, đặc biệt là một ngôn ngữ được sử dụng rộng rãi như C có thể có mã đang hoạt động, không thay đổi, trong nhiều thập kỷ. Nếu cần phải bảo trì, sẽ có các trình biên dịch vẫn có thể nhắm mục tiêu loại nền tảng đó trong khi chạy trên các hệ thống hiện đại cho công việc phát triển. Tiêu chuẩn hóa và cập nhật phiên bản ngôn ngữ giúp duy trì thực hành lập trình hiện tại trong khi vẫn mang lại cảm giác quen thuộc cho các lập trình viên kỳ cựu, những người có thể chống lại việc học một ngôn ngữ "hoàn toàn mới".

Hãy nhớ rằng nhiều ngôn ngữ được cập nhật ít được cập nhật nhiều như "có các bit sáng bóng mới được bắt vít". Những con thú của ngày xưa vẫn thường ẩn nấp bên trong.

Theo như Knuth, hãy nhớ rằng anh ta là một học giả và TeX chỉ được chứng minh là đúng, không được cập nhật.

Tôi nghĩ rằng câu trả lời rõ ràng là sự tiến bộ vẫn đang được tạo ra trong thiết kế ngôn ngữ và kiến ​​trúc hệ thống, và đủ người quan tâm đến các ngôn ngữ cũ hơn mà họ muốn tận dụng các kỹ thuật mới hơn (nhiều lõi, mô hình luồng hoặc bộ nhớ tốt hơn) mà chúng được bắt vít trên hoặc nướng vào tiêu chuẩn ngôn ngữ. Nó cũng giúp có "một cách thực sự" để thực hiện mọi việc (ví dụ: phân tích cú pháp XML, truy cập DB) mà bạn có thể tin tưởng để có bất kỳ trình biên dịch hoặc nền tảng nào, trái ngược với tùy thuộc vào một số bên thứ ba thư viện có thể hoặc không thể được cài đặt (và có thể hoặc không thể là phiên bản bạn yêu cầu, v.v.).

Các khái niệm hoặc mục tiêu cơ bản mà một ngôn ngữ có mục đích chung được xây dựng xung quanh không làm mất đi sự liên quan; tuy nhiên những thay đổi nhỏ trong môi trường làm việc hoặc phần cứng yêu cầu cập nhật hoặc các tính năng nhỏ được thêm vào ngôn ngữ.

Cách các thuật toán được thể hiện bằng ngôn ngữ sẽ không thay đổi, mặc dù nó có thể cần hỗ trợ sạch hơn cho các loại 64 bit hoặc hỗ trợ biểu thức chính quy tiêu chuẩn hơn hoặc hỗ trợ mạnh mẽ hơn cho các loại hệ thống tệp mới.

Có một vài trường hợp các tính năng 'mới' đang được thêm vào các ngôn ngữ hiện có, nhưng trong nhiều trường hợp, những thay đổi đó đã giúp đơn giản hóa mọi thứ mà mọi người đã thực hiện một cách khó khăn. (Xem C ++ bằng cách sử dụng các hàm bậc cao thay vì con trỏ hàm và hàm functor.)

Điều này hơi giống như một sự cân nhắc của ngôn ngữ nói.

Trong quá khứ có những từ không được sử dụng thường xuyên như bây giờ (hoặc được sử dụng cho một nghĩa khác).

ví dụ. tốt đẹp: trong tiếng Anh (rất cũ) có nghĩa gần như ngược với nghĩa mà chúng ta sử dụng ngày nay, đặc biệt khi được sử dụng để mô tả nhân vật của ai đó.

Xấu: cách đây không lâu, xấu chỉ có một ý nghĩa duy nhất, bây giờ nó có thể có nghĩa là "siêu tuyệt vời" (nó được sử dụng theo cách giả mạo (tôi có thể đã bỏ lỡ lỗi chính tả)!

một phát triển mới khác là điện thoại di động 'Text speak' cho các ngôn ngữ viết.

Cá nhân tôi không thấy lý do tại sao một ngôn ngữ lập trình sẽ không phát triển theo cách tương tự, các từ và chức năng có ý nghĩa / hành động cụ thể và cần phải thay đổi để kết hợp các ý tưởng mới, phương pháp mới.

Tôi biết những người nói nhiều ngôn ngữ khác nhau và họ thường gợi ý rằng sau lần thứ 3 hoặc thứ 4, việc học một ngôn ngữ mới sẽ trở nên dễ dàng hơn.

Tôi không biết nếu có những lập trình viên có trải nghiệm tương tự, tôi sẽ không ngạc nhiên nếu có.

Tôi biết rằng tôi cảm thấy hạnh phúc khi lập trình bằng JAVA (nhiều như tôi cảm thấy hạnh phúc khi nói bằng tiếng Anh) Điều này không có nghĩa là tôi không thể giao tiếp bằng 'tiếng Anh Mỹ' hoặc 'tiếng Anh úc' mặc dù có một số 'gotchas' để coi chừng . Giống như chuyển từ Java sang PHP sang Perl, các cấu trúc tương tự nhau, nhưng có một số vấn đề nhỏ để bắt tôi ra và khiến tôi đập đầu vào tường.

Điều này khác với việc chuyển từ tiếng Anh sang tiếng Pháp hoặc Java sang SAS. những điều này rất khác nhau, phải mất khá nhiều thời gian để thành thạo chúng.

Dù sao đó là của tôi về điều này.