Tuyên bố này về C # và Java là một nửa của ngôn ngữ có nghĩa là gì? [đóng cửa]

Trong bài viết: Tại sao POCO , có câu này:

Maciej Sobczak nói rất hay: Tôi chỉ không thích khi ai đó cho tôi một nửa ngôn ngữ và nói với tôi rằng đó là để bảo vệ chính mình.

Tôi không hiểu ý anh ta là gì, mặc dù C # thuộc sở hữu của Microsoft và Java thuộc sở hữu của Oracle , nhưng điều đó không có nghĩa là họ nắm giữ một nửa ngôn ngữ, phải không? Tôi đã không tìm thấy bất kỳ bằng chứng nào để chứng minh câu đó và tôi thực sự tò mò về điều này. Và thậm chí tò mò hơn về phần 'vì sự bảo vệ của riêng tôi'.

Sobczak không nói về quyền sở hữu doanh nghiệp. Ngôn ngữ "một nửa" mà anh ấy thiếu là tất cả những thứ mà bạn không thể làm bằng nhiều ngôn ngữ hiện đại, mặc dù là một chuyên gia máy tính được giáo dục tốt, anh ấy biết rằng chúng có thể được thực hiện: kế thừa từ nhiều lớp học như bạn muốn. Gán bất kỳ đối tượng nào cho bất kỳ đối tượng nào khác mà không có ràng buộc kiểu. Kiểm soát phân bổ và giải phóng tài nguyên theo cách thủ công thay vì tin tưởng vào trình biên dịch và thời gian chạy để làm điều đó cho anh ta.

Vấn đề là, tất cả những hạn chế đó đã được đưa vào ngôn ngữ lập trình vì một lý do. Chúng tôi đã có ngôn ngữ cho phép tất cả điều này. Theo thời gian, chúng tôi thấy rằng lập trình viên trung bình tốt hơn với một số hạn chế nhất định và nắm tay, bởi vì khả năng tạo ra các lỗi thực sự xấu là quá lớn để có giá trị sức mạnh và biểu cảm bổ sung.

(Rõ ràng, điều này đôi khi làm phiền lập trình viên sẽ không thực sự cần nhiều tay nắm giữ. Phàn nàn của họ là đôi khi chính đáng. Nhưng mọi người đều nổi tiếng là xấu tại đánh giá kỹ năng của riêng mình, và nhiều người nghĩ rằng họ không cần các biện pháp bảo vệ làm, trong Thực tế, rất cần chúng. Không phải lúc nào cũng dễ dàng phân biệt được những người thực sự vượt trội thực sự, những người cảm thấy bị kìm hãm bởi những hạn chế trong ngôn ngữ cấp cao từ những lập trình viên trung bình, những người chỉ nghĩ rằng phàn nàn sẽ khiến họ trông vượt trội hơn, hoặc những người không biết bất kỳ tốt hơn.)

Điều này được giải thích khá độc đáo trong nguồn gốc của trích dẫn :

Tôi quyết định tìm hiểu thêm về C ++ và trở thành niềm đam mê trung thành của nó - điều này bao gồm sự quan tâm của tôi về cách ngôn ngữ này có khả năng phát triển. Hơn nữa, tôi nhận thấy rằng các kỹ thuật cao cấp và hiện đại nhất là cần thiết để phát triển các thư viện hữu ích , chứ không phải các ứng dụng thực tế. Có được điều này, tôi đã cố gắng viết một vài thư viện của riêng mình cho các mục đích khác nhau (xem trang tải xuống của tôi) và tôi cũng cố gắng xem qua vai của các nhà phát triển C ++ Boost (xem trang liên kết của tôi) để tìm hiểu những gì kỹ thuật cao cấp là. Dành thời gian cho việc phát triển các thư viện được cho là chung chung và hữu ích cùng một lúc là thực sự đòi hỏi. Đó là lý do tại sao các lập trình viên không bao giờ ngừng học hỏi.

[Càng]

Tôi tiếp tục chơi với C ++ và các kỹ thuật để viết phần mềm mạnh mẽ. Để có được góc nhìn rộng hơn trong lĩnh vực phần mềm đáng tin cậy, tôi quyết định đầu tư một chút thời gian vào việc học Ada (và những thứ liên quan), đây là ngôn ngữ dường như bị doanh nghiệp bỏ rơi hoàn toàn mặc dù Ada thực sự được thiết kế phức tạp và đáng tin cậy hệ thống. Tôi phải thừa nhận rằng việc học Ada thực sự có lợi cho tôi theo nghĩa là nó cho phép tôi có cái nhìn mới mẻ hơn về cách tiếp cận công việc và phát triển của mình. Quan trọng nhất, một số ý tưởng từ thế giới Ada có thể ít nhiều được áp dụng trực tiếp vào C ++ với kết quả tốt trong lĩnh vực mạnh mẽ và chính xác.

[Càng]

OK, tôi quên mất. Tôi thề một ngày không học Java. Nhưng tôi đã làm. Vâng, đến mức cho phép tôi đọc và viết mã làm việc. Tôi đã đọc 'Suy nghĩ bằng Java' (có sẵn trên mạng, miễn phí) và 'Core Java' (không trực tuyến, không miễn phí), tôi cũng đã gián tiếp tham gia vào một số phát triển Java và ... Chà, tôi không mua nó Tôi chỉ không thích khi ai đó cho tôi một nửa ngôn ngữ và nói với tôi rằng đó là để bảo vệ chính tôi. Nó giống như một cái búa giấy, được làm nhẹ để không ai bị thương khi chạm ngón tay ... Điều tương tự cũng áp dụng với C #. Tôi chọn búa tạ thép, để tôi có thể chắc chắn rằng khi tôi muốn chơi macho, nó sẽ chịu được.
Câu hỏi là - tại sao nhiều người sử dụng nó (Java, C #, v.v.)? Hmmm ... Có lẽ bởi vì nó rất tốt ở một số nơi. Nhưng có những tình huống, trong đó cả ngôn ngữ và thư viện cho thấy rằng chúng được thiết kế thay cho các applet (ban đầu) hơn là trở thành tiện ích làm mọi thứ. Nó chỉ hứa hẹn quá nhiều và cung cấp quá ít như cho công nghệ bắt tất cả. Hoặc như một giải pháp có thể vượt qua mọi đối thủ cạnh tranh ..

Tôi thích C ++ khi cần sức mạnh tối đa và quan điểm rộng nhất. Ở những nơi mà tính biểu cảm của C ++ không phải là thứ bắt buộc, các ngôn ngữ như Tcl hoặc Python dường như phù hợp với dự luật. Không chỉ họ cởi mở liên quan đến sự tiến hóa của họ, mà người ta có thể mở rộng và nhúng chúng, tùy thuộc vào nhu cầu cụ thể. Tôi thấy rất nhiều khả năng mơ ước trong những công nghệ đó. Tôi cũng có xu hướng từ bỏ C làm ngôn ngữ cho lập trình thông thường - đây dường như là một lựa chọn hợp lý chỉ là mục tiêu để tạo mã, nếu không, nó quá dễ bị lỗi. Hôm nay, Ada là sự lựa chọn thứ hai của tôi cho các dự án nghiêm túc hơn, với điều kiện là tôi có sự lựa chọn miễn phí (điều không may là không phải là trường hợp thường xuyên).

Vì vậy, nói cách khác, tác giả của trích dẫn đó thích C ++ và anh ta không thích Java và anh ta cảm thấy Java thiếu một nửa C ++. Và đó là tất cả để có trích dẫn đó.

Bài viết được liên kết đến trong blog bạn đăng đã bị xóa, vì vậy thật khó để chắc chắn, nhưng như Kilian nói, có khả năng là khi anh ấy nói "một nửa ngôn ngữ", anh ấy có nghĩa là C # và Java cảm thấy giống như C ++ nhưng với rất nhiều các tính năng và cấu trúc được loại bỏ để làm cho chúng dễ sử dụng hơn hoặc an toàn hơn.

Trở lại năm 2006, khi điều này được viết, khi C # còn khá trẻ và Java còn non nớt và khi sức mạnh và sự an toàn dường như là một sự đánh đổi mà bạn chỉ có thể chọn một, đây không phải là một vị trí hoàn toàn vô lý .

Ngày nay, vị trí đó không hợp lý chút nào. Chỉ cần nghĩ về các ngôn ngữ chính, C # và Java đã trưởng thành rất nhiều, mượn các tính năng từ các ngôn ngữ khác (đặc biệt là chức năng) để thúc đẩy viết mã an toàn. Chúng tôi cũng có các ngôn ngữ như Rust và Swift được xây dựng từ đầu để làm điều này.

Nếu ai đó xem thường ngôn ngữ vì nó nắm tay bạn hoặc nói rằng ngôn ngữ khó sử dụng là một điều tốt, thì tôi sẽ lấy bất cứ thứ gì họ nói bằng một hạt muối. Bạn chỉ cần nhìn vào số lỗi đáng xấu hổ được tìm thấy trong mã mà chúng ta phụ thuộc hàng ngày, được viết bởi những bộ óc thông minh nhất trong ngành, điều đó có thể tránh được bằng cách sử dụng các ngôn ngữ 'an toàn', để biết tại sao.

Nhìn lại các tài liệu lưu trữ , có vẻ như trích dẫn này là từ năm 2003 (mặc dù bài báo trích dẫn từ năm 2006). Vào thời điểm đó, C # đang ở Phiên bản 1. x và nó thiếu rất nhiều tính năng hiện đại :

Các tính năng mới

C # 2.0

• Generics
• Các loại một phần
• Phương pháp ẩn danh
• Lặp đi lặp lại
• Các loại không thể
• Khả năng truy cập riêng của Getter / setter
• Chuyển đổi nhóm phương thức (đại biểu)
• Co-và Contra-variance cho các đại biểu
• Các lớp tĩnh
• Đại biểu suy luận

C # 3.0

• Hoàn toàn gõ các biến cục bộ
• Đối tượng và bộ sưu tập khởi tạo
• Thuộc tính tự động thực hiện
• Các loại ẩn danh
• Phương pháp mở rộng
• Biểu thức truy vấn
• Biểu hiện Lambda
• Cây biểu hiện
• Phương pháp từng phần

C # 4.0

• Liên kết động
• Đối số được đặt tên và tùy chọn
• Chung và chống chỉ định
• Các loại interop nhúng ("NoPIA")

C # 5.0

• Phương pháp không đồng bộ
• Thuộc tính thông tin người gọi

C # 6.0

• Trình biên dịch dưới dạng dịch vụ (Roslyn)
• Nhập thành viên kiểu tĩnh vào không gian tên
• Bộ lọc ngoại lệ
• Chờ đợi trong bắt / cuối cùng khối
• Khởi tạo tài sản tự động
• Giá trị mặc định cho các thuộc tính chỉ getter
• Thành viên thể hiện
• Công cụ truyền Null (toán tử null có điều kiện, kiểm tra null cô đọng)
• Nội suy chuỗi
• toán tử tên
• Từ điển khởi tạo

C # 7.0

• Biến ra
• Khớp mẫu
• Bộ dụng cụ
• Giải cấu trúc
• Chức năng địa phương
• Chữ số phân cách
• Chữ nhị phân
• Tham chiếu trở lại và người dân địa phương
• Các kiểu trả về async tổng quát
• Xây dựng cơ thể biểu hiện và hoàn thiện
• Biểu hiện cơ thể getters và setters

C # 7.1

• Không đồng bộ chính
• Biểu thức nghĩa đen mặc định
• Tên phần tử tuple suy ra

- "C Sharp" , Wikipedia (đã xóa tham chiếu và liên kết)

Có lẽ dễ hiểu hơn khi C # có vẻ giống như một nửa ngôn ngữ trong bối cảnh đó, vì nó thiếu rất nhiều những gì C # ngày nay. Thật kỳ lạ khi nghĩ rằng nó thậm chí không có staticlớp học!

Cũng có nhiều thứ bị thiếu, vì C # đã được gắn với .NET. Ví dụ, WPF không xuất hiện trước đó; tất cả đều là WinForms.

Ông đã phàn nàn về việc thiếu các tính năng ngôn ngữ cho phép kiểm soát chi tiết. Chúng bao gồm các công cụ cho

• Thực thi tính bất biến (như consttừ khóa C ++ )
• Kiểm soát tuổi thọ và quyền sở hữu đối tượng
• Kiểm soát sử dụng bộ nhớ, sao chép và phân bổ kiểu

Điều này nhắc nhở tôi về một trong những lời chỉ trích của tôi về Java:

tất cả mọi thứ là một con trỏ, nhưng con trỏ không tồn tại.

Trong các đối tượng C ++, con trỏ và tham chiếu là ba khái niệm riêng biệt với ngữ nghĩa rõ ràng. Trong Java, bạn chỉ có con trỏ giả đối tượng. Bằng cách kết hợp những thứ này và tránh ngữ nghĩa con trỏ thực, mô hình đối tượng ít rõ ràng hơn.

Trong một chương trình C ++ được xác định rõ, lập trình viên có thể mong đợi các tham chiếu là hợp lệ và không null. Do mô hình đơn giản hóa của nó, Java không thể thực hiện các đảm bảo tương tự.

Các triệu chứng của mô hình ít rõ ràng này bao gồm mẫu đối tượng null và các điều kiện yoda như 5.equals(potentiallyNullIntegerReference).

Tôi đồng ý với câu trả lời @Kilian nhưng tôi sẽ thêm một số yếu tố.

1- Chạy với máy ảo không phải hệ điều hành

Vì Java và C # đang chạy qua Máy ảo, nên theo logic, bạn không thể thực hiện chính xác những gì bạn muốn khi chạy thẳng trên HĐH, bởi vì bạn có khả năng bị hỏng thứ gì đó trong VM. Hơn nữa, với Java được định hướng là bất khả tri về nền tảng, nó thậm chí còn logic hơn.

2- Hàng tấn ứng dụng không yêu cầu bạn cần những thứ đó.

Có rất nhiều ứng dụng thực sự không cần bạn khai thác nhiều chi tiết đó, nhưng nếu bạn làm điều đó với một ngôn ngữ yêu cầu bạn làm điều đó bạn sẽ nhận được:

• Nhiều rủi ro hơn để có lỗi do những thứ không cần thiết.
• Chi phí phát triển nhiều hơn, quản lý bộ nhớ và thử nghiệm cần nhiều thời gian và tiền bạc!

3- Ngôn ngữ được thực hiện trên một số chi phí lựa chọn / sử dụng / rủi ro, như ... tất cả mọi thứ.

Với C ++, bạn có thể làm khá nhiều thứ bạn muốn, đó là sự lựa chọn của người C ++. Tuy nhiên, càng có nhiều, bạn càng cần phải xử lý.

Vì vậy, những thứ như thừa kế không chỉ từ bỏ vì thực tế là chúng nguy hiểm, chúng đã từ bỏ vì thực hiện chúng có chi phí (phát triển, bảo trì), tất cả chỉ dành cho một tính năng hiếm khi được sử dụng đúng cách và có thể nói chung được viết lại khác nhau.

Đơn giản chỉ cần đặt tất cả các hạn chế trong các ngôn ngữ cấp cao như C # và Java tồn tại để bảo vệ lập trình viên. Họ tồn tại không quá nhiều để bảo vệ lập trình viên khỏi anh ta, mà là để bảo vệ lập trình viên khỏi các lập trình viên khác!

Đã bao nhiêu lần chúng ta khi các lập trình viên gặp phải các thư viện hết sức tệ hại trong thực tiễn và thiết kế mã hóa của họ nhưng chúng ta buộc phải sử dụng vì lý do này hay lý do khác?

Các chương trình này thường có các đặc điểm nổi bật của phương pháp lập trình thủ tục cũ, thiếu đóng gói, nhiều bộ nhớ trực tiếp ghi với rất ít hoặc không có lỗi bắt hoặc xử lý. Segfaults theo đuổi en-mass khi cố gắng sử dụng chúng trong bất kỳ dự án quy mô lớn nào.

Đó là nơi các ngôn ngữ như Java và C # cực kỳ hữu ích; Không phải là chúng tôi thích sự thật là họ không cho chúng tôi làm tất cả những điều gọn gàng mà các ngôn ngữ khác làm, đó là chúng tôi thích sự thiếu đau đầu mà chúng tôi phải chịu đựng vì các lập trình viên khác sẽ lạm dụng những điều gọn gàng mà các ngôn ngữ khác có thể làm

Các giao diện rất có giá trị đối với bất kỳ loại đánh đổi nào về bộ nhớ hoặc tốc độ thực thi trong tâm trí của tôi. Tôi hy vọng bạn có thể thấy rằng trong bất kỳ loại ứng dụng quan trọng nào có nhiệm vụ giới hạn thời gian, tất cả các biện pháp bảo vệ đó, xử lý lỗi thích hợp và nói chung chắc chắn rằng bộ nhớ không bị xử lý là những điều tốt!