Nếu một ngôn ngữ thay đổi nhanh chóng, đây có được coi là một điều tốt?

Tôi đã thấy một số ngôn ngữ thay đổi nhanh chóng (ý tôi là chúng được cải thiện hàng năm chẳng hạn) và một số ngôn ngữ khác được cải thiện chậm.

Câu hỏi của tôi, nếu một ngôn ngữ thay đổi nhanh chóng thì đây là điều tốt hay xấu cho lập trình viên? Các lập trình viên có thích học điều mới trong ngôn ngữ hay họ thích gắn bó với những gì họ đã biết?

Nếu một ngôn ngữ thay đổi nhanh chóng thì đây là điều tốt hay xấu cho lập trình viên?

Tốt

• Các thay đổi có thể thêm một số đường tổng hợp đẹp làm cho mã tương lai dễ viết hơn với ít lỗi hơn
• Các thay đổi có thể tiêu chuẩn hóa một mẫu thành ngữ / thiết kế chung mà các lập trình viên phải tự thực hiện hoặc dựa vào các bên thứ 3 để thực hiện.
• Những thay đổi có thể giúp tích hợp dễ dàng hơn với các công nghệ mà ngôn ngữ thường được sử dụng với
• Những thay đổi có thể giúp ngăn ngừa những sai lầm phổ biến
• Những thay đổi có thể phản đối hoặc loại bỏ các thực hành lập trình nguy hiểm
• Các thay đổi có thể có những bổ sung hữu ích cho thư viện chuẩn của ngôn ngữ cho những thứ tôi từng phải tự thực hiện hoặc dựa vào bên thứ 3 để thực hiện.

Xấu

• Ngôn ngữ đã tăng thêm độ phức tạp - các tính năng mới có thể không phải lúc nào cũng chơi tốt với các tính năng cũ (tức là mối quan hệ của C ++ với C)
• Mã kế thừa có thể đã hết hạn và có thể không còn hoạt động trong phiên bản mới của ngôn ngữ mà không có bản cập nhật (Python 2.x -> 3.x)
• Trình biên dịch và các công cụ khác cho ngôn ngữ cần được cập nhật. Bây giờ có khả năng nhiều phiên bản tồn tại.
• Thư viện bên thứ 3 có thể không hỗ trợ phiên bản mới hơn của ngôn ngữ
• Bất chấp sự tồn tại của một tiêu chuẩn, có thể mất thời gian để tìm ra một cách tiêu chuẩn / thông thường để thực hiện các tính năng mới và xác định một số trường hợp khó hiểu hơn về hành vi của họ

Các lập trình viên có thích học điều mới trong ngôn ngữ hay họ thích gắn bó với những gì họ đã biết?

Nhiều lập trình viên thích thỏa mãn sự tò mò của họ bằng cách chơi với các tính năng mới. Tuy nhiên điều này không có nghĩa là các tính năng mới luôn phù hợp trong mã sản xuất. Đây là một quyết định tùy theo từng trường hợp phải cân nhắc lợi ích của các tính năng mới so với chi phí nâng cấp trong tình huống cụ thể của một người.

Tôi có thể vui vẻ hoặc thích tìm hiểu về các tính năng mới, nhưng vào cuối ngày, điều tôi thực sự quan tâm là cung cấp một sản phẩm hữu ích cho ai đó. Tôi phải chọn bộ công cụ đủ hiện đại để có sự hỗ trợ và ổn định hợp lý nhưng không quá cổ kính đến mức tôi không thể làm việc hiệu quả.

Những cải tiến rất tuyệt ... nếu chúng tương thích ngược .

C # làm điều này độc đáo. Họ thêm các biểu thức lamdba, hỗ trợ tốt hơn cho đa luồng, linq, ... Nhưng chương trình C # 2.0 năm tuổi của bạn vẫn sẽ hoạt động tốt mà không cần bất kỳ thay đổi nào và có thể dễ dàng nâng cấp lên C # 4.0 mà không cần bất kỳ thay đổi nào.

Học những thứ mới là điều tuyệt vời nếu nó cho phép bạn thực hiện các nhiệm vụ của mình một cách dễ dàng hơn, nhanh hơn. Nếu dành một giờ học có nghĩa là tiết kiệm thời gian của bạn trong thời gian phát triển, thì nó cũng đáng.

Tôi muốn cải tiến thường xuyên, nhưng tôi không muốn nó phá vỡ một cơ sở mã 500 kloc và kích hoạt một "dự án nâng cấp" khổng lồ chỉ để làm cho mã hoạt động theo cách của nó với phiên bản trước.

Ổn định ngôn ngữ là điều bắt buộc đối với doanh nghiệp và nhà phát triển. Thay đổi ngôn ngữ được hoan nghênh nếu họ giải quyết vấn đề hoặc giới thiệu các tính năng bị bỏ lỡ trong các bản phát hành trước đó, nhưng thay đổi ngôn ngữ sao cho hợp thời trang hoặc chỉ vì bạn muốn bắt kịp đối thủ cạnh tranh là không tốt.

Khi ngôn ngữ ổn định, theo thời gian, các nhà phát triển ngừng tập trung nỗ lực vào việc học ngôn ngữ vì họ sẽ thành thạo nó và bắt đầu tập trung nỗ lực vào việc phục vụ doanh nghiệp với những gì họ biết. Kết quả là dự án ngắn hơn, người dùng cuối hạnh phúc và nhà phát triển tự hào hơn!

Thay đổi cũng đi kèm với chi phí học tập và thời gian. Không phải tất cả các nhà tuyển dụng đều sẵn sàng giáo dục các nhà phát triển về các tính năng mới. Điều này thêm một gánh nặng đáng kể cho các nhà phát triển để tự đào tạo hoặc người khác - Đây không phải là tầm thường, các khóa học chuyên ngành có thể là $ 1500- $ 3500 mỗi khóa!

Thay đổi liên tục có thể khóa các nhà phát triển trong phần mềm 'di sản'. Hãy xem trường hợp nhà phát triển ASP đã không bắt kịp với MVVM trong 2 năm kể từ bây giờ hoặc trường hợp nhà phát triển Windows Forms không học WPF. Khóa này có thể làm tổn thương đáng kể sự nghiệp của nhà phát triển.

Làm thêm giờ, kiến ​​trúc của phần mềm trong một doanh nghiệp trở nên giống như một món salad vườn. Tất cả các loại công cụ và phiên bản và bạn thấy các dự án bắt đầu không làm gì ngoài việc nâng cấp phần mềm từ phiên bản này sang phiên bản tiếp theo mà không có bất kỳ lợi ích kinh doanh nào.

Tôi không nghĩ có câu trả lời nào đúng cả.

Nói chung, khi một ngôn ngữ còn khá trẻ, sẽ có nhiều tự do hơn để thực hiện các thay đổi tương đối lớn tương đối nhanh chóng. Không có một cơ sở lớn các mã hiện có để phá vỡ, vì vậy mọi người thường cởi mở hơn nhiều để thử nghiệm.

Khi ngôn ngữ già đi, giả sử nó có đủ người dùng để mọi người thực sự quan tâm, cơ sở của mã hiện tại bắt đầu đặt ra các hạn chế chặt chẽ và chặt chẽ hơn về những thay đổi có thể được thực hiện. Không chỉ có nhiều mã sử dụng nhiều tính năng hơn nên khó đoán được những thay đổi nào có thể phá vỡ mã, nhưng kỳ vọng của mọi người cũng thay đổi.

Ví dụ, giả sử có cùng số lượng người viết Ruby và Fortran. Hơn nữa, giả sử có cùng một lượng mã trong cả hai. Tôi muốn nói rằng rất có thể là khá tốt rằng một sự thay đổi đó đã phá vỡ chính xác tỷ lệ tương tự của mỗi (và trong một cách mà mất khoảng cùng một công việc để đúng) sẽ là một lô chấp nhận hơn cho người dùng của Ruby hơn người dùng Fortran như một quy luật chung (ít nhất là giả sử họ thấy đó là một sự cải tiến).

Tôi nghĩ nhiều thứ cũng phụ thuộc vào nhận thức của mọi người về ngôn ngữ để bắt đầu. Những người chọn một ngôn ngữ vì nó là "tiên tiến" có nhiều khả năng đưa ra những thay đổi lớn phá vỡ nhiều mã hiện có, nếu đó là những gì cần thiết để giữ cho nó vượt trội.

Một yếu tố khác là quy mô và tuổi thọ của các dự án mà ngôn ngữ được dự định. Một ngôn ngữ phục vụ cho các dự án tương đối nhỏ hoặc những dự án mà chúng tôi biết trước có tuổi thọ ngắn (ví dụ: giao diện người dùng web) có thể thoát khỏi việc phá vỡ mọi thứ tương đối thường xuyên, vì không chắc nhiều người sẽ tiếp tục sử dụng cùng một cơ sở mã cho, nói, 10 năm bằng mọi cách. Một ngôn ngữ (ví dụ: C ++ hoặc Java) phục vụ nhiều hơn cho các dự án lớn hơn, có thời gian tồn tại lâu hơn, có thể mất 5 năm để phát hành ban đầu, có thể được sử dụng thường xuyên (và phát triển liên tục) trong ba hoặc bốn thập kỷ rõ ràng là nhu cầu một lớn ổn định thỏa thuận hơn.

Tôi đã có một anh chàng nói với tôi rằng anh ta thích C ++ của mình và nó sẽ giữ nguyên như vậy. Anh ta không quan tâm hoặc không quan tâm đến D, anh ta không muốn biết cũng không sử dụng C #. Anh ta học java vì anh ta đã làm cho nhiều dự án anh ta cần làm và rõ ràng anh ta làm rất tốt các ngôn ngữ mà anh ta biết

Một người khác yêu C # và không biết mọi từ khóa hoặc biết các thư viện .NET 4 (async và all) và không sử dụng các từ khóa trừu tượng hoặc các thuộc tính được sử dụng.

Tôi chỉ đơn giản là nói hầu hết mọi người ĐỪNG CHĂM SÓC

Bây giờ các hiệu ứng của việc nâng cấp đang bị phá vỡ (đối với libs hoặc mã được biên dịch) mọi người S care quan tâm.

Tôi sẽ trả lời cho C # (nhưng phân tích này cũng có thể được áp dụng cho Scala):

Thay đổi tính năng này gây ra một số vấn đề khi bạn tiếp cận "phong cách" ngôn ngữ:

Trong năm 2011, C # có thể làm rất nhiều thứ khác nhau, và điều này là tốt. Thật không may, nó có hai mô hình khác nhau (nếu không nhiều hơn):

• OOP
• Chức năng (nghĩ về chức năng lambda và LINQ)

Các kiểu kiểm tra khác nhau

• Gõ động
• Gõ tĩnh

Không phải lúc nào cũng rõ ràng khi bạn muốn sử dụng cái này hay cái khác.

Tôi nghĩ rằng nó thực sự phụ thuộc vào ngôn ngữ và những điều sau đây mà ngôn ngữ có. Chẳng hạn, tôi nghĩ rằng nếu C # và Java bắt đầu xuất hiện các thay đổi với tốc độ nhanh hơn thì nó sẽ được chấp nhận (miễn là chúng tương thích ngược như Carra đã nói). Tuy nhiên, nếu ngôn ngữ chưa đạt được lực kéo và nó vẫn thay đổi nhanh chóng, tôi biết tôi sẽ không bận tâm đến nó vì có khả năng những gì tôi cố gắng học hôm nay sẽ khác hoàn toàn so với những gì đã ra trong 6 tháng và vì ngôn ngữ là mới / không phổ biến, nó sẽ không gây bất lợi cho tôi (đọc: sự nghiệp của tôi) đối với tôi để truyền lại nó.