Mengapa Lisp tidak tersebar luas? [Tutup]


50

Saya mulai belajar Skema dari video SICP, dan saya ingin pindah ke Common Lisp berikutnya.

Bahasa itu tampaknya sangat menarik, dan sebagian besar orang menulis buku-buku yang menganjurkan bahwa ia memiliki kekuatan ekspresif yang tiada banding. CL tampaknya memiliki perpustakaan standar yang layak.

Mengapa Lisp tidak tersebar luas? Jika benar-benar kuat, orang harus menggunakannya di seluruh, tetapi sebaliknya hampir tidak mungkin untuk menemukan, katakanlah, iklan pekerjaan Lisp.

Saya harap ini bukan hanya tanda kurung, karena mereka bukan masalah besar setelah beberapa saat.



5
Steel Bank (umum) LISP sebenarnya lebih populer daripada yang Anda bayangkan. LISP seperti prosesor makro (misalnya M4) juga banyak digunakan. Anda mungkin tidak melihatnya di domain pilihan Anda, tetapi masih ada di luar sana (baik atau buruk).
Pos Tim

8
Gempa bumi dan tsunami baru-baru ini memusnahkan pabrik kurung di Jepang. :-(
oosterwal

1
Versi Lisp mana yang harus kita gunakan? Ingat dialek Lisp kurang lebih tidak kompatibel.

2
LISP (atau dialek) digunakan di semua tempat mis. AutoLISP adalah dialek LISP yang digunakan oleh Autocad en.wikipedia.org/wiki/AutoLISP atau EMACS en.wikipedia.org/wiki/Emacs_Lisp
Jaydee

Jawaban:


68

Ekspresivitas tidak selalu merupakan sifat bahasa yang positif dalam lingkungan perusahaan. Java sangat populer sebagian karena mudah dipelajari, mudah ditulis, dan mudah dibaca. Pemrogram yang biasa-biasa saja masih bisa sangat produktif di Jawa, bahkan jika kode mereka bertele-tele dan tidak bagus.

Selain itu, mudah untuk menyalahgunakan bahasa ekspresif. Seorang programmer java yang ahli dapat memperbaiki kode yang ditulis dengan buruk dengan cepat. Semakin ekspresif bahasa, semakin sulit memahami dan menjadi refactoring kode yang mengerikan. Makro LISP adalah contoh yang bagus. Macro adalah alat yang ampuh di tangan kanan. Di tangan yang salah, mereka dapat menyebabkan kode membingungkan dan sulit untuk debug.

LISP adalah pilihan berisiko bagi manajemen senior. Jika ada yang salah, tidak ada yang akan menyalahkan manajemen untuk memilih bahasa berorientasi objek populer yang didukung oleh perusahaan besar seperti Oracle atau Microsoft. Jauh lebih mudah untuk merekrut programmer dengan pengalaman dalam bahasa yang populer dan mudah dipelajari.

Bahkan perusahaan progresif yang bersedia menggunakan bahasa yang lebih kuat biasanya tidak memilih LISP. Ini karena banyak bahasa yang lebih baru mencoba dan berkompromi dengan meminjam fitur-fitur canggih dari LISP, sambil tetap mudah dipelajari untuk massa. Scala dan Ruby mengikuti model ini. Pemrogram yang buruk dapat mengambilnya dengan cepat dan terus menulis kode biasa-biasa saja yang sama yang mereka lakukan di Jawa. Pemrogram yang baik dapat memanfaatkan fitur yang lebih canggih untuk menulis kode yang indah.

Kurung bukan masalah. Haskell adalah bahasa yang sangat kuat dan ekspresif dengan sintaksis yang mirip dengan Python atau Ruby dan belum banyak diadopsi karena banyak alasan yang sama seperti LISP.

Terlepas dari semua ini, saya berharap ...

Clojure memiliki peluang untuk menjadi populer. Ini berjalan pada JVM, memiliki interop hebat dengan Java, dan membuat pemrograman bersamaan jauh lebih sederhana. Ini semua adalah hal penting bagi banyak perusahaan.

* Ini adalah perspektif saya sebagai programmer JVM profesional dengan pengalaman di Jawa, Clojure, JRuby, dan Scala.


24
Keberatan tentang kesulitan menemukan programmer yang berkualitas adalah sedikit anjing mengejar ekornya. Jika Lisp lebih luas, akan lebih mudah untuk menemukan programmer yang baik.
Andrea

2
@ Andrea Itu benar sekali. Lebih sulit untuk belajar cadel, yang berkontribusi terhadap masalah juga. Saya menyadari bahwa itu mungkin pendapat yang kontroversial, karena banyak profesor mengajarkan skema sebagai bahasa pertama.
dbyrne

8
Ya, APL adalah contoh luar biasa dari bahasa ekspresif. Juga, contoh yang bagus tentang mengapa ekspresif bukanlah hal yang paling penting;)
dbyrne

9
Saya tidak berpikir definisi ini benar-benar menyampaikan arti ekspresif. Secara pribadi, sebelum saya menyebut bahasa ekspresif, saya akan memastikan bahwa saya dapat membaca apa yang saya tulis. Misalnya, menggunakan logika nontrivial di penginisialisasi loop di C dapat menghemat beberapa baris kode, tetapi tidak mudah dimengerti. Di sisi lain, daftar pemahaman dalam Python dapat menyimpan beberapa baris dan lebih mudah dibaca. Jadi Anda sebenarnya telah menemukan cara untuk mengekspresikan apa yang Anda maksudkan dengan lebih ringkas. Jika tidak dapat dibaca, Anda belum menemukan cara untuk mengekspresikan apa pun.
Andrea

3
Saya pikir mungkin saya keluar sebagai seseorang yang tidak suka cadel. Sebenarnya, saya menyukainya. Clojure adalah bahasa yang luar biasa. Saya pikir ini adalah pilihan yang sangat layak untuk digunakan oleh perusahaan tertentu. Saya hanya menunjukkan ada banyak perusahaan di mana itu tidak masuk akal, dan menggunakan sesuatu seperti Scala adalah pilihan yang jauh lebih praktis.
dbyrne

17

Mengapa Lisp tidak tersebar luas? Jika benar-benar kuat, orang harus menggunakannya di seluruh,

Jika Anda percaya bahwa bahasa dipilih karena kelebihan teknisnya, Anda akan mengalami kekecewaan yang menghancurkan jiwa.

Keputusan seperti itu dibuat berdasarkan Penari Telanjang Dan Steaks . Microsoft mampu membelinya. Oracle bisa. Sun menghabiskan begitu banyak uang di Jawa sehingga mereka bangkrut. Dua kali. Komunitas sukarela yang terdesentralisasi, heterogen, tidak dapat bersaing dengan itu.

tetapi sebaliknya hampir tidak mungkin menemukan, katakanlah, iklan pekerjaan Lisp.

Lucunya, perusahaan Lisp mengatakan sebaliknya: mereka selalu memiliki lowongan kerja tetapi tidak dapat menemukan cukup banyak orang untuk mengisinya. (Hal yang sama berlaku untuk Haskell, ML, O'Caml, Forth, Smalltalk, ...)


3
Di mana saya tinggal (Italia), saya ragu bahkan ada satu perusahaan Lisp ...
Andrea

1
Perusahaan besar mana yang mendorong Ruby, Python & JavaScript? JS adalah kasus yang diakui khusus, tetapi dua lainnya tampaknya sangat populer tanpa dukungan perusahaan / vendor besar-besaran
Ben Hughes

Ya, itu juga berlaku untuk bahasa lain. Kebanyakan pembuat kode COBOL yang baik sudah memiliki pekerjaan, dan bagaimanapun juga tidak membaca iklan. Kenapa repot-repot beriklan?
Bo Persson

Apa yang benar-benar Saya akan kode dalam bahasa apa pun itu tidak mainstream, meskipun Haskell terdengar jauh di atas kepala saya. Jumlah kecil kode yang saya kodekan di dalamnya sangat indah, tetapi tanpa mentor yang baik saya tidak tahu kapan harus menggunakan setiap Monad dan Fungsi Aplikatif.
aoeu256

9

Saya tidak punya pengalaman bekerja untuk perusahaan yang sebenarnya, tetapi saya tahu mengapa LISP sulit untuk saya gunakan.

Pertama-tama, ini mengingatkan saya pada posting blog ini: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

Masalah utama yang saya miliki dengan Lisp adalah pertanyaan "which Lisp". Saya biasanya bekerja di Linux sebagai platform utama saya, tetapi hal-hal yang saya buat harus kompatibel dengan Windows. Itu berarti bahwa ketika saya mengevaluasi suatu teknologi untuk digunakan, itu harus membuat hidup saya mudah ketika bekerja pada dua sistem operasi yang sangat berbeda. Saya tidak suka persyaratan ini, tetapi untuk menggunakannya pada proyek nyata itu adalah persyaratan. Sekarang saya akan menggunakan bahasa yang tidak memiliki dukungan yang sangat baik pada Windows untuk proyek sampingan pribadi saya, tetapi karena saya tidak pernah mendapatkan kesempatan untuk menulis proyek perangkat lunak besar di dalamnya, saya tidak memiliki pengalaman yang diperlukan.

Sekarang ketika saya mencoba untuk belajar bahasa fungsional, saya benar-benar ingin belajar Common Lisp. Sepertinya itu hal yang benar untuk dilakukan. Saya mulai membaca Praktis Common Lisp sebagai titik awal karena saya benar-benar tidak tahu fungsi bawaan dan membutuhkan proyek untuk dikerjakan di Lisp. Ekspresi S itu indah dan mudah. Semua tanda kurung itu sangat indah bagi saya karena jelas hari persis apa yang terjadi dalam kode.

Jadi saya mencoba menulis program pertama saya di Lisp di luar buku. Saya ingin alat baris perintah yang akan menghitung baris kode dan menghapus garis sepele dari jumlah kode. Bukan alat yang paling berguna, tapi menyenangkan untuk dilakukan. Ini melibatkan akses file, sedikit penguraian, dan penghitungan. Saya telah mengimplementasikan alat yang sama dengan Python sekitar seminggu sebelumnya.

Saya perlu mengakses argumen baris perintah. Lalu saya belajar tidak ada cara standar untuk mendapatkan argumen baris perintah. Itu semua fitur yang tidak standar. Ini bukan lintas platform sama sekali. Sebagian besar hanya menjadi lebih buruk dari sana karena bahasa tidak memiliki banyak perpustakaan yang dibangun ke dalamnya. Saya akhirnya beralih ke Haskell dan tidak terlalu jauh ke Common Lisp (jadi keluhan saya mungkin tidak valid).

Hal non-standar semacam ini selalu menyakitkan bagi saya di masa lalu. C ++ memiliki masalah yang sama, tetapi dengan perpustakaan seperti Boost, Anda dapat mengatasi kelemahan itu.

Juga tidak membantu bahwa sintaks Lisp untuk segala sesuatu selain ekspresi S sedikit jelek.


1
PLT Racket (sebelumnya PLT Scheme) berjalan dengan baik di Linux dan Windows.
Larry Coleman

Menarik, saya harapkan Common Lisp jauh lebih standar dan dapat digunakan untuk aplikasi nyata daripada Skema. (Saya membaca Praktis Common Lisp sekarang.)
Giorgio

Saya memuji Anda karena memilih Haskell (yang merupakan bahasa yang lebih baik menurut saya), tetapi bagaimana dengan Clojure? Ini berjalan di JVM, jadi itu harus portabel dan memiliki akses ke semua perpustakaan yang Anda butuhkan.
Andres F.

Argumen baris perintah sulit digunakan dalam C ++? Benarkah?
Nick Keighley

Bukankah sepele membangun cross-complier yang mengubah Lisp menjadi Scheme menjadi Clojure? Mengapa orang tidak menggunakannya?
aoeu256

8

IMO, sebagian besar disebabkan oleh:

  • Dukungan perpustakaan buruk. Tentu, ada Quicklisp sekarang, yang membuatnya mudah untuk menginstal perpustakaan, tetapi itu tidak mengompensasi mereka yang masih cukup sedikit, dan beberapa didokumentasikan dengan buruk atau tidak terawat dengan baik. Dibandingkan dengan Python, ada kemungkinan besar bahwa menulis aplikasi Lisp yang non-sepele (terlepas dari dialek tertentu) mungkin masih akan melibatkan penciptaan kembali setidaknya sebagian dari satu atau dua roda.
  • Kurangnya keakraban dengan model yang diadopsi oleh alat pengembangan. Sebagian besar orang yang saya kenal cukup terintimidasi dengan harus menggunakan SLIME dan Emacs, yang dapat dimengerti untuk orang yang terbiasa dengan Eclipse dan Visual Studio. Ada dua plugin Eclipse saya pikir, saya hanya mencoba salah satu dari mereka beberapa tahun yang lalu dan itu cukup buggy. Seluruh ekosistem Lisp tampak seperti tersendat di antara hari-hari ketika itu merupakan bagian dari sistem Lisp yang berjalan penuh dan standar modern dari oh-itu-bahasa lain. Belajar Lisp tidak terbatas pada mempelajari bahasa baru - Anda juga perlu mempelajari cara kerja dan berpikir yang sama sekali berbeda, dan sementara ini tidak apa-apa jika Anda melakukannya sebagai hobi, patut dipertanyakan apakah layak melakukannya dalam suatu bisnis.

Hal-hal mulai terlihat sedikit lebih baik, terutama dengan Clojure yang ada.


1
"Sebagian besar orang yang saya kenal cukup terintimidasi dengan harus menggunakan SLIME dan Emacs, yang dapat dimengerti bagi orang-orang yang terbiasa dengan Eclipse dan Visual Studio.": Berulang kali saya mendapatkan perasaan bahwa Lisp adalah untuk elit.
Giorgio

2
"Anda juga perlu mempelajari cara bekerja dan berpikir yang sama sekali berbeda, dan sementara ini tidak apa-apa jika Anda melakukannya sebagai hobi, patut dipertanyakan apakah itu layak dilakukan dalam bisnis.": Bukankah peningkatan produktivitas itu alasan yang cukup bagus?
Giorgio

Apakah "peningkatan produktivitas" ini telah ditunjukkan? Jelas tidak jelas bagi saya (ya saya sudah memprogram dalam dialek Lisp). Tidak Ada Peluru Perak.
Nick Keighley

5

Saya belajar LISP satu miliar tahun yang lalu di perguruan tinggi.

LISP, seperti FORTH, sangat bagus untuk logika. Tetapi kebanyakan pemrograman bukan tentang logika, ini tentang memanipulasi data dengan cara mekanis yang membosankan. Misalnya, pada saat itu tidak ada cara untuk membenarkan hasil numerik.

LISP adalah tentang fungsionalitas bersarang, dan orang tidak berpikir seperti itu. Mereka berpikir dalam hal DO A, B, C, D, lalu E. Tidak melakukan A, yang melibatkan melakukan B dan C, kemudian D dan E. Ini melibatkan semacam konkurensi yang membingungkan. Kecuali untuk tugas-tugas yang telah ditentukan seperti "mengajukan pengembalian pajak penghasilan", orang tidak berpikir secara bersamaan, mereka berpikir secara berurutan. Inilah sebabnya mengapa bahasa prosedural dominan saat ini.

Akibatnya, kode produral menyukai Java dan C dapat diterjemahkan ke dalam bahasa Inggris dengan mudah. Kode LISP tidak bisa; tidak ada bahasa manusia yang terstruktur dengan cara itu.

Jadi itu bagus untuk pemecahan masalah, tetapi pemecahan masalah tidak terlalu penting dalam pemrograman. Entri data, validasi, pemformatan keluaran, yang semuanya sangat lemah di LISP.


7
Pemecahan masalah ADALAH semua yang kami lakukan. Memanipulasi data tidak mudah di Jawa atau C. Memanipulasi data dalam sel kontra jauh lebih mudah dalam Lisp dan bahasa fungsional lainnya. Sebagian besar operasi data sama persis dan tidak peduli urutan Anda memprosesnya. Ini mudah dilakukan dengan panggilan untuk memetakan dan penunjuk fungsi. Saya juga akan mengatakan lebih mudah untuk berpikir dalam fungsionalitas bersarang daripada fungsionalitas prosedural (seperti yang merinci tujuan Anda, dan yang lainnya merinci bagaimana melakukan tujuan tersebut), tetapi saya tidak punya bukti untuk itu. Either way, saya tidak akan mengatakan ini adalah alasan LISP tidak digunakan.
jsternberg

4
Pemrograman bukan tentang pemecahan masalah? Saya kira tidak. Dan omong-omong saya tidak berpikir bahwa Anda dapat belajar bahasa di perguruan tinggi juga.
Adam Arold

+1, terdengar sangat masuk akal bagi saya yang tidak tahu Lisp. Saya akan menyatakan alasan yang sama C / Java lebih baik daripada Python untuk solusi ukuran perusahaan.
Jonas Byström

Ini adalah satu-satunya jawaban sejauh ini yang mengangkat topik besar fungsional vs prosedural, tetapi jangan lupa berpikir prosedural cenderung suka bermain-main dengan gumpalan data di vars di mana pun Anda dapat menyentuh dari banyak tempat dan untaian menciptakan masalah sinkronisasi. Fungsional tidak menderita secepat ini, fungsional yang ditulis dengan baik tidak menderita sama sekali.
Maksimal

1
Seorang programmer pernah bertanya kepada saya apa cara terbaik untuk mengekspresikan for for loop menggunakan diagram aliran data. Untuk orang seperti itu tidak ada gunanya bahasa non-prosedural. The berpikir di FORTRAN.
Nick Keighley

5

Saya pikir satu masalah dengan Lisp yang belum disebutkan adalah bahwa untuk programmer yang biasa-biasa saja atau pemula (seperti saya sendiri, saya akui dengan bebas), mungkin sulit untuk melihat bagaimana Anda mengubah kode Lisp menjadi program besar. Sangat mudah untuk menulis tetapi sulit untuk arsitek. Saya tidak berpikir salah satu konsep itu sangat sulit, tetapi mentalitas DIY sangat kuat sehingga saya sering merasa bingung harus mulai dari mana.

Dengan bahasa OOP seperti Java atau C #, Anda bisa menggunakan sistem tipe untuk mendorong diri Anda menuju model yang berfungsi, dan membangun itu. Dengan Lisp (atau Lua, atau Javascript, dalam hal ini) ada anggapan bahwa Anda dapat keluar dan melakukannya dengan cara apa pun yang Anda inginkan. Jika Anda menginginkan OOP, buat saja sistem OOP Anda sendiri! Kecuali membuat OOP Anda sendiri, atau mempelajari milik orang lain, adalah penghalang baru di atas bahasa sebelum Anda mendapatkan program yang dapat digunakan. Ditambah lagi, aku selalu merasa seperti OOP di Lisp atau Lua tidak benar-benar ada, seperti aku bisa mengabaikannya jika aku benar-benar menginginkannya, jadi apa gunanya?

Singkatnya, saya pikir pemrograman dalam Lisp membutuhkan banyak disiplin, dan itu sangat sulit didapat. Bahasa yang sangat diketik dan bahasa OOP keduanya menawarkan semacam disiplin bawaan, sehingga pemrogram dapat memfokuskan cadangan terbatas mereka pada penyelesaian proyek alih-alih mengutak-atik bahasa.

EDIT: Sebagai analogi yang baru saja mengejutkan saya, rasanya seperti jika Anda perlu melakukan pekerjaan kayu dan dua orang menawarkan Anda kotak alat mereka. Alat satu orang agak payah, tetapi pada dasarnya akan menyelesaikan pekerjaan dengan sedikit usaha. Orang lain memiliki tempat sampah yang besar, tetapi menjanjikan bahwa Anda dapat menggabungkan bagian-bagian itu untuk membuat alat terbaik yang pernah Anda gunakan, sangat cocok untuk genggaman Anda dan kualitas terbaik. Anda hanya harus membangunnya terlebih dahulu.


2
Common Lisp, setidaknya, secara eksplisit merupakan bahasa OO: Common Lisp Object System adalah bagian dari standar.
Frank Shearar

Benar, dan seperti yang saya pahami itu sangat kuat, tetapi menurut saya ini adalah fitur sampingan dari bahasa tersebut. Ini tidak seperti Java di mana Anda perlu memahami objek dari hari 1. Praktik Common Lisp tidak menyentuh CLOS sampai bab 16. Saya mungkin juga hanya bias terhadap mengetik statis, meskipun saya tidak suka bahasa yang diketik secara dinamis .
CodexArcanum

Lisp memungkinkan Anda untuk menggunakan closure (let-over-lambda) alih-alih objek untuk OOP yang ringan, tapi saya percaya ini mudah untuk ditingkatkan menggunakan OOP via CLOS.
aoeu256

2

Saya telah lama bertanya-tanya hal yang sama, dan saya bahkan pergi ke konferensi Lisp untuk mencoba memahami apa "sisi gelap" Lisp yang membuat semua orang tidak mengadopsinya.

Saya tidak menemukan jawaban yang layak dan lengkap.

Ketidaktahuan mungkin menjadi alasan hilangnya popularitas, tetapi yang lebih membingungkan saya adalah bahwa siapa pun yang tahu pasti tentang Lisp (misalnya Google - Peter Norvig bekerja untuk mereka) tidak menggunakannya.

Satu-satunya penjelasan parsial yang saya kemukakan adalah bahwa sebagian besar ide-ide hebat Lisp sekarang sudah umum, satu-satunya yang sangat penting hilang (yang sangat penting IMO) adalah kemudahan metaprogramming.

Sayangnya saya tidak melihat cara mudah untuk mengadaptasi konsep ini untuk bahasa lain karena metaprogramming menjadi lebih baik membutuhkan bahasa homoikonik dan reguler (saya berbicara tentang metaprogramming umum, bukan versi template-only dumbed-down). Dengan kata lain pada dasarnya memerlukan pendekatan Lisp untuk sintaks: kode adalah data dan data adalah kode. Menulis kode dalam bahasa yang kaya sintaksis yang memanipulasi AST lebih sulit karena Anda perlu tahu dua bahasa: cara menulis kode dan cara menulis AST. Ini sangat sulit jika AST Anda diperbaiki dan juga kompleks dan tidak teratur dengan banyak jenis simpul yang berbeda. Sebagai gantinya, Lisp memiliki AST yang cukup teratur (dan dapat diperpanjang!) Dan Anda biasanya sudah membuat kode dengan langsung menulis AST.

Metaprogramming juga secara inheren lebih sulit (dan meta-metaprogramming bahkan lebih dan sebagainya) dan sebagian besar programmer dan manajer tampaknya hanya lebih suka jawaban "tidak ada yang membutuhkan itu".

Saya menemukan sangat sedih bahwa bahasa "baru" seperti goakhirnya menggunakan metaprogramming berbasis teks ketika diperlukan (generator kode eksternal menulis file teks) dan "ajaib" (yaitu kompiler dapat melakukan apa yang tidak dapat dilakukan oleh pemrogram).

Saya pikir solusi untuk masalah kompleksitas adalah alat dan pendidikan yang kuat. Tren ini tampaknya bukan alat tumpul dan berpura-pura masalah tidak ada.


+1 untuk "Saya pikir solusi untuk masalah kompleksitas adalah alat dan pendidikan yang kuat."
Giorgio

setelah 50 tahun alasan 'ketidaktahuan' memakai cukup tipis
Nick Keighley

1
@NickKeighley: tergantung. Bahkan saat ini kebanyakan programmer benar-benar tidak tahu apa-apa tentang Lisp (misalnya sebagian besar waktu Anda mendengar Lisp digambarkan sebagai bahasa fungsional). Bahkan di antara yang "tahu" Lisp hampir tidak ada yang pernah melihat ide makro dengan detail yang cukup (saya tidak berbicara tentang versi skema yang bodoh, tetapi kekuatan algoritmik lengkap dengan kenyamanan kuasi-kutip ketika itu lebih cocok).
6502

@ 6502: Meskipun tidak sepenuhnya berfungsi, IMO Lisp mendukung pemrograman fungsional jauh lebih baik daripada banyak bahasa utama seperti C #, Java, C ++, dan sebagainya. Bagi banyak programmer, FP berarti hanya menggunakan ekspresi lambda dari waktu ke waktu: programmer ini tidak akan melewatkan Lisp atau Clojure atau Haskell. Jadi saya akan menambahkan: (1) Lisp mendukung FP dengan cukup baik dan programmer fungsional akan mendapat untung darinya tetapi (2) ketidaktahuan tentang FP dan manfaatnya adalah salah satu alasan mengapa Lisp tidak digunakan lebih sering.
Giorgio

1
@ 6502: Memiliki daftar sebagai struktur data dasar dan fungsi tingkat tinggi yang biasa pada daftar juga merupakan fitur yang tidak ada dalam Javascript. Dan, sejauh yang saya ingat, Javascript juga memiliki pernyataan / ekspresi dualitas. Saya pasti akan menempatkan Lisp (Common Lisp) beberapa langkah lebih jauh ke arah FP daripada Javascript atau Python. Dengan ini saya tidak bermaksud bahwa Common Lisp adalah bahasa yang murni fungsional, saya setuju bahwa itu adalah multi-paradigma, tetapi mendukung FP jauh lebih baik daripada bahasa multi-paradigma lainnya.
Giorgio

1

Tampaknya bahkan CL tidak memiliki dukungan perpustakaan yang sangat baik. Setidaknya menurut orang yang beralih dari Lisp ke Python:

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

Secara pribadi, saya tahu beberapa Skema dan menikmati bermain dengannya, tetapi tidak bisa membayangkan melakukan proyek non-sepele dalam bahasa itu.


2
Ini tidak lagi benar. Quicklisp memecahkan masalah itu.

2
Perlu juga disebutkan bahwa dengan CFFI, pustaka C apa pun dapat digunakan dari Common Lisp. CFFI didokumentasikan dengan baik dan berfungsi dengan baik. Di sisi lain, jika menghabiskan beberapa jam menulis pembungkus untuk fungsi C memiliki dampak besar pada proyek Anda, Lisp mungkin bukan pilihan yang tepat untuk itu.
Larry Coleman

Saya melakukan proyek non-sepele dalam Skema dan mengenal sebuah perusahaan yang menggunakan Skema (Skema Ayam) untuk beberapa produk.
Giorgio

1

Menjadi kuat tidak selalu menyiratkan penggunaan luas. Pernahkah Anda mendengar istilah 'Optimalkan untuk kasus umum'? Sayangnya seperti yang banyak diceritakan sebelum mediocrity jika dipastikan secara konsisten jauh lebih baik bagi orang daripada hit besar dengan banyak kegagalan di antara mereka.

Ini bukan hanya kasus dengan lisp, tetapi dengan banyak teknologi. Sentuhan yang baik pada alat pengolah teks Unix, awk, sed, perl dapat menghemat hari pemrograman. Sayangnya saya telah melihat orang membutuhkan waktu berhari-hari melakukan tugas-tugas semacam ini di alat lain dengan buruk apa yang bisa dilakukan dengan alat-alat ini lebih efisien dalam hitungan menit. Tetapi jika seseorang menghabiskan seluruh hidupnya dalam gerhana ia tidak akan pernah menghargai nilai dari hal-hal ini. Anda dapat menulis sebuah program besar dengan keterbacaan dan pemeliharaan dan semua itu, tetapi apa gunanya menulis program seperti itu sementara tidak menulisnya bisa dengan mudah melakukan pekerjaan itu.

Aspek lain saat merancang alat-alat hari ini seberapa berguna di luar kotak mereka menggunakannya secara langsung untuk memecahkan masalah. Anda tidak dapat membangun sesuatu yang terlalu umum dan kemudian mengatakan Anda akan melakukan lindung nilai semua itu melalui perpustakaan dan kerangka kerja. Agak sulit untuk menyelesaikan masalah dengan cara itu. Alat yang bagus cocok dengan lingkungan dan masalah di sekitarnya. Itu sebabnya alat-alat seperti php, perl dan awk terus tetap relevan meskipun tanpa henti-hentinya trolling dan bashing, karena mereka terlalu berguna untuk membuangnya dan seringkali mereka melakukan banyak pekerjaan daripada bahasa umum dengan banyak perpustakaan dan kerangka kerja yang dikunci.

Demikian pula Anda akan melihat bahasa seperti Java / Python sangat baik dan saya akan mengatakan yang terbaik untuk tugas-tugas tertentu. Python khususnya sangat baik dan mudah dipelajari dan ditulis. Bahasa-bahasa ini juga sangat baik jika titik akhir data Anda standar. Semacam database atau XML atau data semacam itu. Data pada dasarnya terstruktur.

Gangguan akan ada di sana untuk waktu yang lama, tetapi belum tentu meluas. Seperti yang akan Anda lihat, setiap alat memiliki ceruknya. Dan mereka memecahkan serangkaian masalah tertentu dengan sangat baik. Saya pikir dan saya yakin CIP melakukan baik di bidang dan masalah yang dirancang untuk menyelesaikan dengan baik.


+1 untuk mengutip prinsip "Optimalkan untuk kasus umum".
Giorgio

Ya tapi Penutupan LISP adalah optimasi untuk kasus umum Objects. Saya juga bertanya-tanya apakah ada yang membuat perubahan pada basis kode LISP mereka dengan memperlakukannya sebagai pohon dan menjalankan kueri seperti JQuery untuk HTML.
aoeu256

1

Untuk pengembangan web dengan dialek Lisp, mungkin ada sedikit masalah ayam-dan-telur - karena sedikit orang yang menggunakan Lisp, host tidak mengizinkannya atau tidak membuatnya mudah, dan karena itu tidak mudah, beberapa orang Gunakan. Tetapi sebenarnya, menjalankan Lisp pada host bisa lebih mudah dari yang Anda kira, bahkan jika itu membutuhkan kerja lebih banyak daripada layanan PHP out-of-the-box mereka. Baru-baru ini saya mendapat aplikasi tipu daya Skema yang bekerja di sini hanya dengan sedikit usaha.


0

IMO, ini sebagian besar masalah waktu yang buruk: Lisp sudah tua (dan hampir secara definisi tidak lagi menarik) jauh sebelum menjadi praktis bagi kebanyakan orang atau pengguna. Clojure (misalnya) memiliki peluang yang jauh lebih baik. Keberhasilannya akan jauh lebih tergantung pada dianggap sebagai baru, modis dan keren daripada apa pun sepraktis interoperasi dengan Jawa (dan segala sesuatu yang berjalan di JVM) sekalipun.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.