Tại sao Lisp không phổ biến hơn? [đóng cửa]

Tôi đang bắt đầu tìm hiểu Scheme bằng các video SICP và tôi muốn chuyển sang Common Lisp tiếp theo.

Ngôn ngữ có vẻ rất thú vị, và hầu hết mọi người viết sách về nó đều ủng hộ rằng nó có sức mạnh biểu cảm vô song. CL dường như có một thư viện tiêu chuẩn phong nha.

Tại sao Lisp không phổ biến hơn? Nếu nó thực sự mạnh mẽ như vậy, mọi người nên sử dụng nó khắp nơi, nhưng thay vào đó, gần như không thể tìm thấy, giả sử, quảng cáo việc làm Lisp.

Tôi hy vọng nó không chỉ là dấu ngoặc đơn, vì chúng không phải là một vấn đề lớn sau một thời gian ngắn.

Tính biểu cảm không phải lúc nào cũng là một đặc điểm ngôn ngữ tích cực trong môi trường doanh nghiệp. Java cực kỳ phổ biến một phần vì nó dễ học, dễ viết và dễ đọc. Các lập trình viên tầm thường vẫn có thể làm việc rất hiệu quả trong Java, ngay cả khi mã của họ dài dòng và không phù hợp.

Hơn nữa, thật dễ dàng để lạm dụng các ngôn ngữ biểu cảm. Một lập trình viên java chuyên gia có thể cấu trúc lại mã viết kém một cách nhanh chóng. Ngôn ngữ càng biểu cảm, càng khó hiểu và tái cấu trúc mã khủng khiếp. Các macro LISP là một ví dụ tốt. Macro là công cụ mạnh mẽ trong tay phải. Trong tay sai, chúng có thể dẫn đến mã khó hiểu và khó gỡ lỗi.

LISP là một lựa chọn rủi ro cho quản lý cấp cao. Nếu mọi thứ trở nên sai lầm, không ai sẽ đổ lỗi cho ban quản lý vì đã chọn một ngôn ngữ hướng đối tượng phổ biến được hỗ trợ bởi một tập đoàn lớn như Oracle hay Microsoft. Dễ dàng hơn nhiều để thuê các lập trình viên có kinh nghiệm trong các ngôn ngữ phổ biến, dễ học.

Ngay cả các công ty tiến bộ sẵn sàng sử dụng ngôn ngữ mạnh hơn thường không chọn LISP. Điều này là do nhiều ngôn ngữ mới hơn cố gắng và thỏa hiệp bằng cách mượn các tính năng mạnh mẽ từ LISP, trong khi vẫn dễ học cho đại chúng. Scala và Ruby theo mô hình này. Các lập trình viên xấu có thể nhận chúng một cách nhanh chóng và tiếp tục viết cùng một mã tầm thường mà họ đã làm trong Java. Lập trình viên giỏi có thể tận dụng các tính năng nâng cao hơn để viết mã đẹp.

Dấu ngoặc đơn không phải là vấn đề. Haskell là một ngôn ngữ cực kỳ mạnh mẽ và biểu cảm với cú pháp tương tự như Python hoặc Ruby và nó không được sử dụng rộng rãi vì nhiều lý do tương tự như LISP.

Mặc dù tất cả điều này, tôi hy vọng ...

Clojure có cơ hội trở nên phổ biến. Nó chạy trên JVM, có khả năng tương tác tuyệt vời với Java và làm cho việc lập trình đồng thời trở nên đơn giản hơn nhiều. Đây là tất cả những điều quan trọng đối với nhiều công ty.

* Đây là quan điểm của tôi với tư cách là một lập trình viên JVM chuyên nghiệp có kinh nghiệm về Java, Clojure, JRuby và Scala.

Tại sao Lisp không phổ biến hơn? Nếu nó thực sự mạnh đến thế, mọi người nên sử dụng nó khắp nơi,

Nếu bạn tin rằng các ngôn ngữ được chọn vì giá trị kỹ thuật của chúng, thì bạn đang ở trong một sự thất vọng tan nát tâm hồn.

Những quyết định như vậy được đưa ra dựa trên Vũ nữ thoát y và Steaks . Microsoft có thể đủ khả năng cho họ. Oracle có thể. Sun đã chi quá nhiều tiền cho việc thổi phồng Java đến nỗi họ phá sản. Hai lần. Một cộng đồng tình nguyện phi tập trung, không đồng nhất, không thể cạnh tranh với điều đó.

nhưng thay vào đó, gần như không thể tìm thấy, giả sử, quảng cáo việc làm Lisp.

Thật thú vị, các công ty Lisp nói hoàn toàn ngược lại: họ liên tục có cơ hội việc làm nhưng không thể tìm đủ người để lấp đầy. (Điều tương tự áp dụng cho Haskell, ML, O'Caml, Forth, Smalltalk, ...)

Tôi không có kinh nghiệm làm việc cho một công ty thực sự, nhưng tôi biết tại sao LISP khó sử dụng cho tôi.

Trước hết, điều này làm tôi nhớ đến bài đăng trên blog này: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

Vấn đề chính mà tôi gặp phải với Lisp là câu hỏi "mà Lisp". Tôi thường làm việc trên Linux như là nền tảng chính của mình, nhưng những thứ tôi cần phải tương thích với Windows. Điều đó có nghĩa là khi tôi đánh giá một công nghệ sẽ sử dụng, nó phải làm cho cuộc sống của tôi trở nên dễ dàng khi làm việc trên hai hệ điều hành hoàn toàn khác nhau. Tôi không thích yêu cầu này, nhưng để sử dụng nó cho một dự án thực sự là một yêu cầu. Bây giờ tôi sẽ sử dụng các ngôn ngữ không hỗ trợ rất tốt trên Windows cho các dự án cá nhân của riêng tôi, nhưng vì tôi không bao giờ có cơ hội viết một dự án phần mềm lớn trong đó, nên tôi không có kinh nghiệm cần thiết.

Bây giờ khi tôi đang cố gắng học một ngôn ngữ chức năng, tôi thực sự muốn học Common Lisp. Có vẻ như điều đúng đắn phải làm. Tôi bắt đầu đọc Lisp thực tế như một điểm xuất phát vì tôi thực sự không biết các chức năng tích hợp sẵn và cần một dự án để làm việc ở Lisp. Biểu cảm S rất đẹp và dễ dàng. Tất cả những dấu ngoặc đơn đó là vô cùng đẹp đối với tôi vì nó rõ ràng như ngày chính xác những gì đang xảy ra trong mã.

Vì vậy, tôi cố gắng viết chương trình đầu tiên của tôi ở Lisp bên ngoài cuốn sách. Tôi muốn có một công cụ dòng lệnh sẽ đếm các dòng mã và loại bỏ các dòng tầm thường khỏi số đếm mã. Không phải là công cụ hữu ích nhất, nhưng thú vị để làm. Nó liên quan đến truy cập tệp, một chút phân tích cú pháp và đếm. Tôi đã triển khai cùng một công cụ trong Python khoảng một tuần trước.

Tôi cần truy cập các đối số dòng lệnh. Sau đó, tôi học được rằng không có cách tiêu chuẩn để có được các đối số dòng lệnh. Chúng đều là những tính năng không chuẩn. Nó hoàn toàn không phải là đa nền tảng. Nó hầu như trở nên tồi tệ hơn từ đó vì ngôn ngữ không có nhiều thư viện được tích hợp trong đó. Tôi đã kết thúc việc chuyển sang Haskell và không đi sâu vào Common Lisp (vì vậy những khiếu nại của tôi thậm chí có thể không hợp lệ).

Loại điều không chuẩn này luôn là nỗi đau đối với tôi trong quá khứ. C ++ có vấn đề tương tự, nhưng với các thư viện như Boost, bạn có thể khắc phục những điểm yếu đó.

Điều này cũng không giúp ích gì cho cú pháp Lisp cho mọi thứ khác ngoài biểu thức S là một chút xấu xí.

IMO, chủ yếu là do:

• Hỗ trợ thư viện kém. Chắc chắn, bây giờ có Quicklisp, giúp cài đặt thư viện dễ dàng, nhưng nó không bù cho chúng vẫn còn khá ít, và một số ít được ghi chép kém hoặc không được bảo trì tốt. So với Python, rất có thể việc viết ứng dụng Lisp không tầm thường (bất kể phương ngữ cụ thể nào) có thể vẫn sẽ liên quan đến việc phát minh lại ít nhất một phần của một hoặc hai bánh xe.
• Thiếu sự quen thuộc với mô hình được thông qua bởi các công cụ phát triển. Hầu hết những người tôi biết đều khá sợ hãi khi phải sử dụng SLIME và Emacs, điều này có thể hiểu được đối với những người đã sử dụng Eclipse và Visual Studio. Có hai plugin Eclipse tôi nghĩ, tôi chỉ thử một trong số chúng vài năm trước và nó khá là lỗi. Toàn bộ hệ sinh thái Lisp trông giống như bị kẹt giữa chừng khi nó là một phần của hệ thống chạy Lisp hoàn chỉnh và tiêu chuẩn hiện đại của ngôn ngữ oh-it-other-ngôn ngữ khác. Học Lisp không bị giới hạn trong việc học một ngôn ngữ mới - bạn cũng cần học một cách làm việc và suy nghĩ hoàn toàn khác, và trong khi điều này ổn nếu bạn làm nó như một sở thích, thì có đáng nghi ngờ không? kinh doanh.

Mọi thứ bắt đầu có vẻ tốt hơn một chút, đặc biệt là với Clojure đang ở xung quanh.

Tôi đã học LISP một tỷ năm trước ở trường đại học.

LISP, giống như FORTH, rất tốt cho logic. Nhưng hầu hết lập trình không phải là về logic, mà là về việc thao túng dữ liệu theo những cách cơ học nhàm chán. Ví dụ, tại thời điểm đó, không có cách nào để chứng minh đúng đầu ra số.

LISP là về chức năng lồng nhau và mọi người không nghĩ như vậy. Họ nghĩ theo các khía cạnh DO A, B, C, D, sau đó E. Không làm A, liên quan đến việc làm B và C, sau đó D và E. Điều này liên quan đến một loại đồng thời gây nhầm lẫn. Ngoại trừ các nhiệm vụ được xác định trước như "nộp tờ khai thuế thu nhập", mọi người không nghĩ đồng thời, họ nghĩ theo tuần tự. Đây là lý do tại sao các ngôn ngữ thủ tục chiếm ưu thế ngày nay.

Kết quả là, mã produral thích Java và C có thể được dịch sang tiếng Anh một cách dễ dàng. Mã LISP không thể; không có ngôn ngữ của con người được cấu trúc theo cách đó.

Vì vậy, thật tuyệt vời khi giải quyết vấn đề, nhưng giải quyết vấn đề không quan trọng lắm trong lập trình. Nhập dữ liệu, xác thực, định dạng đầu ra, tất cả trong đó LISP rất yếu.

Tôi nghĩ một vấn đề với Lisp chưa được đề cập là đối với một lập trình viên tầm thường hoặc người mới (như tôi, tôi tự do thừa nhận), có thể khó thấy cách bạn biến mã Lisp thành một chương trình lớn. Thật dễ để viết nhưng khó để kiến ​​trúc sư. Tôi không nghĩ bất kỳ khái niệm nào là đặc biệt khó khăn, nhưng tâm lý DIY mạnh mẽ đến mức tôi thường cảm thấy mất mát khi bắt đầu.

Với ngôn ngữ OOP như Java hoặc C #, bạn có thể sử dụng hệ thống loại để thúc đẩy bản thân hướng tới một mô hình hoạt động và xây dựng nó. Với Lisp (hoặc Lua hoặc Javascript, đối với vấn đề đó), có khái niệm rằng bạn có thể ra ngoài và làm bất cứ điều gì bạn muốn. Nếu bạn muốn OOP, chỉ cần tạo hệ thống OOP của riêng bạn! Ngoại trừ việc tạo OOP của riêng bạn, hoặc học hỏi người khác, là một rào cản mới trên ngôn ngữ trước khi bạn có được các chương trình có thể sử dụng được. Thêm vào đó, tôi luôn cảm thấy như OOP ở Lisp hoặc Lua không thực sự ở đó, giống như tôi có thể bỏ qua nó nếu tôi thực sự muốn, vậy thì sao?

Nói tóm lại, tôi nghĩ lập trình ở Lisp đòi hỏi rất nhiều kỷ luật và điều đó rất khó xảy ra. Các ngôn ngữ được gõ mạnh và ngôn ngữ OOP đều cung cấp một loại kỷ luật được xây dựng, vì vậy lập trình viên có thể tập trung dự trữ hạn chế của họ vào việc hoàn thiện các dự án thay vì điều chỉnh ngôn ngữ.

EDIT: Như một sự tương tự vừa xảy ra với tôi, nó giống như nếu bạn cần làm một số công việc gỗ và hai người cung cấp cho bạn hộp công cụ của họ. Công cụ của một người là loại khủng khiếp, nhưng về cơ bản sẽ hoàn thành công việc với một chút nỗ lực. Người khác có một thùng lớn các bộ phận, nhưng hứa hẹn rằng bạn có thể kết hợp các bộ phận đó để tạo ra các công cụ tốt nhất bạn từng sử dụng, hoàn toàn phù hợp với báng cầm của bạn và có chất lượng tốt nhất. Bạn chỉ cần xây dựng chúng đầu tiên.

Tôi đã tự hỏi điều tương tự từ lâu, và tôi thậm chí đã đi đến các hội nghị Lisp để cố gắng hiểu "mặt tối" của Lisp này khiến mọi người không chấp nhận nó.

Tôi không tìm thấy câu trả lời hoàn chỉnh.

Sự thiếu hiểu biết có thể là lý do cho sự thiếu phổ biến, nhưng điều khiến tôi băn khoăn hơn là ngay cả những người chắc chắn biết về Lisp (ví dụ Google - Peter Norvig làm việc cho họ) không sử dụng nó.

Giải thích một phần duy nhất tôi đưa ra là hầu hết các ý tưởng tuyệt vời của Lisp hiện nay đều phổ biến, điều duy nhất thực sự quan trọng (một IMO cực kỳ quan trọng) là dễ dàng lập trình siêu dữ liệu.

Thật không may, tôi thấy không có cách nào dễ dàng để hấp thụ khái niệm này cho các ngôn ngữ khác bởi vì siêu lập trình để trở nên tốt đẹp đòi hỏi một ngôn ngữ đồng âm và thông thường (tôi đang nói về siêu lập trình chung, không phải là phiên bản chỉ dành cho mẫu bị câm). Nói cách khác, về cơ bản, nó đòi hỏi cách tiếp cận Lisp theo cú pháp: mã là dữ liệu và dữ liệu là mã. Viết mã bằng ngôn ngữ giàu cú pháp thao túng AST khó hơn vì bạn cần biết hai ngôn ngữ: cách viết mã và cách viết AST. Điều này đặc biệt khó nếu AST của bạn được cố định và cũng phức tạp và không đều với nhiều loại nút khác nhau. Thay vào đó, Lisp có AST thường xuyên (và có thể mở rộng!) Và bạn thường viết mã bằng cách trực tiếp viết AST.

Lập trình siêu dữ liệu cũng khó khăn hơn (và siêu lập trình meta thậm chí còn nhiều hơn thế) và hầu hết các lập trình viên và nhà quản lý dường như chỉ thích câu trả lời "không ai cần điều đó".

Tôi thấy đặc biệt buồn khi các ngôn ngữ "mới" như gođã kết thúc bằng cách sử dụng siêu lập trình dựa trên văn bản khi cần thiết (trình tạo mã bên ngoài viết tệp văn bản) và "ma thuật" (tức là trình biên dịch có thể làm những gì lập trình viên không thể làm).

Tôi nghĩ rằng giải pháp cho vấn đề phức tạp là các công cụ và giáo dục mạnh mẽ. Xu hướng rõ ràng là thay vì các công cụ cùn và giả vờ vấn đề không có mặt.

Có vẻ như ngay cả CL cũng không có hỗ trợ thư viện rất tốt. Ít nhất là theo những người đã chuyển từ Lisp sang Python:

http://www.redmenezsw.com/wordpress/archives/reddit-switches-from-lisp-to-python

Cá nhân, tôi biết một số Đề án và thích chơi với nó, nhưng không thể tưởng tượng được việc thực hiện một dự án không tầm thường bằng ngôn ngữ đó.

Mạnh mẽ không nhất thiết phải ngụ ý sử dụng rộng rãi. Bạn đã nghe nói về thuật ngữ 'Tối ưu hóa cho trường hợp phổ biến' chưa? Thật không may như nhiều người đã nói trước sự tầm thường nếu được đảm bảo nhất quán sẽ tốt hơn rất nhiều cho mọi người so với những cú đánh lớn với nhiều thất bại ở giữa họ.

Đây không chỉ là trường hợp cần thiết, nhưng với rất nhiều công nghệ. Một liên lạc tốt trên các công cụ xử lý văn bản Unix, awk, sed, perl có thể giúp bạn tiết kiệm nhiều ngày lập trình. Thật không may, tôi đã thấy mọi người mất nhiều ngày để thực hiện các loại nhiệm vụ này trong các công cụ khác một cách tồi tệ những gì có thể làm với các công cụ này hiệu quả hơn trong vài phút. Nhưng nếu một người dành cả đời trong nhật thực, anh ta sẽ không bao giờ đến để đánh giá cao giá trị của những thứ này. Bạn có thể viết một chương trình lớn với khả năng đọc và bảo trì và tất cả những thứ đó, nhưng toàn bộ quan điểm của việc viết một chương trình như vậy trong khi không viết nó có thể dễ dàng thực hiện công việc.

Một khía cạnh khác trong khi thiết kế các công cụ ngày nay chúng hữu ích đến mức nào khi sử dụng chúng trực tiếp để giải quyết vấn đề. Bạn không thể xây dựng một cái gì đó quá chung chung và sau đó nói rằng bạn sẽ phòng ngừa tất cả những thứ đó thông qua các thư viện và khung. Đó là một chút khó khăn để làm việc theo cách đó. Một công cụ tốt phù hợp với môi trường và vấn đề xung quanh nó. Đó là lý do tại sao các công cụ như php, perl và awk vẫn tiếp tục có liên quan mặc dù bị troll và bash vô tận, bởi vì chúng quá hữu ích để vứt chúng đi và chúng thường làm rất nhiều việc hơn là một ngôn ngữ chung với nhiều thư viện và khung.

Tương tự như vậy, bạn sẽ thấy các ngôn ngữ như Java / Python rất tốt và tôi sẽ nói tốt nhất cho các tác vụ nhất định. Python đặc biệt rất tốt và dễ học và viết. Ngoài ra các ngôn ngữ này thực sự tốt nếu điểm cuối dữ liệu của bạn là tiêu chuẩn. Một số loại cơ sở dữ liệu hoặc XML hoặc dữ liệu thuộc loại đó. Dữ liệu cấu trúc cơ bản.

Lisp sẽ ở đó trong thời gian dài, nhưng không nhất thiết phải phổ biến rộng rãi. Như bạn sẽ thấy mỗi công cụ có thích hợp của nó. Và họ giải quyết một số vấn đề nhất định rất tốt. Tôi nghĩ và tôi chắc chắn rằng lisp đang làm tốt trong các lĩnh vực và các vấn đề mà nó được thiết kế để giải quyết tốt.

Để phát triển web với phương ngữ Lisp, có thể có một chút vấn đề trứng gà - bởi vì rất ít người sử dụng Lisp, chủ nhà không cho phép hoặc không làm điều đó dễ dàng, và vì không dễ, ít người sử dụng nó. Nhưng trên thực tế, việc Lisp chạy trên máy chủ có thể dễ dàng hơn bạn nghĩ, ngay cả khi nó đòi hỏi nhiều công việc hơn so với dịch vụ PHP ngoài luồng của họ. Gần đây tôi đã dảo Đề án ứng dụng làm việc ở đây chỉ với một chút nỗ lực.

IMO, chủ yếu là vấn đề thời gian kém: Lisp đã cũ (và gần như theo định nghĩa không còn thú vị nữa) trước khi nó trở nên thiết thực đối với hầu hết mọi người hoặc sử dụng. Clojure (cho một ví dụ) có cơ hội tốt hơn nhiều. Thành công của nó sẽ phụ thuộc nhiều vào việc được coi là mới, thời trang và tuyệt vời hơn bất cứ thứ gì thiết thực như sự tương tác với Java (và mọi thứ khác chạy trên JVM).