Cú pháp của Clojure có thực sự đơn giản hơn Scala không? [đóng cửa]


8

Đối số luôn được đưa ra có lợi cho Clojure là vậy.

Cú pháp đơn giản hơn và chỉ có một cách để thể hiện mã mà không có quy tắc phức tạp.

Tuy nhiên Scala có vô số loại cú pháp và cấu trúc khác nhau so với Clojure.

Nhưng từ một tuần trước khi cố gắng học Clojure, tôi đã nhận thấy rằng danh sách các macro sẵn có là vô tận, mặc dù chúng ta viết chúng với cùng một cú pháp dấu ngoặc đơn, chúng ta cần tìm hiểu cách thức hoạt động của từng loại.

Vậy theo nghĩa nào thì cú pháp của Clojure đơn giản hơn? Đối với LISPers thì có thể nhưng đối với những người từ một nền tảng khác, việc học các cấu trúc khác nhau trong Scala có vẻ đơn giản hơn.

Vậy theo quan điểm trung lập, cú pháp nào đơn giản và dễ đọc hơn?


6
Nếu bạn nhìn vào tiêu chuẩn Scala, ngữ pháp của nó dài 7 trang. nhiều như tôi thích Scala, nó không có cú pháp đơn giản hơn lisp.
Daniel Gratzer

Câu trả lời:


18

Vậy theo quan điểm trung lập, cú pháp nào đơn giản và dễ đọc hơn?

Đó là hai câu hỏi rất khác nhau.

Đơn giản hơn có nghĩa là "bao gồm ít bộ phận hơn". Cú pháp của Clojure có ít quy tắc hơn, nhưng nó đơn giản hơn so với Scala.

Khả năng đọc , tuy nhiên, là chủ quan. Nó chủ yếu đi xuống để làm quen . Ví dụ, tôi thấy ECMAScript, C #, Java, D, Go, C ++ và C gần như không thể hiểu được, nhưng đối với một người đã quen đọc loại cú pháp đó, họ có thể đọc được. Phần này của câu hỏi không thể được trả lời một cách khách quan hoặc "từ quan điểm trung lập".


5
+1: "Tuy nhiên, khả năng đọc là chủ quan. Nó chủ yếu bắt nguồn từ sự quen thuộc.": Đúng. Gần đây tôi đã chơi với Scheme và Common Lisp (tôi không phải là chuyên gia trong số họ) và tôi không hiểu tại sao cú pháp của họ bị coi là khó đọc: rất dễ để làm quen với nó.
Giorgio

cú pháp có ít quy tắc hơn, nhưng sau đó một lần nữa học đường cong vẫn giống như bạn vẫn phải học các macro khác nhau, theo cách bạn phải học các cấu trúc khác nhau. Ngay cả khi chúng được viết bằng sam eset của các biểu tượng.
Amogh Talpallikar

Có, nhưng câu hỏi là về cú pháp, không phải ngữ nghĩa. Nếu đó là những gì bạn muốn biết, bạn nên làm rõ câu hỏi của bạn.
Jörg W Mittag

1
+1: Đây là một câu trả lời hay cho câu hỏi của OP. Thật thú vị, tuy nhiên, ý tưởng rằng khả năng đọc là hoàn toàn chủ quan là một huyền thoại phổ biến. Thật hợp lý khi đề xuất rằng, với kinh nghiệm tương tự của hai ngôn ngữ khác nhau, một ngôn ngữ có thể dễ đọc hơn so với ngôn ngữ kia, ít nhất là theo thống kê. (Ví dụ, hãy xem xét những ngôn ngữ bí truyền rất khó đọc ngay cả khi bạn biết chúng khá rõ.) Thật không may, tôi không biết về bất kỳ nghiên cứu nào về vấn đề này.
Kramii

1
@Kramii: Tôi có nhiều năm kinh nghiệm với C ++ và một vài tháng kinh nghiệm với Common Lisp, và tôi thấy CL dễ đọc hơn nhiều so với C ++. Điều này cũng cho thấy Common Lisp dễ đọc hơn C ++ một cách khách quan, hoặc cách suy luận của tôi gần với cách CL hoạt động. Hoặc có thể nó chỉ chứng minh không có gì cả.
Giorgio

4

Khi tôi làm việc ở Scala, thường có một giai đoạn phát triển của tôi (đặc biệt là với forsự hiểu biết) trong đó tôi phải làm cho tất cả các loại hoạt động chính xác, đó là một điểm cộng lớn cho các dự án lớn, nhưng tiêu cực nhất định cho các dự án nhỏ. Tôi đã dự đoán rằng tôi chỉ có thể quên các loại và tập trung vào "hoàn thành công việc" trong Clojure theo cách tôi mơ hồ nhớ làm trong Perl hoặc Awk, nhưng cho đến nay nó vẫn chưa thành công với tôi. Kinh nghiệm của tôi là thay vì "làm cho các loại hoạt động được" trong giai đoạn mã / biên dịch, tôi gặp ngoại lệ khi tôi cố chạy mã của mình. Đây không phải là một sự đơn giản hóa; vấn đề chưa biến mất, nó mới chuyển sang một phần nguy hiểm / tốn kém hơn trong chu kỳ phát triển.

một sự đơn giản thú vị để cú pháp Lisp-ish. Một trong những thế mạnh lớn của Emacs là có thể thực thi mã lisp tùy ý bằng cách nhấn một chuỗi khóa đặc biệt ở vị trí đóng của một khối mã bất cứ lúc nào trong bất kỳ bộ đệm nào. Bản chất phân tách dấu ngoặc đơn giản của cú pháp lisp làm cho thanh lịch này theo cách sẽ gây khó xử (phải giới thiệu dấu ngoặc nhọn?) Trong hầu hết các ngôn ngữ khác. Ngoài ra, tính thường xuyên (function arg, arg...)(operator arg, arg...)làm cho suy nghĩ về các hàm và toán tử là công dân hạng nhất và suy nghĩ về các hàm ẩn danh rất tự nhiên, theo cách mà các toán tử infix của các ngôn ngữ khác như Scala không làm được.

Kinh nghiệm hạn chế của tôi với Scala ngăn tôi nói rằng cú pháp đơn giản hơn hoặc dễ đọc hơn. Chắc chắn, có một số cú pháp không cần thiết trong Clojure bằng cách sử dụng macro, nhưng nhận thức của tôi là các macro này chỉ mở một cửa sổ nhỏ vào suy nghĩ bắt buộc trong một cú pháp rất khác là chức năng. Áp dụng một ưu tiên cho cú pháp chức năng hoặc mệnh lệnh trong ngôn ngữ có thể đơn giản hóa mọi thứ. Tôi sẽ phải đưa ra một điểm cho Clojure, Java và Haskell cho việc này.

Mối quan tâm của tôi với Scala là mối quan tâm tương tự tôi có với C ++ hoặc Perl (mặc dù ở mức độ thấp hơn); cú pháp của ngôn ngữ chứa một số kiểu suy nghĩ khác nhau (Haskell và Java). Điều này làm cho nó thú vị để viết, nhưng có thể có vấn đề về khả năng đọc. Ngay cả khi tôi viết điều đó, tôi nhớ rằng Clojure hỗ trợ Ngôn ngữ cụ thể của miền và tự hỏi đến mức độ nào làm suy yếu quan điểm của tôi.

Câu hỏi của bạn là một câu hỏi rất thú vị. Cuối cùng, so sánh là một phức tạp. Nhưng dựa trên kiến ​​thức hiện tại của tôi, tôi sẽ phải đồng ý rằng cú pháp của Clojure đơn giản hơn Scala, nhưng có lẽ không phải là toàn bộ thứ tự cường độ đơn giản hơn.


3

Mặc dù chúng tôi viết chúng với cú pháp dấu ngoặc đơn giống nhau

Và đó cơ bản là câu trả lời cho câu hỏi của bạn.

chúng ta cần học cách làm việc của từng người

Mặc dù có thể giới thiệu DSL với cú pháp không quá phức tạp như Common Lisps loopsử dụng macro thông thường (tôi sẽ bỏ macro người đọc ra khỏi điều này), chúng chủ yếu được sử dụng để kiểm soát đánh giá và vẫn sẽ sử dụng cú pháp biểu thức s thông thường. Một tính năng quan trọng là ngay cả các loopmacro giống như phức tạp hơn cũng có thể được đọc bằng cùng một trình đọc sexpr cũ.

Mặc dù đúng là bạn sẽ phải tìm hiểu về các macro khác nhau và hình thức nhập liệu mà chúng sử dụng, hãy nói Common Lisp condvới condviệc giảm bớt một lớp lồng của nó so với Clojure , nó không chỉ giữ cho macro, mà còn cho chức năng thường xuyên. Hãy tưởng tượng một hàm thông thường lấy một danh sách trích dẫn của một cấu trúc cụ thể làm đối số - bạn vẫn sẽ phải tuân theo cấu trúc đầu vào dự kiến, cho dù hàm đó có biến đổi mã hay không, mong đợi một loại nào đó tồn tại, plist, cây hoặc một cái gì đó hoàn toàn khác.

Bất cứ khi nào bạn gặp chức năng mới, sẽ có một số API bạn sẽ phải học. Điều đó cũng sẽ áp dụng cho một ngôn ngữ chỉ cho phép function(arg1, arg2, …, argN)cú pháp nghiêm ngặt - bạn vẫn phải tìm hiểu các đối số dự kiến ​​là gì, tác dụng phụ xảy ra và đầu ra của bất kỳ chức năng nào là gì.

Điều dễ dàng hơn về cú pháp Lisp so với một ngôn ngữ như Scale, là mọi thứ được thể hiện ít nhiều giống nhau và chính mã đã sử dụng các biểu diễn và cấu trúc dữ liệu này (đó sẽ là tính đồng nhất mà mọi người đang nói đến). Sự khác biệt về độ phức tạp cú pháp này sẽ trở nên khá rõ ràng nếu bạn cố gắng viết một trình phân tích cú pháp Lisp hoặc Clojure và sau đó là một trình phân tích cú pháp Scala. Bạn sẽ phải đối phó với một ngữ pháp phức tạp hơn nhiều - các quy tắc phức tạp hơn liên quan đến quyền ưu tiên, khoảng trắng, sự mơ hồ, nhiều ngoại lệ, v.v.


3

Từ định nghĩa wikipedia :

Trong khoa học máy tính, cú pháp của ngôn ngữ lập trình là tập hợp các quy tắc xác định các tổ hợp ký hiệu được coi là chương trình có cấu trúc chính xác trong ngôn ngữ đó

Vì clojure là một lisp, bạn có biểu thức s + danh sách các macro người đọc và đó là tất cả.

Trong scala, bạn có các lớp, lớp trường hợp, lambda ẩn với _, từ khóa ẩn, đặc điểm, chú thích chung, chú thích phương sai, v.v.

Clojure có cú pháp đơn giản hơn vì các tính năng có thể được triển khai dưới dạng macro hoặc các hình thức đặc biệt. Điều này là không thể với scala, anh ta phải thêm cú pháp để hỗ trợ một số tính năng.


-1

Macro không có cú pháp.

Lập luận hệ sinh thái hoặc phức tạp thư viện cơ bản là một cuộc thảo luận hoàn toàn khác nhau.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.