Là so sánh ngôn ngữ có ý nghĩa? [đóng cửa]

Tiến sĩ Bjarne Stroustrup trong cuốn sách của mình D & E nói

Một số nhà phê bình yêu cầu tôi so sánh C ++ với các ngôn ngữ khác. Điều này tôi đã quyết định không làm. Qua đó, tôi đã tái khẳng định một quan điểm lâu đời và được giữ vững: "So sánh ngôn ngữ hiếm khi có ý nghĩa và thậm chí ít thường xuyên hơn". Một so sánh tốt về các ngôn ngữ lập trình chính đòi hỏi nhiều nỗ lực hơn so với hầu hết mọi người sẵn sàng chi tiêu, trải nghiệm trong một loạt các lĩnh vực ứng dụng, duy trì cứng nhắc quan điểm vô tư và vô tư, và cảm giác công bằng. Tôi không có thời gian, và là người thiết kế C ++, sự vô tư của tôi sẽ không bao giờ đáng tin cậy hoàn toàn.

- Thiết kế và tiến hóa của C ++ (Bjarne Stroustrup)

Bạn có đồng ý với tuyên bố này của anh ấy " Language comparisons are rarely meaningful and even less often fair" không?

Cá nhân tôi nghĩ rằng việc so sánh một ngôn ngữ X với Y có ý nghĩa bởi vì nó đưa ra nhiều lý do hơn để yêu / coi thường X / Y :-P

Bạn có người nghĩ gì?

tôi thích so sánh các ngôn ngữ lập trình!

tôi so sánh java với một làn gió ấm áp với một cơn mưa

tôi so sánh C # với ngày xuân tươi đẹp với những đám mây trắng mịn vừa đủ để giữ cho bầu trời hạnh phúc

tôi so sánh C với búa tạ trong một căn phòng đầy kính

tôi so sánh C ++ với một chiếc búa tạ trong một thế giới pha lê

tôi so sánh VB với một món đồ chơi gió cũ chìm trong bồn tắm

tôi so sánh PL / 1 với cái đe rỉ sét, bắt vít xuống sàn

Bạn so sánh chúng với cái gì?

Tôi nghĩ rằng Stroustrup là hoàn toàn chính xác. So sánh đầy đủ hai ngôn ngữ trên giá trị kỹ thuật của chúng đòi hỏi đủ sự quen thuộc với cả hai để viết mã thành ngữ và sử dụng cùng một mẫu thiết kế thường được sử dụng bởi các lập trình viên, những người rất năng suất trong cả hai ngôn ngữ. Một người không có trình độ hiểu biết về cả hai ngôn ngữ có thể thấy những thứ không được cung cấp rõ ràng bởi ngôn ngữ mà anh ta không quen thuộc và cho rằng sẽ có vấn đề.

Ví dụ, một người không sử dụng Python thường xuyên có thể cho rằng người dùng Python thường xuyên gặp sự cố vì thụt lề. Hoặc ai đó không quen thuộc với Common Lisp có thể xem xét việc thiếu các thư viện được đánh bóng, nhưng không biết rằng FFI đủ mạnh để viết các hàm bao cho các thư viện C với nỗ lực danh nghĩa. Ai đó không quen thuộc với Ruby có thể thấy việc thiếu gõ tĩnh và cho rằng lỗi loại sẽ là một vấn đề lớn. Cuối cùng, ai đó không quen thuộc với Haskell có thể thấy thiếu sự phân công và cho rằng nó không thể xử lý trạng thái.

Bây giờ tất cả những điều này giả định rằng các ngôn ngữ thực sự chỉ được so sánh trên giá trị kỹ thuật của chúng.

Một ngôn ngữ là một công cụ. Điều đó nói rằng, tôi đã thấy các công cụ thực sự, thực sự nhảm nhí trước đây. Không ai muốn làm việc với một cái búa có đầu có khả năng bay ra và đâm vào một người thợ mộc khác trong bụng. Tương tự như vậy, nếu bạn nhận thấy cây búa của đồng nghiệp của bạn có hình dạng đó, có lẽ bạn sẽ tránh xa chúng khi họ đang sử dụng nó.

Nó cũng quan trọng để thực sự hiểu nó là công cụ nào. Bạn không thể sử dụng tuốc nơ vít và búa thay thế cho nhau (mặc dù một số người cố gắng hết sức). Địa ngục bạn thậm chí không thể sử dụng tất cả các búa thay thế cho nhau; bạn cần một cái tạ cho một số thứ, một cái vồ cho những người khác và một chiến thuật cho những người khác. Nếu bạn sử dụng công cụ không phù hợp, thì tốt nhất, bạn sẽ làm một công việc kém hơn, tệ nhất là bạn sẽ tự làm mình bị thương hoặc đồng nghiệp.

Nói cách khác, so sánh ngôn ngữ rất hữu ích ở chỗ nó có thể ngăn ngừa tai nạn tại nơi làm việc. Lấy những điều trên ra khỏi phép ẩn dụ; thật khó để biết nếu không so sánh liệu một ngôn ngữ nhất định là búa tạ, tuốc nơ vít, máy khoan hay cưa bàn, bởi vì (không giống như các công cụ vật lý) bạn không thể thực sự biết chỉ bằng cách liếc nhìn. Bạn cần suy nghĩ về các tính năng mà nó cung cấp, xem nó hoạt động (bằng cách đọc các phần quan trọng của một cơ sở mã lớn được viết trong đó), và lý tưởng nhất là tự mình lái thử. Cẩn thận không phạm sai lầm khi chỉ viết Cobol bằng Python (ví dụ). Bạn cần sử dụng ngôn ngữ mới một cách thành ngữ, có nghĩa là học tốt nó. Đây có lẽ là lý do tại sao Bjarne nói rằng hầu hết mọi người không nỗ lực hết sức để so sánh hữu ích.

Kiểu so sánh bắt đầu bằng "Tôi thích Blub" và tiếp tục với "Chà, tôi thích Blub ++" là hoàn toàn vô dụng. Nếu kết thúc việc chọn một ngôn ngữ, tất cả những gì nó thực sự cho bạn biết là ai có sức thuyết phục nhất trong một nhóm nhất định và / hoặc công ty ngôn ngữ nào có ngân sách quảng cáo lớn nhất. Nếu bạn phân tích những gì một ngôn ngữ có thể làm, những nhiệm vụ phù hợp cho nó và những thiếu sót của nó mà không cần dùng đến những lý lẽ không hợp lý hoặc thiên vị cá nhân, thì điều đó thực sự hữu ích.

Điều đó, ngoại trừ một số trường hợp hiếm (và - hiếm - như trong "nó xảy ra một hoặc hai lần trong vòng đời của hệ mặt trời"), nó thường dẫn đến các cuộc chiến ngôn ngữ, trong biến thể mạnh hơn hoặc ít hơn, và rất hiếm khi để lại một số thực tế và kết luận hữu ích.

Ngôn ngữ là công cụ, không phải tôn giáo. Bạn không so sánh búa với tuốc nơ vít, nhưng bạn sử dụng cái phù hợp với nhiệm vụ & cách suy nghĩ / giáo dục / mức độ trừu tượng cần thiết nhất của bạn. Ngoài ra, vì người thực hiện so sánh bị thiên vị bởi thực tế là anh ta biết ít nhất một trong hai, hoặc ít nhất là thích một trong hai, nên khó có thể tìm thấy một tiêu chí thực sự khách quan để so sánh chúng (ngoại lệ tồn tại).

Nếu chúng ta coi ngôn ngữ là sản phẩm và tất cả các nhà phát triển là thị trường, chúng ta có thể đi đến một vài kết luận thú vị:

1. Sản phẩm không phải lúc nào cũng cạnh tranh. Chẳng hạn, Haskell không giải quyết các vấn đề tương tự như Java mà không giải quyết được các vấn đề tương tự như Hội không giải quyết được các vấn đề tương tự như Prolog. Một nhà phát triển, trong các tình huống khác nhau, có thể sử dụng tất cả các ngôn ngữ này. So sánh ngụ ý cạnh tranh cho sự vượt trội. Do đó, không có ý nghĩa gì khi so sánh các ngôn ngữ không cạnh tranh.
2. Khả năng hiển thị trên thị trường có nghĩa là sản phẩm đã được chứng minh là hữu ích với ai đó. Đó là, bạn có thể so sánh Ruby và Python tất cả những gì bạn muốn - mọi người làm điều đó mọi lúc. Bằng cách nào đó, điều đó dường như không thay đổi suy nghĩ của bất kỳ ai (hoặc nếu có, cùng một số người thay đổi suy nghĩ theo hướng khác). Theo những cách quan trọng, Ruby và Python là tương đương. Nó giống như hai công ty soda khổng lồ thực hiện so sánh "khoa học" các sản phẩm của họ. Một nghiên cứu cho thấy Coca-cola vượt trội trong khi các nghiên cứu khác cho thấy Pepsi vượt trội. Ngay cả khi dữ liệu là đáng tin cậy, nó không có nghĩa gì cả. Tất cả chúng ta đều biết rằng họ là những loại soda hoàn hảo (ngôn ngữ lập trình) và rằng một thứ chỉ hấp dẫn ít nhiều theo sở thích cá nhân của tôi.
3. So sánh ngôn ngữ là một hình thức tiếp thị chuyên nghiệp. Nếu có một nơi hoàn toàn khách quan để bắt đầu so sánh, chúng có thể hữu ích. Tất nhiên là không có. Bất kỳ ai bận tâm để so sánh đều cố gắng xác nhận sự thiên vị hiện có. Họ đang cố gắng bán một ngôn ngữ. Một lần nữa, nếu C ++ quá tệ hoặc VB quá tệ hoặc Erlang quá tệ, vậy tại sao mọi người lại sử dụng chúng? Bạn có thể đưa ra tất cả các yêu cầu bạn muốn, nhưng điều đó không ngăn chúng trở nên hữu ích. Giả định của chúng tôi là mọi người quá ngu ngốc khi nhìn thấy sự thật trước mặt họ, nhưng sự thật có khả năng là "thị trường" phức tạp hơn chúng ta tưởng. So sánh cho chúng ta biết nhiều hơn về người thực hiện so sánh so với những sản phẩm được so sánh.

Stroustrup là hoàn toàn chính xác.

Hầu hết các "so sánh ngôn ngữ" được thực hiện với một kết quả cụ thể, đó là "cho thấy" cái này "vượt trội" so với cái kia.

Thông thường, điều này có nghĩa là viết một đoạn mã bằng cả hai ngôn ngữ và đo hiệu suất của tệp thực thi được tạo, viết một ngôn ngữ được tối ưu hóa cao và ngôn ngữ kia cố tình cho hiệu suất kém. Đây là cách huyền thoại "Java chậm" được duy trì. Các "kiểm tra" để "chứng minh" nó được viết có chủ ý để không đo lường hiệu năng của việc chạy mã Java mà là thời gian khởi động của JVM. Lấy ví dụ một thao tác toán học đơn giản và lặp lại 100 lần, thực hiện điều đó trong Java và C ++, biên dịch phiên bản C ++ với bật tối ưu hóa, phiên bản Java không có cờ tối ưu hóa, sau đó chạy cả hai phiên bản thực thi. Lớp Java sẽ chạy lâu hơn nhiều so với tệp thực thi C ++, đơn giản là do thời gian khởi động của JVM. Điều này cho thấy không phải là "Java chậm" nhưng thời gian khởi động JVM có nghĩa là Java không phải là công cụ thích hợp cho các quy trình chạy rất ngắn (không phải là bất kỳ ngôn ngữ nào được giải thích hoặc bất kỳ thứ gì khác yêu cầu tải thời gian chạy). Thử nghiệm được viết đúng để chạy trong khoảng thời gian vài giờ với cả cơ sở mã và hệ thống trình biên dịch sử dụng mức tối ưu hóa tương đương, kết quả khá khác nhau (có thể cho thấy hiệu suất khá giống nhau).

Và đó chỉ là một ví dụ (mà tôi tình cờ quen thuộc).

Là người quản lý dự án, bạn phải thực hiện một số so sánh để chọn ngôn ngữ mà phần mềm của bạn sẽ được mã hóa. Tiêu chí có thể không phải là kỹ thuật:

• Ngôn ngữ có phù hợp với nhiệm vụ không
• Là ngôn ngữ có sẵn trên tất cả các nền tảng đích
• Chất lượng, độ tin cậy và chi phí của trình biên dịch
• Có lập trình viên nào biết ngôn ngữ đó không, họ có năng lực, đắt tiền, sáng tạo không