Liệu cú pháp có thực sự quan trọng trong một ngôn ngữ lập trình? [đóng cửa]

Một trong những giáo sư của tôi nói rằng "cú pháp là giao diện người dùng của ngôn ngữ lập trình", các ngôn ngữ như Ruby có khả năng đọc rất tốt và nó đang phát triển, nhưng chúng tôi thấy rất nhiều lập trình viên làm việc với C \ C ++, vì vậy các lập trình viên thực sự coi đó là cú pháp Có nên chấp nhận?

Tôi rất muốn biết ý kiến ​​của bạn về điều đó.

Tuyên bố miễn trừ trách nhiệm: Tôi không cố bắt đầu một cuộc tranh cãi. Tôi nghĩ rằng đây là một chủ đề thảo luận tốt.

Cập nhật: Điều này hóa ra là một chủ đề tốt. Tôi rất vui vì tất cả các bạn đang tham gia vào nó.

Có nó làm. Nếu bạn nghi ngờ, hãy dùng APL , hoặc J , hoặc Brainfuck , hoặc thậm chí là Lisp hoặc Forth đơn giản và đơn giản, và cố gắng hiểu bất kỳ chương trình không hoàn toàn tầm thường nào trên đó. Sau đó so sánh với ví dụ Python.

Sau đó so sánh cùng một Python (hoặc Ruby, hoặc thậm chí C #) với những thứ như Cobol hoặc VB6.

Tôi không cố nói rằng cú pháp lông là xấu và cú pháp giống ngôn ngữ tự nhiên là tốt trong mọi trường hợp. Nhưng cú pháp obvoiusly không tạo ra sự khác biệt lớn. Nói chung, tất cả mọi thứ bạn có thể viết bằng ngôn ngữ lập trình đẹp nhất bạn cũng có thể viết dưới dạng chương trình máy Turing - nhưng bạn thường không muốn, phải không?

Trong thực tế tôi nghĩ rằng nó có vấn đề. Khả năng đọc đã được thảo luận ở trên. Một vấn đề khác có thể là có bao nhiêu tổ hợp phím được neded để thể hiện một ý tưởng / đại số? Tuy nhiên, một vấn đề khác là việc các lỗi đánh máy đơn giản trở nên dễ dàng như thế nào đối với mắt người, và chúng có thể gây ra bao nhiêu trò nghịch ngợm.

Tôi cũng thấy nó hữu ích trong một số bối cảnh để phân tích và / hoặc để tạo các đoạn mã thông qua một chương trình máy tính khác. Khó khăn trong việc phân tích ngôn ngữ và / hoặc tạo mã chính xác sau đó ảnh hưởng trực tiếp đến việc cần bao nhiêu nỗ lực để tạo / duy trì các công cụ đó.

Tôi tin rằng giáo sư của bạn đang đề cập đến đường Syntactic .

Đường cú pháp là một thuật ngữ khoa học máy tính dùng để chỉ cú pháp trong một ngôn ngữ lập trình được thiết kế để làm cho mọi thứ dễ đọc hoặc diễn đạt hơn, trong khi các cách khác để diễn đạt chúng tồn tại .

Vì vậy, điều mà giáo sư của bạn ngụ ý, là bất kỳ mã / cú pháp nào được viết bằng một ngôn ngữ lập trình, đều có thể được diễn đạt bằng các ngôn ngữ khác giống nhau - hoặc thậm chí cùng một ngôn ngữ.

Robert Martin, lấy từ định lý Lập trình có cấu trúc , đã tóm tắt những gì lập trình viên về cơ bản với các ngôn ngữ lập trình tại bài phát biểu của mình tại RailsConf 2010: Robert Martin (video trên YouTube, xem sau 14 phút, mặc dù tôi khuyên bạn nên làm toàn bộ):

• Trình tự (bài tập)
• Lựa chọn (nếu báo cáo)
• Lặp lại (vòng lặp)

Đó là tất cả các lập trình viên làm, từ ngôn ngữ lập trình này sang ngôn ngữ lập trình khác, chỉ trong một cú pháp hoặc giao diện người dùng (UI) khác nhau. Đây là những gì tôi đoán giáo sư của bạn đã nhận được, nếu anh ấy / cô ấy đang nói một cách trừu tượng về ngôn ngữ lập trình.

Vì vậy, về bản chất , cú pháp không thành vấn đề . Nhưng nếu bạn muốn cụ thể, thì rõ ràng một số ngôn ngữ và cú pháp phù hợp hơn cho các tác vụ nhất định so với các tác vụ khác, nhờ đó bạn có thể lập luận rằng cú pháp có vấn đề.

Có và không.

Có một vài khía cạnh khác nhau về cú pháp.

• khả năng đọc
• biểu cảm
• phân tích cú pháp

Khả năng đọc đã được đề cập.

Biểu cảm là một trường hợp thú vị. Tôi sẽ sử dụng chức năng truyền qua làm ví dụ, bởi vì đó là một điểm đau của ngữ nghĩa / cú pháp.

Hãy lấy C ++ làm ví dụ. Tôi có thể tạo một chức năng đặt hàng đầu tiên sau thời trang này:

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

Thành ngữ đặc biệt này thường được sử dụng trong Các yếu tố lập trình của Stepanov .

Mặt khác, tôi có thể bắt chước nó trong Common Lisp với một cái gì đó như thế này :

(defun myfunc() )

(defun run_func(fun)
  (fun))

Hoặc, trong Perl -

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

Hoặc, bằng Python -

def myfunc():
    pass

def run_func(f):
    f()

Tất cả đều có - về cơ bản - cùng một nội dung ngữ nghĩa, mặc dù ví dụ C ++ mang một số siêu dữ liệu loại. Ngôn ngữ nào thể hiện ý tưởng vượt qua chức năng bậc cao là tốt nhất? Lisp thông thường hầu như không tạo ra một biến thể cú pháp. C ++ yêu cầu một lớp được tạo chỉ để 'thực hiện' chức năng. Perl khá đơn giản về việc tạo ra một số mức độ khác biệt. Python cũng vậy.

Cách tiếp cận nào phù hợp nhất với miền vấn đề? Cách tiếp cận nào tốt nhất có thể diễn tả những suy nghĩ trong đầu bạn với "sự không phù hợp trở kháng" ít nhất?

Khả năng phân tích là - trong tâm trí của tôi - một vấn đề lớn. Cụ thể, tôi đề cập đến khả năng phân tích và cắt ngôn ngữ của IDE mà không mắc lỗi. Định dạng lại là hữu ích. Các ngôn ngữ được phân tách bằng mã thông báo có xu hướng phân tích tốt - ruby ​​/ c / pascal, v.v.

Hãy xem xét mặc dù - các hệ thống chính của tất cả các loại đã được tạo ra với mọi ngôn ngữ nghiêm túc để giải quyết các vấn đề trong thế giới thực. Mặc dù cú pháp là một rào cản để diễn đạt một số thứ, nhưng nó là một rào cản có thể giải quyết được. Turing tương đương và tất cả những thứ đó.

Cú pháp chắc chắn có vấn đề, mặc dù bạn có xu hướng chú ý đến nó nhiều hơn khi nó không trực quan và khuyến khích các lỗi. Ví dụ, trò đùa "lỗi cuối cùng của thế giới" khét tiếng:

if (AlertCode = RED)
   {LaunchNukes();}

Cú pháp có vấn đề và tôi có thể cung cấp cho bạn hai ví dụ hỗ trợ: Dylan, đó là một Lisp với cú pháp thông thường hơn và Liskell, đó là Haskell với cú pháp giống Lisp. Trong mỗi trường hợp, một biến thể của ngôn ngữ đã được đề xuất có chính xác cùng một ngữ nghĩa, nhưng cú pháp hoàn toàn khác nhau.

Trong trường hợp của Dylan, người ta đã nghĩ rằng việc bỏ các biểu thức s có lợi cho một cái gì đó thông thường hơn sẽ giúp thu hút một loạt các lập trình viên. Hóa ra cú pháp không phải là điều duy nhất ngăn các lập trình viên sử dụng Lisp.

Trong trường hợp của Liskell, người ta đã nghĩ rằng sử dụng biểu thức s sẽ cho phép sử dụng macro dễ dàng hơn. Hóa ra các macro thực sự không cần thiết trong Haskell, vì vậy thử nghiệm đó cũng không hoạt động.

Đây là điều: nếu cú ​​pháp không quan trọng với bất kỳ ai, thì cả hai thử nghiệm đều không được thử.

Câu trả lời có thể là phân tách "vấn đề" thành yếu tố máy tính và yếu tố con người . Có rất nhiều yếu tố con người trong cú pháp:

• Dễ đọc
• Cô đọng
• Bảo trì
• sư phạm
• Phòng ngừa lỗi
• Sự phù hợp cho mục đích - đó là ngôn ngữ REPL, ngôn ngữ kịch bản hay ngôn ngữ hệ thống lớn?

Đối với máy tính có liên quan, vấn đề duy nhất của cú pháp là có hay không có sự mơ hồ cần được giải quyết, và mất bao nhiêu thời gian để mã hóa / phân tích mã khi biên dịch / phiên dịch - và chỉ trong trường hợp đó sau này trong đó chi phí phân tích cú pháp là một vấn đề quan trọng.

Đó có thể là lý do tại sao bạn sẽ luôn nhận được câu trả lời "có và không" cho câu hỏi này - bởi vì có hai khía cạnh của nó.

Nếu không có cú pháp, chúng ta sẽ không có một "khuôn mẫu" chung để giao tiếp, ở cấp độ con người, mục đích của một khối mã. Cú pháp cung cấp một khung chung để từ đó trình biên dịch có thể được tiêu chuẩn hóa; phương pháp có thể được chia sẻ; bảo trì có thể được đơn giản hóa.

Tôi nghĩ điều thực sự quan trọng là quyền truy cập API và tính khả dụng của chức năng cấp thấp (như kiểm soát bộ nhớ và khóa) khi cần. Hầu hết các ngôn ngữ khác đi kèm với các tính năng này bao gồm. Vấn đề là, khi bạn cần chức năng bổ sung, bạn thường phải sử dụng một ngôn ngữ như C để thực hiện nó. Và nó cồng kềnh giao tiếp C với ngôn ngữ bạn đang sử dụng.

Đối với mọi thứ trừ phát triển web (và toán học) tôi đã thấy rằng C / C ++ vẫn là ngôn ngữ của một hệ điều hành và một ứng dụng. Đó là những gì được hỗ trợ hầu hết thời gian để phát triển ứng dụng đa nền tảng, tạo mẫu, đa nền tảng thực sự. Và cú pháp của C là được. Chỉ cần rất đơn giản và tương đối dài dòng. Cú pháp tuyệt vời không thực sự quan trọng đến thế. Tính khả dụng của API và API Tất cả chúng ta cần phải giao tiếp với mã của người khác (phần lớn thời gian được viết bằng C hoặc các dẫn xuất của nó).

Cú pháp chắc chắn có vấn đề. Nó cực kỳ có giá trị nếu cú ​​pháp ngôn ngữ đủ linh hoạt để cho phép bạn tạo một Ngôn ngữ cụ thể theo miền thuận tiện và dễ đọc cho ứng dụng của bạn. Nếu bạn nghi ngờ điều này, chỉ cần tưởng tượng làm các vấn đề đại số trong tiếng Latin prosaic, như nó đã được thực hiện trước thế kỷ 18, hoặc tưởng tượng làm phép tính mà không có ký hiệu Leibniz quen thuộc. Chắc chắn, một văn bản tính toán không thể đọc được đối với người mới, nhưng với thực tế, chúng ta có thể sử dụng phép tính và ký hiệu Leibniz để giải quyết nhanh chóng một lớp các vấn đề đòi hỏi các trang toán học bằng phương pháp cổ điển. Lập trình chỉ là một chút khác của toán học. Một ký hiệu thuận tiện, gần với miền vấn đề, có thể tạo ra sự khác biệt lớn về năng suất.

Đây là một chương trình tính toán khoa 6:

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

Cú pháp là tối thiểu:

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

Dường như có một niềm tin phổ biến rằng cú pháp là điều gây khó khăn cho một ngôn ngữ. Như thường thấy với niềm tin thường được tổ chức, chính xác điều ngược lại là đúng.

Lưu ý rằng cú pháp LISP chỉ có thể đọc được (nếu có) vì nó có cú pháp nhiều hơn so với cú pháp ở trên. Vì vậy, nếu người hâm mộ LISP nói với bạn rằng "cú pháp không thành vấn đề", hãy yêu cầu họ làm hệ quả và thử tính toán SKI. Rốt cuộc họ sẽ phải thừa nhận rằng một cú pháp bit không quá tệ.

Tôi không nghĩ nó quan trọng ngoài sở thích cá nhân. Tất cả mọi thứ (hiệu suất, khả năng, v.v.) đều bằng nhau sau đó tôi có thể thấy lý do tại sao người ta sẽ đặt trọng số lớn hơn vào cú pháp ngôn ngữ nhưng chọn chuyển qua hiệu suất của các ngôn ngữ như c / c ++ hoặc bất kỳ ngôn ngữ nào khác phù hợp hơn cho công việc chỉ vì cú pháp có vẻ như là một ý tưởng tồi xung quanh.

Vâng, vấn đề cú pháp, mặc dù thực sự chỉ cho khả năng đọc. So sánh:

for i in range(10):
   print(i)

(Vâng đó là Python) với

FOR(i<-RNG-<10){PRN<-i}

(Vâng, đó là ngôn ngữ tôi vừa tạo) Cả hai sẽ thực hiện chính xác cùng một cách, theo cùng một cách, nhưng cú pháp thì khác và Python dễ đọc hơn. Vì vậy, có, cú pháp chắc chắn có vấn đề. Ngay cả vấn đề "đường tổng hợp".

 @property
 def year(self):
     return self._date.year

Dễ đọc hơn

 def year(self):
     return self._date.year
 year = property(year)

Chắc chắn.

Nếu bạn muốn bắt đầu một ngọn lửa lớn, hãy hỏi mọi người, nơi họ đặt bracet mở đầu bằng các ngôn ngữ giống như C. Ý tôi là

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

hoặc thậm chí VS

void foo() 
{ // blah
}

Và đây chỉ là cùng một ngôn ngữ! Ngoài ra, hãy hỏi họ về không gian, nơi họ đặt chúng (tên hàm và bracet, toán tử, v.v.).

1000 câu trả lời được đảm bảo!

Cú pháp không thành vấn đề. Tuy nhiên trong thời đại ngày nay tôi nói nó gần như hoàn toàn vì khả năng đọc và không thực sự về số lượng tổ hợp phím cần thiết. Tại sao?

• Trừ khi bạn thực sự viết một cái gì đó đơn giản, nếu số lượng phím bạn nhấn là yếu tố hạn chế trong việc viết chương trình thì bạn thực sự, thực sự tào lao khi gõ hoặc suy nghĩ nhiều, quá nhanh.
• Tất cả các IDE tốt ngày nay có một số lượng lớn các phím tắt có nghĩa là bạn không cần phải thực sự loại bỏ tất cả các ký tự bạn đang sử dụng hầu hết thời gian.

Điều đó nói rằng, nếu nó quá dài dòng thì nó có thể đi đến điểm ảnh hưởng đến khả năng đọc. Tôi muốn thấy một cái gì đó như:

foreach (Chuỗi trong chuỗiList)

Đến:

cho mỗi Chuỗi trong danh sách được tham chiếu bởi biến danh sách chuỗi

...bất kỳ ngày nào!

Cú pháp quan trọng đối với những người đang học nó, rào cản gia nhập ngôn ngữ càng phổ biến ban đầu càng thấp. Nhưng nếu ngôn ngữ khó hoặc không thể thể hiện bản thân của bạn một cách phong phú và cô đọng, nó sẽ bắt đầu khô héo về mức độ phổ biến.

Rất ngắn gọn và mờ đục (Perl) cũng tệ như quá dài dòng và dài dòng (AppleScript).

Cần phải có sự cân bằng, rào cản thấp hơn để nhập cảnh, năng suất cao và bảo trì dễ dàng.

Một điều khác cần xem xét là các ngôn ngữ lập trình với cú pháp đẹp hơn sẽ dễ phân tích cú pháp hơn, do đó làm cho trình biên dịch dễ viết hơn, nhanh hơn và ít bị lỗi hơn.

Nói một cách đơn giản: cú pháp như vậy không thành vấn đề. Các ngữ nghĩa bạn có thể thể hiện thông qua nó quan trọng.