Ngôn ngữ lập trình nên nghiêm ngặt hay lỏng lẻo? [đóng cửa]

Trong Python và JavaScript, dấu chấm phẩy là tùy chọn.

Trong PHP, các trích dẫn xung quanh các khóa mảng là tùy chọn ( $_GET[key]vs $_GET['key']), mặc dù nếu bạn bỏ qua chúng, trước tiên nó sẽ tìm một hằng số theo tên đó. Nó cũng cho phép 2 kiểu khác nhau cho các khối (dấu hai chấm hoặc dấu ngoặc nhọn).

Bây giờ tôi đang tạo một ngôn ngữ lập trình và tôi đang cố gắng quyết định mức độ nghiêm ngặt của tôi. Có rất nhiều trường hợp các ký tự phụ không thực sự cần thiết và có thể được giải thích rõ ràng do các ưu tiên, nhưng tôi tự hỏi liệu tôi có nên thi hành chúng hay không để khuyến khích tính nhất quán.

Bạn nghĩ sao?

Được rồi, ngôn ngữ của tôi không phải là ngôn ngữ lập trình nhiều như một ngôn ngữ tạo khuôn mẫu lạ mắt. Một loại lai giữa mẫu Haml và Django . Đồng nghĩa với việc được sử dụng với khung web C # của tôi và được cho là rất mở rộng.

Các loại ngôn ngữ khác nhau có cách sử dụng khác nhau, vì vậy câu trả lời cho câu hỏi này thực sự phụ thuộc vào việc bạn sẽ sử dụng nó để làm gì.

Ví dụ, Perl là một ngôn ngữ rất lỏng lẻo và tôi thấy nó rất hữu ích cho việc viết các bản sửa lỗi nhanh hoặc các tập lệnh crunching số. Đối với các dự án mạnh mẽ vững chắc, tôi sử dụng C #.

Bạn cần có được sự cân bằng ngay cho mục tiêu sử dụng. Càng nghiêm ngặt, bạn càng mất nhiều thời gian để viết mã, nhưng bạn sẽ có được sự mạnh mẽ hơn, khả năng sử dụng lại và dễ bảo trì hơn.

Những gì tôi tìm kiếm trong một ngôn ngữ lập trình (trái ngược với ngôn ngữ kịch bản) là tính nhất quán và gõ mạnh.

Trong các ngôn ngữ lập trình hiện tại, có thể bỏ qua dấu chấm phẩy ở một số nơi nhất định mà không trở nên mơ hồ (biểu thức cuối cùng trong một {}khối là một). Nếu một ngôn ngữ lập trình cho phép bạn bỏ qua các ký tự trong những trường hợp này, thì lập trình viên bây giờ có thêm một vấn đề; trên cùng của cú pháp ngôn ngữ chung, bây giờ cô ấy phải biết trong trường hợp nào nó cũng được phép bỏ qua các phần của cú pháp.

Kiến thức bổ sung này không có vấn đề gì đối với lập trình viên viết mã, nhưng nó trở thành gánh nặng cho bất kỳ ai phải giải thích mã hiện tại vào một thời điểm sau đó (bao gồm cả tác giả ban đầu sau một thời gian).

Ví dụ PHP của bạn mở ra khả năng cho các lỗi tinh vi trong một chương trình khi hằng số keysẽ được thêm vào trong cùng một bối cảnh. Trình biên dịch không có cách nào để biết đó không phải là ý nghĩa, vì vậy vấn đề chỉ trở nên rõ ràng khi chạy thay vì thời gian biên dịch.

Mỗi nơi có một sự mơ hồ, trình biên dịch cần có một số cách để đoán người lập trình thực sự có ý nghĩa gì. Mỗi khi điều này xảy ra, có khả năng lập trình viên thực sự có ý nghĩa khác, nhưng không có quy tắc giải quyết mơ hồ.

Viết mã chính xác là đủ khó. Thêm vào sự mơ hồ cú pháp có vẻ "thân thiện" trên bề mặt, nhưng đó là một lời mời mở để giới thiệu các lỗi mới, bất ngờ, khó gỡ lỗi vào cơ sở mã. Tóm lại, hãy nghiêm khắc nhất có thể.

Từ ví dụ của bạn, bạn đã đề cập rằng dấu chấm phẩy là tùy chọn trong Python và JavaScript. Đối với Javascript, ít nhất, điều này không hoàn toàn đúng. Dấu chấm phẩy được yêu cầu trong JS giống như trong bất kỳ ngôn ngữ gia đình C nào khác. Nhưng trình phân tích cú pháp JavaScript được yêu cầu bởi đặc tả ngôn ngữ để chèn dấu chấm phẩy bị thiếu trong các trường hợp nhất định. Điều này được coi là một điều rất xấu bởi vì nó có xu hướng làm cho ý định của bạn sai và làm hỏng mã của bạn.

Câu trả lời cho việc bạn nên thả lỏng ngôn ngữ của mình bằng với câu trả lời của câu hỏi được nói bằng giọng Texas "Bạn cảm thấy may mắn như thế nào, punk?".

Mọi người sẽ không phải làm việc quá nhiều để thống nhất mã hóa nếu các ngôn ngữ không có quá nhiều biến thể. Chúng tôi không thích nó khi người dùng thực hiện các yêu cầu làm tăng độ phức tạp một cách không cần thiết, vậy tại sao nên hỏi ngôn ngữ phát triển của chúng tôi?

Sở thích cá nhân của tôi là khả năng có đủ độ nghiêm ngặt để bắt lỗi chính tả của tôi, nhưng với càng ít nồi hơi càng tốt. Tôi nói về vấn đề này tại http://www.perlmonks.org/?node_id=755790 .

Điều đó nói rằng, bạn đang thiết kế ngôn ngữ của bạn cho chính mình. Bạn nên làm cho nó là bất cứ điều gì bạn muốn nó được.

Tôi thích ngôn ngữ của tôi để làm những gì tôi muốn nói. Nói chung là khá khó khăn về phía lỏng lẻo. Tôi cũng muốn có thể gắn thẻ "nghiêm ngặt" trên một thành phần hoặc khối để có thể gỡ lỗi / phân tích khu vực giới hạn đó.

Tôi thường có xu hướng rơi vào khía cạnh "Điều gì sẽ giúp tôi dễ dàng hơn với tư cách là một lập trình viên". Tất nhiên điều đó có thể có nghĩa nhiều hơn một điều. Trong Javascript hầu như không có kiểu kiểm tra nào, hoạt động rất tốt cho đến khi bạn gặp phải một lỗi lạ. Mặt khác, trong Haskell có rất nhiều kiểu kiểm tra, đặt nhiều công việc lên phía trước nhưng lại chặn một số lớp lỗi.

Thành thật mà nói, tôi sẽ kiểm tra một loạt các ngôn ngữ để xem những gì họ làm và cố gắng tìm một ngách mà không ai trong số họ đạt được!

Tôi không nghĩ rằng có một cách đúng đắn rõ ràng để làm điều đó, hoặc ít nhất là nếu đó không phải là điều mà mọi người đã tìm thấy sự đồng thuận. Vì vậy, bằng cách tạo ra các ngôn ngữ với các hệ thống loại khác nhau, chúng tôi đang học.

Chúc may mắn.

Tôi sẽ đề nghị rằng một ngôn ngữ lập trình tốt nên có các quy tắc nghiêm ngặt, việc triển khai sẽ được thực thi một cách nhất quán, nhưng các quy tắc nên được viết theo kiểu như vậy để có ích. Tôi sẽ đề nghị thêm rằng người ta nên xem xét việc thiết kế một ngôn ngữ để tránh các trường hợp trong đó "khoảng cách Hamming" giữa hai chương trình khác nhau đáng kể chỉ là một. Rõ ràng người ta không thể đạt được điều đó với các chữ số hoặc chuỗi (nếu một lập trình viên có nghĩa là 123 thay vì loại 1223 hoặc 13, trình biên dịch không thể biết rõ chương trình có nghĩa gì). Mặt khác, nếu ngôn ngữ được sử dụng :=để gán và ==so sánh bình đẳng, và không sử dụng một ngôn ngữ= cho bất kỳ mục đích pháp lý nào, sau đó sẽ làm giảm đáng kể các khả năng cho cả các bài tập tình cờ được coi là so sánh, và so sánh không làm gì vô tình được coi là bài tập.

Tôi sẽ đề nghị rằng trong khi có những nơi hữu ích cho trình biên dịch để suy luận mọi thứ, thì suy luận như vậy thường có giá trị nhất trong các trường hợp đơn giản nhất và ít có giá trị hơn trong các trường hợp phức tạp hơn. Ví dụ: cho phép thay thế:

  Từ điển <ComplexType1, ComplexType2> item =
    Từ điển mới <ComplexType1, ComplexType2 ()>;

với

  var item = new Dictionary <ComplexType1, ComplexType2 ()>;

không yêu cầu bất kỳ loại suy luận phức tạp nào, nhưng làm cho mã dễ đọc hơn rất nhiều (trong số những thứ khác, chỉ sử dụng cú pháp dài dòng hơn trong các tình huống cần thiết, ví dụ vì loại vị trí lưu trữ không khớp chính xác với loại biểu thức tạo ra nó, sẽ giúp gọi thêm sự chú ý đến những nơi có thể yêu cầu nó).

Một khó khăn lớn của việc cố gắng suy luận kiểu tinh vi hơn là các tình huống mơ hồ có thể xảy ra; Tôi sẽ đề xuất rằng một ngôn ngữ tốt nên cho phép lập trình viên đưa thông tin vào trình biên dịch có thể sử dụng để giải quyết sự mơ hồ đó (ví dụ: bằng cách liên quan đến một số kiểu chữ thích hợp với người khác), hãy xác định rằng chúng không quan trọng (ví dụ như mặc dù có thể có hai quá tải có thể thực thi các mã khác nhau, lập trình viên đã chỉ ra rằng họ nên hành xử giống hệt nhau trong những trường hợp có thể được sử dụng) hoặc gắn cờ những mã đó (và chỉ những mã đó) không thể được xử lý theo một trong các cách trên.

Đối với tôi, khả năng đọc là quan trọng nhất.

Đối với một người có kinh nghiệm với ngôn ngữ, ý nghĩa của một đoạn mã phải rõ ràng mà không cần phải phân tích bối cảnh sâu sắc.

Ngôn ngữ nên có thể gắn cờ các lỗi thường xuyên nhất có thể. Nếu mỗi chuỗi ký tự ngẫu nhiên tạo ra một chương trình đúng về mặt cú pháp, điều đó không hữu ích. Và nếu biến được tự động tạo ra lần đầu tiên chúng được sử dụng, sau đó lỗi chính tả clientnhư cleintsẽ không cung cấp cho bạn một lỗi biên dịch.

Bên cạnh cú pháp, ngôn ngữ nên có một ngữ nghĩa được xác định rõ ràng và có lẽ điều đó còn khó hơn cả việc quyết định một cú pháp hợp lý ...

Ví dụ hay:

• Trong Java, "1"là một chuỗi, 1là một int, 1.0là một chuỗi và 1Llà một chuỗi dài. Một cái nhìn và bạn biết nó là gì.

• Trong Java, =là sự phân công. Nó gán giá trị cho các kiểu nguyên thủy và tham chiếu cho các kiểu tham chiếu. Nó không bao giờ sao chép dữ liệu phức tạp hoặc so sánh.

• Trong Java, việc gọi một phương thức cần dấu ngoặc đơn theo cách này được phân biệt rõ ràng với các biến - vì vậy, nếu không có dấu ngoặc đơn, bạn không cần tìm kiếm định nghĩa phương thức, đó chỉ là đọc dữ liệu.

Ví dụ xấu:

• Trong Java, một biểu tượng giống như clientcó thể gần như mọi thứ: phần tử đường dẫn gói, tên lớp hoặc tên giao diện, tên lớp bên trong, tên trường, tên phương thức, biến cục bộ và thậm chí nhiều hơn nữa. Người dùng có thể giới thiệu hoặc tuân theo các quy ước đặt tên hay không.

• Trong Java, dấu chấm .được sử dụng quá mức. Nó có thể là dấu phân cách trong tên gói, dấu phân cách giữa gói và lớp, dấu phân cách giữa lớp bên ngoài và lớp bên trong, trình kết nối giữa biểu thức thể hiện và phương thức được gọi trong thể hiện và nhiều hơn nữa.

• Trong nhiều ngôn ngữ, các dấu ngoặc nhọn của các ifkhối là tùy chọn, dẫn đến những sai lầm khó chịu nếu ai đó thêm một câu lệnh nữa vào khối (không thực sự tồn tại).

• Toán tử Infix: đôi khi tôi phải dừng lại ở một biểu thức số và suy nghĩ kỹ xem nó có nghĩa là gì, từng bước một. Chúng ta đều được sử dụng để viết các biểu thức toán học trong ký hiệu infix như thế nào a * b / c * d + e. Hầu hết thời gian chúng tôi nhớ về sự ưu tiên của phép nhân và phép chia trên phép cộng và phép trừ (nhưng bạn có nhận ra rằng chúng ta không chia cho c*dmà chỉ chia cho crồi nhân với d?). Nhưng có rất nhiều toán tử bổ sung bổ sung với các quy tắc ưu tiên riêng của chúng và trong một số ngôn ngữ quá tải nên khó theo dõi. Có lẽ việc thực thi sử dụng dấu ngoặc đơn là cách tiếp cận tốt hơn ...

Bạn có thể xem xét một sự tương tự với ngôn ngữ tự nhiên. Trong email, bạn có phải là một phát xít ngữ pháp không? Hoặc bạn có ổn với một số lỗi ngữ pháp, chẳng hạn như chia nhỏ, liên kết bị thiếu hoặc sửa đổi không đúng chỗ. Câu trả lời sôi sục theo sở thích cá nhân.