Có gì tuyệt vời về Lisp? [đóng cửa]

103

Tôi không biết đủ Lisp để nói nó tốt hay xấu. Có vẻ như tất cả những người đã sử dụng Lisp đều yêu thích nó, tuy nhiên những ngôn ngữ phổ biến nhất hiện nay đều có nguồn gốc từ C.

Vậy Lisp có gì mà tuyệt vời như vậy và tại sao nó không được sử dụng nhiều hơn? Có điều gì đơn giản là xấu về Lisp (ngoài số lượng dấu ngoặc đơn không ngừng)?

lisp 
— Darrell Brogdon
nguồn
5
"Hầu hết các ngôn ngữ phổ biến ngày nay là hậu duệ của C" chỉ bề ngoài. Nếu bạn nhìn vào các tính năng thay vì chỉ sử dụng dấu ngoặc nhọn, bạn sẽ thấy rằng các ngôn ngữ hiện đại không quá xa Lisp và ngày càng gần hơn. Một chương trình trong C # hoặc Python hay Ruby, nói rằng, sẽ xem xét rất nhiều như Lisp hơn nó sẽ thích C.
— Ken
11
Một ví dụ điển hình về ngôn ngữ trông giống C nhưng hoạt động giống Lisp hơn là JavaScript. Rất nhiều thiết kế của nó tương tự như Scheme.
— JAL
Điểm tốt, Ken: ngày càng có nhiều tính năng từng là duy nhất của Lisp (các hàm hạng nhất, các hàm như dữ liệu, thậm chí cả macro) sẽ xuất hiện trong các ngôn ngữ khác. Và phản hồi không phải là một chiều: Lisp đang phát triển các kỹ thuật và thành ngữ mới để công nhận các ngôn ngữ khác (ví dụ: CLOS để đáp ứng sự thành công của mô hình hướng đối tượng).
— itowlson
6
Lisp đã lấy ý tưởng từ khắp nơi, nhưng CLOS để đáp lại những gì? CLOS (1986-1987) phần lớn là một tiêu chuẩn hóa của các hệ thống đối tượng trước đó cho Lisp, ví dụ, Lisp Machine Lisp (1980) bao gồm Hương vị. Tôi không nghĩ rằng "thành công của mô hình OO" vẫn chưa rõ ràng vào năm 1980: "C with Classes" chỉ mới được một năm (và còn 3 năm nữa mới được đổi tên thành "C ++") và tôi không biết Simula-67 đã từng rất phổ biến. Lisp có một loạt các tính năng nâng cao khác mà các ngôn ngữ phổ biến hiện nay không có; OO tình cờ đã thành công, nhưng Lisp đã không đạt được điều đó vì (hoặc khi nào) nó phổ biến.
— Ken
Tôi không nghĩ rằng tất cả những người đã sử dụng Lisp đều thích nó. Kinh nghiệm của tôi là khác nhau. Thử hỏi những sinh viên khoa học máy tính đã bắt đầu với Scheme. Có lẽ khoảng 10% sẽ thích nó, 30% sẽ tôn trọng nó và 60% sẽ ghét nó. Tôi cũng không nghĩ rằng hầu hết các ngôn ngữ phổ biến có nguồn gốc từ C.
— Rainer Joswig

Câu trả lời:

59

Lisp là Chuck Norris của các ngôn ngữ lập trình.

Lisp là thanh đo lường các ngôn ngữ khác.

Biết Lisp chứng tỏ sự khai sáng của nhà phát triển.

Tôi đã nghe nói về 3 điểm yếu (và các lập luận phản bác của chúng):

  1. Nhập động.

    Có một lập luận cho các ngôn ngữ được nhập tĩnh xoay quanh việc cung cấp cho trình biên dịch đủ thông tin để bắt một loại lỗi nhất định để chúng không xảy ra trong thời gian chạy. Nhưng bạn vẫn cần phải kiểm tra.

    Bài viết này lập luận về việc nhập động cùng với nhiều thử nghiệm hơn: Đánh máy mạnh so với Thử nghiệm mạnh .

  2. Khó nhặt.

    Thực ra có hai phần: học tập và công cụ.

    Lisp cần một số nỗ lực để thực sự "có được", nhưng nó đáng giá, bởi vì học Lisp thực sự sẽ giúp bạn trở thành một lập trình viên giỏi hơn trong các ngôn ngữ khác. Ví dụ, một khi bạn thực sự "nhận được" các bao đóng, bạn sẽ hiểu các lớp bên trong của Java. Và một khi bạn "nhận được" các chức năng hạng nhất, bạn sẽ chán nản mỗi khi sử dụng một ngôn ngữ mà không có chúng.

    Tôi đã đọc Lược đồ nhỏ và đang đọc Danh sách chung thực tế , cả hai đều xuất sắc.

    Tiếp theo là các công cụ. Tôi đang sử dụng máy Mac, vì vậy tôi đã bắt đầu sử dụng Aquamacs Emacs (làm cho Emacs có thể sử dụng được cho người mới) và Steel Bank Common Lisp (SBCL).

  3. Thiếu thư viện.

    Tôi chưa thể nói chắc chắn, nhưng tôi nghi ngờ điều đó. Để xây dựng các trang web, có vẻ như Hunchentoot và Elephant cung cấp một bộ công cụ tốt. Nhưng thực sự tôi không thấy Lispers phàn nàn về việc thiếu thư viện (có thể vì Lisp quá mạnh nên chúng không cần thiết?).

— rickmode
nguồn
4
Để giải quyết (3) - Bạn đã xem Clojure chưa?
— viksit
5
"Nhưng thực sự tôi không thấy Lispers phàn nàn về việc thiếu thư viện (có thể vì Lisp quá mạnh nên chúng không cần thiết?)." Tôi sẽ sửa câu lệnh cuối cùng thành "(có thể vì Lisp quá mạnh nên chúng không cần thiết cho chúng?)" Điều này tạo ra một sự khác biệt lớn.
— Agnius Vasiliauskas
49
Không nói một điều tại sao nói ngọng là tuyệt vời, phản đối từ tôi.
— Kilon
30
Bị phản đối vì "X thật tuyệt! X thật tuyệt! X giống Y, cũng thật tuyệt vì tôi nói nó thật tuyệt!" không phải là câu trả lời cho "Tại sao X được coi là tuyệt vời?". Tham chiếu chính trị cũng không phù hợp và vô ích (hầu hết mọi người thậm chí không nghĩ chủ nghĩa tự do là một ý kiến ​​hay). Ba điểm là hữu ích, nhưng tôi ước chúng không phải là "Nó có điểm yếu A ... Nhưng nó thực sự thậm chí không phải là điểm yếu!".
— Superbest
1
Lisp là Chuck Norris của các ngôn ngữ lập trình. vì vậy đó là những gì làm cho nó rất tốt. Hiểu rồi. Bị phản đối.
— NiCk Newman
71

“Lisp là một ngôn ngữ lập trình có thể lập trình được.”
- John Foderaro, CACM, tháng 9 năm 1991

Đây là quan điểm của tôi:

Nhìn bề ngoài, Lisp là một ngôn ngữ lập trình chức năng đơn giản, đẹp mắt. Hầu như không có cú pháp nào và tất cả các phần đều khớp với nhau theo những cách hợp lý.

Nếu bạn tìm hiểu sâu hơn một chút, đọc SICP và viết một bộ đánh giá siêu vòng, bạn sẽ phát hiện ra hai điều: Một, toàn bộ trình thông dịch (chỉ đưa ra một số nguyên thủy) chỉ là một trang mã và hai, mối quan hệ giữa mã và dữ liệu cho phép các kỹ thuật lập trình thanh lịch.

Khi bạn đã hoàn toàn tiếp thu điều này, có cảm giác như các ngôn ngữ khác đã được sắp đặt sẵn khi chúng chỉ cho phép bạn nói một vài điều. Lisp có thể xây dựng bất kỳ sự trừu tượng nào nếu bạn có thể xác định cú pháp và ngữ nghĩa cho nó.

— Josh Lee
nguồn
1
Về lý thuyết, bạn có thể nhúng bất kỳ ngôn ngữ nào vào Lisp như Rust, Ruby, C, Java, Python, Erlang. Vì vậy, phiên bản biểu thức s của Python (Hy) và của Rust được gọi là (Risp) [mặc dù tôi không biết chúng ổn định như thế nào]. Nếu bạn viết mã bằng Hy thay vì Python, bạn có khả năng macro và chỉnh sửa cấu trúc như parinfer / paredit ( shaunlebron.github.io/parinfer ). Macro cho phép bạn nhúng các DSL của riêng mình vào Lisp và chúng cũng có thể được sử dụng để chuyển mã chậm thành mã nhanh thông qua macro trình biên dịch. Bạn cũng có thể biến mã Python (Hy) thành Rust (Risp), bằng cách chuyển đổi cây sexp.
— aoeu256
Tôi cũng đã nghe câu nói này nhiều lần. Bạn có thể vui vẻ hơn một chút không @ aoeu256?
— Sinh viên
66

Lisp là tốt vì nó có một cú pháp rất tối thiểu, đơn giản, thông thường.

Lisp không tốt vì nó có cú pháp rất tối thiểu, đơn giản, thông thường.

— Daniel Earwicker
nguồn
4
Có gì xấu về một cú pháp tối thiểu, đơn giản, thông thường?
— oskarkv
27
@oskarkv - một cú pháp tối giản hoàn toàn thông thường có nghĩa là không có sự thiên vị đối với bất kỳ mục đích sử dụng cụ thể nào. Điều này nghe có vẻ tốt, cho đến khi bạn gặp phải nguyên tắc Pareto: sẽ hiệu quả hơn nếu thiên vị đối với các trường hợp thường xảy ra nhất và ngừng giả vờ rằng tất cả các trường hợp đều có khả năng xảy ra như nhau. Nếu 20% khách hàng của bạn ở NYC và 80% ở LA, có hợp lý khi ngồi trên hàng rào, một nơi nào đó trên biên giới Kansas / Oklahoma, để vẫn "không thiên vị" về mặt địa lý không? Hay ý nghĩa hơn để đi đến nơi có hầu hết khách hàng? Chúng tôi thích các ngôn ngữ làm lệch các tính năng của chúng đối với các vấn đề có thể xảy ra.
— Daniel Earwicker
4
Cú pháp Lisp thực sự tốt. Tôi học Haskell sau Clojure, nhưng ngay cả cú pháp của Haskell cũng cảm thấy như một trở ngại. Tính đồng nhất của suntax của Lisp là rất tốt. Vì vậy, tôi không biết chính xác bạn đang nói về sự thiên vị nào. Thiên về tính không linh hoạt? Nghe tệ thật.
— oskarkv
3
Nghe có vẻ tệ khi bạn đặt nó như vậy. Tôi không đặt nó như thế! Làm thế nào về sự thiên vị đối với các trường hợp phổ biến nhất, các tình huống có thể xảy ra nhất? Đây là (tất nhiên) các thuật ngữ tương đối, vì vậy nó phụ thuộc vào những gì bạn đang làm. Nếu bạn thực sự thiếu bất kỳ thông tin nào về những gì bạn sẽ làm, thì chẳng ích gì khi bạn cố gắng chuẩn bị. Nhưng điều đó có lẽ không đúng - bạn có thông tin và vì vậy bạn có thể chuẩn bị ("thiên vị") cho mình trước những tình huống có thể xảy ra nhất mà bạn cần phải sẵn sàng.
— Daniel Earwicker
22

"Bất kỳ chương trình C hoặc Fortran nào đủ phức tạp đều chứa một nửa số Common Lisp được triển khai một cách không chính thức, được chỉ định không chính thức, bị lỗi, chậm được triển khai."

Quy tắc thứ mười của Greenspun

— Paolo
nguồn
16

Dưới đây là một số liên kết hữu ích:

— Greg Hewgill
nguồn
1
Trên Lisp thì rất tuyệt (tôi mới làm được nửa chừng, mặc dù tôi thừa nhận các macro đang trở nên hơi dày đặc); nhưng bạn cần biết Lisp để đọc nó. Ngoài vấn đề nhỏ này, đó là một cuốn sách tuyệt vời không chỉ về Lisp mà còn về kỹ thuật phần mềm nói chung.
— JS
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 cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.