Tại sao độ dài của ngôn ngữ lập trình lại không tốt? [đóng cửa]

Tôi đã thấy nhiều người xung quanh phàn nàn về tính dài dòng trong các ngôn ngữ lập trình. Tôi thấy rằng, trong một số giới hạn, ngôn ngữ lập trình càng dài thì càng dễ hiểu. Tôi nghĩ rằng tính dài dòng cũng củng cố việc viết APIs rõ ràng hơn cho ngôn ngữ cụ thể đó.

Nhược điểm duy nhất tôi có thể nghĩ đến là nó khiến bạn gõ nhiều hơn, nhưng ý tôi là, hầu hết mọi người đều sử dụng IDE làm tất cả công việc cho bạn.

Vì vậy, những nhược điểm có thể có đối với một ngôn ngữ lập trình dài dòng là gì?

Mục tiêu là hiểu nhanh

"Verbose" có nghĩa là "sử dụng quá nhiều từ". Câu hỏi là "quá nhiều" là gì.

Mã tốt nên dễ hiểu trong nháy mắt. Điều này dễ dàng hơn nếu hầu hết các ký tự trực tiếp phục vụ mục đích của mã .

Tín hiệu vs tiếng ồn

Nếu một ngôn ngữ dài dòng, nhiều mã của bạn sẽ bị nhiễu. So sánh "Hello World" của Java :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... với Ruby's:

print "Hello World!"

Tiếng ồn làm lãng phí năng lượng tinh thần.

Mật mã vs Xóa

Mặt khác, sự căng thẳng quá mức trong một ngôn ngữ cũng tiêu tốn năng lượng tinh thần. So sánh hai ví dụ từ Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

Nó ảnh hưởng đến bao nhiêu mã bạn có thể thấy và phân tích trong nháy mắt

x++ thay vì set(x,Integeradd(get(x),1))

ps. Đó không chỉ là vấn đề đọc mã. Trong thời của màn hình 40x25, các ngôn ngữ loại APL, hoặc Perl, rất hữu ích đối với Cobol hoặc Fortran đối với số lượng mã bạn có thể đọc / trang. Nhưng bây giờ nó nói nhiều hơn về bộ nhớ cache bên trong của riêng bạn - nếu một câu lệnh có một toán tử đơn lẻ thì bộ não lão hóa của tôi sẽ dễ dàng phân tích hơn một với 3 biểu tượng và 4 lệnh gọi hàm.

Nếu độ dài ngôn ngữ làm giảm khả năng đọc mã, thì đó là xấu.

Một số ngôn ngữ có cú pháp dài dòng như vậy mà việc nắm bắt ý nghĩa của mã mất nhiều thời gian hơn (tôi đang nghĩ về VB.NET so với C #):

If something Then
End If

if(something)
{}

Nó thực sự sôi sục với những gì một lập trình viên quen thuộc và thoải mái.

Hãy nhìn vào AppleScript , một trong những ngôn ngữ dài dòng nhất mà tôi có thể nghĩ ra có thể được coi là hiện tại , hãy thử viết một thứ gì đó trong đó và quay lại và thử và cho rằng tính dài dòng là một đặc điểm tốt trong ngôn ngữ.

Cố gắng nhớ tất cả các ngữ nghĩa về nơi các từ khóa đi và những gì chúng là không tầm thường nếu bạn không làm điều đó mỗi ngày.

Chỉ cần nhìn vào tất cả các nhiễu từ khóa trong ví dụ tầm thường này:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

được cấp điều tương tự bashvới các công cụ Unix truyền thống sẽ rất ngắn gọn nhưng khó hiểu đối với hầu hết người dùng OSX, do đó cần phải có sự cân bằng.

Tôi nghĩ rằng bạn cần phải đặt câu hỏi lên đầu và hỏi: Tại sao một số người nghĩ mã terse là tốt?

Câu trả lời của tôi sẽ có hai lý do cơ bản:

Lý do tại sao Terse có thể tốt hơn

Chúng bao gồm dễ đọc hơn, theo cùng một cách mà một câu ngắn có thể dễ hiểu hơn một câu dài, hoa mỹ. Thông thường các ngôn ngữ lập trình cố gắng và mô phỏng ngữ pháp của ngôn ngữ tiếng Anh cuối cùng trở nên dài dòng khủng khiếp, đòi hỏi phải mở rộng mã lớn để thực hiện các hành động đơn giản nhất. Thông thường bạn sẽ thấy rằng ngôn ngữ càng mô phỏng ngôn ngữ viết thì càng khó dỗ nó thực hiện các hoạt động phức tạp về mặt logic.

Lý do tại sao Terse có thể tồi tệ hơn

Một số ngôn ngữ (và tôi đang nghĩ về Perl) sử dụng một loạt các ký hiệu lạ, dường như được chọn gần như tùy ý, như một phần của cú pháp của chúng. Đối với bất cứ ai không quen thuộc với các chữ tượng hình này thì ngôn ngữ sẽ trở nên bất khả xâm phạm. Nó cũng trở nên dễ dàng mắc lỗi đánh máy mà không dễ thấy. Biểu thức thông thường có lẽ là điển hình cho loại căng thẳng này.

Ngoài ra, một số người thích thể hiện bằng cách viết mã ngắn gọn bởi vì, thẳng thắn, họ nghĩ rằng nó làm cho họ trông thông minh. Đôi khi bạn thấy điều này trên StackOverflow, nơi mọi người thường sẽ gửi câu trả lời cực kỳ nhỏ gọn với chi phí dễ đọc. Đây là một loại "gây ấn tượng với đồng nghiệp của bạn" với bao nhiêu bạn biết triết lý, nhưng các lập trình viên giỏi nhận ra rằng " golf mã " không phải là cách để tạo ra phần mềm có thể bảo trì.

@frowing, tôi muốn đề xuất một cách để xem xét vấn đề dài hạn là nhận ra rằng lập trình luôn là sự pha trộn của hai phong cách tìm kiếm và thể hiện một giải pháp khá khác nhau.

Phong cách đầu tiên và dài dòng hơn là lập trình theo ngôn ngữ (ngôn ngữ). Phong cách này kết hợp các từ giống như danh từ và các từ giống như động từ trong các cấu trúc giống như câu, và nó được dự định để đọc và hiểu theo cách tương tự như một đoạn văn được viết tốt. Lập trình ngôn ngữ là phong cách lập trình phổ biến nhất vì bản thân ngôn ngữ là phổ quát. Vì lý do tương tự, hỗ trợ chương trình dài hạn luôn cần một thành phần ngôn ngữ mạnh mẽ, vì điều đầu tiên mà một lập trình viên mới sẽ tìm kiếm là sự hiểu biết khái niệm về những gì đang được thực hiện. Theo nguyên tắc chung, bạn càng di chuyển ra xa khỏi bối cảnh bạn tạo chương trình, thì phong cách lập trình ngôn ngữ sẽ càng quan trọng để đảm bảo rằng các giả định và khái niệm của bạn sẽ không bị hiểu lầm bởi người tiếp theo cố gắng hiểu mã của bạn .

Phong cách thứ hai và ngắn gọn hơn là lập trình hướng toán học (toán học). Phong cách lý luận này cũng dựa vào ngôn ngữ, vì ví dụ các biến tương tự như danh từ và toán tử với động từ. Tuy nhiên, lý luận toán học thúc đẩy khả năng tuyệt vời và song song của bộ não chúng ta để thực hiện các phép biến đổi không gian phức tạp trên các vật thể nằm trong tầm nhìn của chúng ta. Bằng cách biểu thị các danh từ và động từ dưới dạng các ký hiệu nhỏ gọn, đặc biệt có thể được sắp xếp thành các đối tượng tưởng tượng có cấu trúc tốt - phương trình - sau đó chúng ta có thể sử dụng các khả năng trực quan song song cao của mình để thực hiện các phép quay, thay thế, chuyển động, đảo ngược và các phép biến đổi khác trên các tưởng tượng này các đối tượng. Kết quả là một sự khuếch đại lớn về số lượng các trường hợp chúng ta có thể xử lý cùng một lúc, vì mỗi biểu tượng có thể đại diện cho toàn bộ các lớp của các đối tượng liên quan chặt chẽ.

Lưu ý rằng để áp dụng xử lý hình ảnh một cách hiệu quả, bạn cần giữ cho đối tượng tưởng tượng của mình giống nhau nhất có thể về kích thước và tính năng với một đối tượng thực. Nếu trường tầm nhìn cần thiết quá rộng hoặc các ký hiệu không thể được sử dụng như dấu di động trên một đối tượng hoặc nếu bạn phải đọc các chữ cái và chuyển đổi chúng thành các từ, thì khả năng thực hiện các phép biến đổi phức tạp sẽ giảm đi nhanh chóng ngay cả đối với một nhà toán học rất tốt.

Đó là lý do tại sao mọi người đắm chìm trong phong cách toán học lập trình có thể trở nên không hài lòng nghiêm trọng nếu một phương trình được trải ra và thể hiện theo cách mà họ sẽ gọi là phong cách ngôn ngữ của verbose. Không phải vì phương trình đã được thay đổi đáng kể, bởi vì việc truyền bá nó ra như thế có thể khiến cho việc áp dụng một kiểu hiểu biết về nó gần như không thể. Tuy nhiên, cùng lúc đó, một lập trình viên mới hoàn toàn không quen thuộc với các ký hiệu ngắn có khả năng thích phiên bản dài dòng hơn, cung cấp nhiều thông tin ngôn ngữ hơn để hiểu ban đầu mã này làm gì.

Vì vậy, những gì tôi sẽ đề nghị?

Sử dụng cả hai phong cách, nhưng chú ý cẩn thận tại sao bạn đang sử dụng từng phong cách.

Ví dụ, bất cứ điều gì có cơ hội giao tiếp với thế giới bên ngoài nên được kéo dài ở một mức độ nào đó, ngay cả khi chỉ ở dạng nhận xét nội tuyến trộn với mã và cũng nên bao gồm kiểm tra tự động để sử dụng đúng. Các ký hiệu mật mã và đặc biệt được xác định không đầy đủ không có kinh doanh trong các giao diện như vậy, vì chúng gần như được đảm bảo để bị hiểu lầm tại một số điểm. Các lỗ năm 1999 của Mars Climate nhân tiện do sự thất bại trong việc nhận ra cho dù đơn vị giao diện phần mềm được thể hiện trong bảng hoặc Newtons là một ví dụ đặc biệt nhọn của sự nguy hiểm của phụ thuộc quá tình cờ trên số liệu ở phần mềm hoặc phần cứng giao diện.

Ngược lại, bất kỳ hình thức lập trình nào có tính toán học và toán học sâu sắc là một ứng cử viên tốt lập trình cô đọng, hỗ trợ phong cách toán học của lý luận. Nếu ai đó mới phải duy trì mã như vậy, thông thường sẽ tốt hơn cho họ để tìm hiểu các ký hiệu toán học thay vì cố gắng chuyển đổi mã thành các dạng dài hơn. Tất nhiên lúc nào cũng nên có sẵn tài liệu để giải thích các phần toán học mà mã có sẵn cho các nhà phát triển như vậy, nhưng đó là một vấn đề riêng biệt.

Ở giữa những thái cực này là nhiều trường hợp lập trình viên có quyền quyết định đáng kể. Tôi sẽ đề nghị xem xét cách mã sẽ được duy trì trong dài hạn và cố gắng đáp ứng nhu cầu của những người có khả năng duy trì mã trong dài hạn.

Một số người đã bóng gió về điều gì đó mà tôi nghĩ có lẽ nên được nêu rõ ràng.

Độ dài có xu hướng ủng hộ sự hiểu biết ở cấp độ hiển vi - nó thường dẫn đến một tuyên bố cá nhân dễ đọc và dễ hiểu. Độ dài cũng có xu hướng làm giảm mức độ quen thuộc với ngôn ngữ cần thiết để hiểu nó (ít nhất là ở một mức độ nào đó). Các ngôn ngữ dài dòng nhất (ví dụ, COBOL) có thể ít nhất có thể đọc được ngay cả khi những người không lập trình hoàn chỉnh.

Sự quan tâm có xu hướng ngược lại: nó giúp hiểu ở cấp độ vĩ mô, đặc biệt là bởi các lập trình viên có sự quen thuộc gần gũi nhất với ngôn ngữ cụ thể đó. Đồng thời, việc không quen thuộc với ngôn ngữ cụ thể đó có thể ngăn chặn ngay cả sự hiểu biết thô sơ, ngay cả từ các lập trình viên, những người khá kinh nghiệm.

Như vậy, khả năng đọc rất khác nhau tùy thuộc vào đối tượng mục tiêu. Một mặt, hãy xem xét một dự án lớn, phức tạp được viết và duy trì bởi những người làm việc gần như độc quyền trong dự án đó, hầu hết những người có nền tảng lập trình và giáo dục đáng kể (ví dụ, rất nhiều tiến sĩ). Điều này sẽ có xu hướng ủng hộ một ngôn ngữ ngắn gọn hơn.

Ít nhiều thì ngược lại, hãy xem xét một dự án đơn giản hơn đáng kể (mặc dù vẫn còn khá lớn) được duy trì chủ yếu bởi những người thực sự chuyên kinh doanh liên quan đến phần mềm, thay vì trong chính phần mềm. Điều này gần như chắc chắn sẽ ủng hộ một ngôn ngữ dài dòng hơn nhiều.

Thay vì đi đến một cuốn sách kỹ thuật, tôi trở lại các yếu tố của phong cách * của Strunk và White. Khái niệm cơ bản là "Hãy chính xác" và "Đừng nói nhiều hơn mức cần thiết." Mọi thứ khác là bình luận.

Áp dụng cho lập trình, đó là về việc rất chính xác, nhưng không có lông tơ không cần thiết. Fluff thêm có thể là cú pháp, nhưng nó cũng có thể là nhiều từ hơn yêu cầu để truyền đạt ý nghĩa. (Tất nhiên không quá ít để cho phép sự mơ hồ)

• Tôi trích dẫn phiên bản gốc vì nó ngắn gọn nhất. :-)

Vào cuối ngày, bất cứ điều gì "khác biệt" sẽ khiến mọi người hú lên. Tôi thấy thoải mái với cú pháp kiểu C và do đó ok với các ngôn ngữ khác có chung cú pháp (C ++, Java, C #). Vì vậy, tôi có xu hướng ủng hộ phong cách đặc biệt này.

Ngôn ngữ có xu hướng tìm sự cân bằng giữa mô tả đủ, và không dài dòng.

Perl là một ví dụ về nơi bạn có thể viết mã rất súc tích. Đối với những người không quen biết, mã được viết bởi một ninja Perl không có gì là kỳ diệu.

COBOL là một ví dụ về quá dài dòng.

Tôi đã đọc ở đâu đó một lần rằng rất nhiều cuộc tranh luận dài dòng đến từ những lập trình viên mới và những người cũ. Điều tương tự được sử dụng là khi chúng ta học một cái gì đó mới, chúng ta tự nói với mình một "câu chuyện" để vượt qua nó (nghĩ về khi bạn học đại số ở HS). Khi chúng tôi có được kinh nghiệm, chúng tôi vượt ra ngoài nhu cầu về một câu chuyện giải thích các thành phần riêng lẻ và chúng tôi hiểu được số tiền lớn hơn. Mã của chúng tôi trở nên dày đặc hơn và ngắn gọn hơn, với các bình luận chỉ giải thích các mục cần thiết, thay vì nhắc lại những gì mã nói.

Tôi đã thấy điều này là đúng giữa tôi và đồng nghiệp. Cô viết mã với rất nhiều bình luận giải thích các dòng mã là gì và rất nhiều khoảng trắng. Nếu tôi đang đọc nó, tôi thấy rằng tôi chỉ có thể phù hợp với một vài dòng mã trên một màn hình vì điều này. Điều đó làm cho việc hiểu từng dòng riêng lẻ dễ dàng hơn rất nhiều, nhưng việc tìm kiếm toàn bộ chức năng trở nên khó khăn hơn nhiều.

Tôi có xu hướng viết mã mà không có khoảng trắng hoặc bình luận thêm. Điều này làm cho việc nhìn toàn bộ dễ dàng hơn nhiều, nhưng bạn phải có khả năng "lấy" mã "từ" riêng lẻ. Nếu bạn đã cố gắng đọc câu trả lời này với mỗi từ nằm trên một dòng riêng, với rất nhiều khoảng trắng / bình luận / thêm thông báo thì việc hiểu từng từ riêng lẻ sẽ dễ dàng hơn rất nhiều, nhưng khó hiểu hơn toàn bộ.

Einstein đã nói đúng: "Làm cho mọi thứ đơn giản nhất có thể, nhưng không đơn giản hơn."

Điều này cũng áp dụng cho mã. Nếu bạn có thể đơn giản hóa mã bằng cách loại bỏ các yếu tố dài dòng lặp đi lặp lại và không cần thiết, đó là một điều tốt.

Ngoài ra, một số nghiên cứu trường hợp cho thấy năng suất của lập trình viên được đo bằng các dòng mã ít nhiều là một hằng số. Vì vậy, số lượng lỗi trên mỗi LỘC. Vì vậy, chuyển sang một ngôn ngữ cho phép bạn làm nhiều hơn trên mỗi dòng mã có thể được coi là một cải tiến năng suất, nếu tất cả những thứ khác không thay đổi.

Điều đó đang được nói, có một xu hướng trong ngành công nghiệp này để vượt qua kỹ sư và làm phức tạp những gì nên là những điều đơn giản. Những điều đơn giản như nhồi chi tiết liên lạc trong cơ sở dữ liệu quan hệ. Tôi đã thấy một số giải pháp phức tạp và sai lầm ( ho MDA) cho vấn đề cụ thể đó. Các ngôn ngữ như Scala và Ruby là những ví dụ điển hình về các công cụ mạnh mẽ mà trong tay một số cá nhân nhất định dẫn đến mã không thể hiểu được, quá phức tạp và bảo trì kém. Chỉ vì bạn có thể sử dụng nhiều cấp độ gián tiếp với một vài nét chính không có nghĩa là bạn phải đánh bật mọi móng tay trong tầm ngắm với cây búa đặc biệt đó.

Khi được sử dụng đúng cách, bạn sẽ có được mã sạch đẹp, vừa ngắn gọn vừa dễ hiểu. Khi được sử dụng kém, tốt hơn hết bạn nên giới hạn cá nhân trong câu hỏi sử dụng ngôn ngữ cơ bản trực quan hoặc ngôn ngữ hạn chế tương tự để ngăn ngừa thiệt hại thêm.

Kỹ năng thực sự nằm ở việc tạo ra những thứ phức tạp một cách đơn giản, không phải là tạo ra những thứ đơn giản theo một cách phức tạp.

Một cái gì đó không ai khác đạt được là số lượng mã bạn có thể đặt trong một màn hình. Nó giúp vì nhiều lý do:

• Ít cuộn qua lại khi bạn đang làm việc (hoặc đọc) nhiều chức năng trong một tệp.
• Cuộn ngang ít hơn (dừng đọc, nhấp và kéo thanh cuộn, ngừng đọc, nhấp và kéo thanh cuộn ...).
• Quét nhanh hơn, vì có ít cú pháp vô dụng hơn trong cách tìm kiếm những gì bạn muốn.

Bởi vì nhiều mã hơn có nghĩa là nhiều lần phát triển hơn và nhiều lỗi hơn.

Nếu bạn viết 100 dòng mã chứ không phải 300 dòng mã. Điều đó có nghĩa là gần 1/3 lần phát triển bạn cần và 1/3 lỗi tiềm năng bạn có thể gặp.

Trong hầu hết các trường hợp, bạn cần phải cân bằng giữa hiệu quả và sự đồng nhất, vì viết ít mã hơn có nghĩa là máy cần phải làm nhiều việc hơn và nó sẽ làm giảm hiệu quả.

Thông thường, mọi người ủng hộ các ngôn ngữ dễ đọc / dài dòng hơn các ngôn ngữ khó hiểu / ngắn gọn. Tuy nhiên, tôi nghĩ rằng hầu hết mọi người đồng hóa "tính dài dòng" với "sự lộn xộn", đó không phải là điều tương tự.

Ví dụ: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

là một tuyên bố rất ngắn gọn. Nó chứa mọi thứ bạn muốn biết. Tuy nhiên, vì nó căng thẳng, thật khó hiểu. Mặt khác, một phiên bản dài hơn một chút của cùng một chương trình sẽ khá dễ hiểu vì nó dễ đọc hơn. Tất nhiên đây không phải là một tài sản của ngôn ngữ, nhưng một số ngôn ngữ có xu hướng dài hơn trong khi những ngôn ngữ khác có xu hướng cụ thể hơn trong cách lập trình của họ.

Đối với thái cực khác của tính dài dòng, là http://en.wikipedia.org/wiki/Literate_programming , mà tôi cho là một khái niệm khá thú vị.

Một khía cạnh khác là "tính dài dòng không mong muốn", còn được gọi là "sự lộn xộn". Những thứ bạn phải thêm vì lý do kỹ thuật, thiếu đường cú pháp, API cồng kềnh, v.v.

Tôi nghĩ rằng một cú pháp rõ ràng và trực quan là rất quan trọng. Nó cũng phải đủ dài để tạo điều kiện dễ đọc. Các câu lệnh quá ngắn được đóng gói với quá nhiều logic thường có thể dẫn đến nhiều thời gian để giải mã hơn so với các đối tác dài hơn một chút của chúng. Mặt khác, mã cồng kềnh vô dụng chứa đầy các dòng soạn sẵn để làm một cái gì đó hoàn toàn đơn giản cũng gây phiền toái không kém.

Độ dài là một xu hướng sử dụng số lượng lớn văn bản và Việc sử dụng rất ít văn bản ...

Độ dài là xấu vì:

1. nó giới thiệu nhiều cơ hội hơn cho lỗi đánh máy
2. nó làm cho việc đọc mã trên màn hình hoặc giấy trở nên khó khăn hơn và / hoặc nhập vào punchcard
   1. điều này làm tăng thời gian gỡ lỗi
   2. điều này làm cho việc hiểu mã để nâng cấp / bảo trì khó hơn
   3. điều này có thể dẫn đến sự trùng lặp mã ngoài ý muốn
3. nó làm tăng khả năng lỗi cú pháp
4. nó làm giảm tính linh hoạt của mã hóa, trong đó, hầu hết các ngôn ngữ dài dòng có cấu trúc cao và không có nhiều cách để nói cùng một điều.
5. nó làm tăng thời gian mã hóa và biên dịch
6. nó có thể mất nhiều không gian lưu trữ hơn.

Một mức độ dài nhất định là cần thiết cho sự rõ ràng, tuy nhiên ...

mức độ tối thiểu của Verbosity là tốt bởi vì:

1. con người dễ đọc và gắn giá trị ngữ nghĩa hơn là mã đơn thuần
2. Trong cách đặt tên biến và hàm, việc gỡ lỗi, chuyển và duy trì mã dễ dàng hơn
3. trong các hoạt động ngôn ngữ cấp cơ sở và từ khóa của các ngôn ngữ phức tạp, nó dẫn đến ít thao tác / từ khóa không chính xác.

Một số ví dụ tuyệt vời về các lệnh quá ngắn cho nhiều người bao gồm các ký tự BASIC cũ của val(x$), str$(x)và chr$(x)... trả về một số từ biểu diễn chuỗi của nó, trả về một chuỗi cho một số và trả về một ký tự có giá trị ascii x dưới dạng chuỗi.

Hoặc con trỏ C / C ++ và bởi các toán tử tham chiếu &và *so với byreftừ khóa BASIC . Trong C / C ++, tôi có thể có một biến X và truyền một con trỏ tới biến đó, nhưng tôi phải nhớ đó là con trỏ nào và đó là "con trỏ sử dụng làm biến nó trỏ tới"; về cơ bản, tôi chỉ đơn giản chuyển tham chiếu bằng từ khóa byref trong lệnh gọi hàm, rõ ràng hơn, nhưng kém linh hoạt hơn:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

Trong mã này, nội dung của x được sửa đổi do cờ byref. Một số hương vị cho phép byref tại cuộc gọi, một số khác trong định nghĩa, một số trong một trong hai.

Độ dài rất quan trọng đối với các lập trình viên thông thường để có thể sử dụng biểu tượng dễ dàng hơn; BASIC hoặc python dễ đọc hơn và dài dòng hơn C / C ++, và do đó hữu ích hơn nhiều cho các lập trình viên thông thường; sự căng thẳng của C / C ++ giúp các lập trình viên có kinh nghiệm hơn, những người cần xem nhiều mã hơn và mã phức tạp hơn trong một màn hình, nhưng phải học các quy ước cấu trúc biểu tượng khác nhau. Ở phía xa là APL, gần như hoàn toàn không thể đọc được.

Một vấn đề liên quan mật thiết là sự rõ ràng - mã terse thường không rõ ràng và mã dài dòng quá mức (như trong AppleScript) có thể không rõ ràng như nhau. Sự quen thuộc với một ngôn ngữ nhất định làm tăng sự rõ ràng của mã terse trong ngôn ngữ đó - một người mới bắt đầu, đối mặt với mã C ++ có khả năng chỉ có thể phân tích các công thức và thậm chí nhiều mã BASIC hoặc Python có chức năng quá khó hiểu, nhưng táo bạo có thể nói chung là khó hiểu mà không cần phải đọc từ điển ngôn ngữ. Ít rõ ràng nhất mà tôi gặp phải mà không có sự cố ý che giấu là Thông báo 7 ...

Vào những ngày xưa

Một cân nhắc quan trọng khác trong quá khứ, nhưng một điều không còn quan trọng đối với người viết mã sở thích, đó là không gian hoạt động và lưu trữ. .

Một số giải pháp đã tồn tại - mã thông báo là cực kỳ phổ biến trong BASIC; các từ khóa ngôn ngữ riêng lẻ đã được giảm xuống thành một từ 1 hoặc 2 byte ở khoảng trên 128 hoặc không gian ký tự điều khiển. Mã thông báo cũng dẫn đến việc biên dịch mã byte (như trong Thông tin và Máy Z).

Nhiều trình biên dịch và liên kết tệp đối tượng cũng được sử dụng để khắc phục các giới hạn về không gian. Phần mã Pascal 100KiB có thể biên dịch thành chỉ 5KiB; bằng cách liên kết nhiều tệp được biên dịch, người ta có thể xây dựng các ứng dụng lớn mà không cần truy cập vào các ổ đĩa định dạng lớn (hãy nhớ rằng 10MiB có dung lượng lớn đáng kinh ngạc và mua một chiếc xe mới đắt tiền).

Tuy nhiên, nhiều ngôn ngữ ngắn hơn đã nhận được nhiều mã hơn vào một đoạn nhất định của cả đĩa và ram, và do đó biên dịch các khối lớn hơn tại một thời điểm. Hãy ghi nhớ: "máy tính mini" đầu thập niên 1970 có thể chỉ có 64KiB ram (Honeywell 800 có cài đặt cơ bản gồm 4 ngân hàng mỗi ngân hàng 2048 từ 8B). APL và các ngôn ngữ tượng trưng tương tự đã tiếp cận 1B mỗi lệnh cộng với toán hạng của nó, so với 3B-10B lớn hơn trên mỗi lệnh cộng với toán hạng. (Đó là một cơn ác mộng khi gõ vào thẻ đục lỗ, đặc biệt là vì các biểu tượng về cơ bản là một phông chữ trên bóng loại và nhiều thẻ bài không có ký hiệu trên các phím ...)

Ngoài ra, hãy nhớ rằng thẻ không thể bị xóa ... và nhiều chương trình đã được nhập vào thẻ. Mặc dù không đắt tiền riêng lẻ, mã của bạn có thể được nén trên thẻ càng nhiều, bạn càng cần ít hơn và các chương trình có thể lớn hơn hoặc ít tốn kém hơn. Đây là một phần lý do BASIC có nhiều hướng dẫn trên mỗi dòng trong hầu hết các hương vị - nó được giới thiệu để tiết kiệm thẻ đục lỗ. .

Giống như với rất nhiều điều, câu trả lời phụ thuộc vào định nghĩa cụ thể của "tính dài dòng". Nếu định nghĩa như vậy mà tính dài dòng hàm ý sự dư thừa thì tôi sẽ cho rằng nó luôn xấu. Lưu ý rằng với định nghĩa như vậy, chương trình hello hello Java thường được trích dẫn sẽ không đủ điều kiện là "dài dòng", bởi vì không có gì trong đó là dư thừa.

Các lập trình viên có xu hướng thích các ngôn ngữ có sức mạnh biểu cảm vì nó cho phép họ mã hóa những điều đơn giản, thường phải được thực hiện thường xuyên, trong các đoạn mã nhỏ. Các ngôn ngữ dài có xu hướng có nghĩa là nhiều, nhiều dòng mã phải được sử dụng để làm điều tương tự lặp đi lặp lại. Tuy nhiên, có thể có một cái giá phải trả bằng các ngôn ngữ biểu cảm vì chúng có thể không được thực thi nhanh như các ngôn ngữ cấp cao đơn giản hơn. Nếu tôi có thể đưa ra một ví dụ trong sự tương phản giữa C và C ++. C ++ mang lại sức mạnh biểu cảm nhiều hơn cho người viết mã - họ có thể gói gọn ý tưởng về các đối tượng trong thế giới thực trong các lớp. Các lập trình viên C có thể đạt được những điều tương tự nhưng họ có sức mạnh biểu cảm của việc xây dựng lớp để giúp họ - vì vậy họ thường phải viết mã dài hơn, phức tạp hơn (để hiểu). Nhưng mã đó có thể chạy nhanh hơn (mặc dù điều này phụ thuộc nhiều vào chất lượng trình biên dịch, v.v.) vì nó không sử dụng "ràng buộc muộn" của C ++ (tức là chạy tái cấu trúc thời gian) để thực thi mã. C chỉ thực thi mã được biên dịch và liên kết, C ++ phải đưa ra quyết định (trong một số trường hợp nhất định) trong thời gian chạy về việc thực thi đoạn mã nào.

Tôi tin rằng có một câu trả lời cho câu hỏi bắt nguồn từ một vấn đề cơ bản và lý thuyết hơn là dễ đọc và câu trả lời này có liên quan đến lý thuyết thông tin thuật toán được thành lập bởi Gregory Chaitin: http://en.wikipedia.org/wiki/Alacticmic_inif_theory . Nói cách khác, "nội dung thông tin của một chuỗi tương đương với độ dài của biểu diễn tự chứa ngắn nhất có thể có của chuỗi đó", Điều này ngụ ý rằng chương trình ngắn nhất (cụ thể là về độ dài từ vựng của nó) giải quyết chặt chẽ một vấn đề nhất định phù hợp với sự phức tạp nội tại của vấn đề mà nó đưa ra giải pháp và do đó, nó phụ thuộc nhiều hơn vào bản chất vấn đề và ít hơn vào sự biểu diễn của vấn đề.