Apakah ada kerugian atau masalah dengan Haskell?

47

Saya melihat menyelam ke Haskell untuk proyek pribadi saya berikutnya (relatif sepele). Alasan saya menangani Haskell adalah:

Dapatkan kepalaku ke bahasa yang murni fungsional
Kecepatan. Meskipun saya yakin ini bisa diperdebatkan, membuat profil yang saya lihat paku Haskell dekat dengan C ++ (dan tampaknya sedikit lebih cepat daripada Erlang).
Kecepatan. Server web Warp tampaknya sangat cepat gila dibandingkan dengan yang lainnya .

Jadi, mengingat ini, apa yang saya cari adalah kelemahan atau masalah yang menyertai Haskell. Web memiliki sejumlah besar informasi tentang mengapa Haskell adalah Good Thing, tetapi saya belum menemukan banyak topik tentang sisi buruknya (terlepas dari keluhan tentang sintaksisnya yang tidak saya pedulikan sama sekali).

Contoh dari apa yang saya cari bisa seperti Python GIL. Sesuatu yang tidak mendukungnya sampai saya benar-benar mulai melihat menggunakan konkurensi dalam lingkungan CPython.

haskell

— Demian Brecht
sumber

4

Menemukan ini di stackoverflow: stackoverflow.com/questions/1695076/pros-and-cons-of-haskell

— FrustratedWithFormsDesigner

26

Saya pernah mendengar programmer yang lebih sedikit berurusan dengan masalah pencairan otak. Ini adalah kondisi yang sangat mahal untuk dirawat.

— ChaosPandion

1

@FrustratedWithFormsDesigner: Terima kasih atas tautannya. Namun, masih belum ada referensi untuk kelemahan teknis apa pun untuk Haskell .. Mungkinkah tidak ada? ;)

— Demian Brecht

6

@ChaosPandion: Saya pernah mendengar hal yang sama .. Tetapi jika Anda tidak melelehkan otak Anda, apakah Anda benar - benar mencoba ? ;) Juga, saya tidak akan menganggap diri saya seorang programmer yang lebih rendah, jadi saya tidak terlalu khawatir tentang hal itu;)

— Demian Brecht

3

@ChaosPandion: Dan sebagian besar rencana kesehatan tidak menutupinya. :(

— FrustratedWithFormsDesigner

48

Beberapa kerugian yang dapat saya pikirkan:

Karena sifat bahasa dan akarnya yang kuat di dunia akademik, komunitas ini sangat berpikiran matematika; jika Anda adalah orang yang pragmatis, ini bisa sangat banyak di kali, dan jika Anda tidak berbicara jargon, Anda akan memiliki waktu yang lebih sulit daripada dengan banyak bahasa lainnya.
Meskipun ada banyak sekali perpustakaan, dokumentasi sering kali singkat.
Tutorial entry-level yang lembut sedikit dan sulit ditemukan, sehingga kurva pembelajaran awal cukup curam.
Beberapa fitur bahasa tidak perlu kaku; contoh yang menonjol adalah bagaimana sintaks rekaman tidak memperkenalkan ruang lingkup penamaan, jadi tidak ada cara untuk memiliki nama bidang rekaman yang sama dalam dua jenis yang berbeda dalam ruang nama modul yang sama.
Haskell default untuk evaluasi malas, dan meskipun ini sering merupakan hal yang hebat, Haskell kadang-kadang dapat menggigit Anda dengan cara yang jahat. Menggunakan evaluasi malas secara naif dalam situasi non-sepele dapat menyebabkan hambatan kinerja yang tidak perlu, dan memahami apa yang terjadi di bawah tenda tidak langsung.
Evaluasi malas (terutama dikombinasikan dengan kemurnian dan kompiler optimisasi agresif) juga berarti Anda tidak dapat dengan mudah alasan tentang urutan eksekusi; pada kenyataannya, Anda bahkan tidak tahu apakah suatu kode tertentu benar-benar dievaluasi dalam situasi tertentu. Akibatnya, debug kode Haskell memerlukan pola pikir yang berbeda, jika hanya karena melangkah melalui kode Anda kurang bermanfaat dan kurang bermakna.
Karena kemurnian Haskell, Anda tidak dapat menggunakan efek samping untuk melakukan hal-hal seperti I / O; Anda harus menggunakan evaluasi malas monad dan 'penyalahgunaan' untuk mencapai interaktivitas, dan Anda harus menyeret konteks monadik di mana saja Anda mungkin ingin melakukan I / O. (Ini sebenarnya adalah fitur yang baik dalam banyak hal, tetapi itu membuat pengkodean pragmatis tidak mungkin dilakukan pada waktu-waktu tertentu.)

— tammmer
sumber

16

Sebenarnya ada beberapa buku pengantar yang sangat bagus tersedia untuk online gratis sekarang. Pelajari Anda Haskell for Great Good adalah salah satu buku pemrograman pemula terbaik yang pernah saya baca dan Real World Haskell adalah sumber daya perantara yang hebat.

— Tikhon Jelvis

1

@TikhonJelvis: Mereka memang satu-satunya dua kandidat yang saya anggap layak untuk digunakan; "Learn You A Haskell" membuatku bingung lebih dari apa pun, "Real World Haskell" bekerja untukku tetapi mengasumsikan sedikit latar belakang pemrograman. Ada juga "Pengantar Lembut untuk Haskell", tapi itu semua lembut, terutama jika Anda tidak memiliki latar belakang dalam Matematika.

— Pelaku

Saya menggunakan "Pengantar Lembut untuk Haskell" dan "Haskell Dunia Nyata". Kombinasi keduanya memberi saya banyak informasi berguna. Saya berada pada tingkat di mana saya siap untuk proyek non-sepele tetapi sayangnya saya tidak punya banyak waktu untuk itu.

— Giorgio

9

"Jika Anda adalah orang yang pragmatis ...": kadang-kadang menggunakan bahasa berorientasi matematika bisa menjadi keputusan yang sangat pragmatis jika itu akan menghindari banyak perbaikan bug di kemudian hari. Tentu saja, Anda harus selalu menemukan keseimbangan antara berapa banyak waktu yang Anda hemat dengan menggunakan alat, dan berapa banyak waktu tambahan yang Anda butuhkan untuk belajar cara menggunakannya.

— Giorgio

Monads akan (dan melakukan dalam bahasa lain) bekerja sama persis dalam bahasa yang ketat. Anda benar-benar tidak "menyalahgunakan" evaluasi malas untuk mencapai interaktivitas, itu sepele untuk menulis program interaktif yang ketat di Haskell.

— titik koma

19

Sebagian besar kerugian Haskell (dan juga sebagian besar kelebihan Haskell) berasal dari dua karakteristik yang menentukan: Ini malas dan murni fungsional.

Menjadi malas membuat lebih sulit untuk berpikir tentang kinerja. Khususnya untuk orang-orang yang tidak terbiasa dengan kemalasan, tetapi bahkan untuk Haskellers yang berpengalaman, akan sulit untuk melihat bagaimana kemalasan akan memengaruhi kinerja dalam kasus-kasus tertentu.

Kemalasan juga berarti bahwa lebih sulit untuk membuat tolok ukur yang akurat tanpa menggunakan perpustakaan seperti Kriteria.

Menjadi fungsional murni berarti bahwa setiap kali Anda perlu menggunakan struktur data yang bisa berubah-ubah (dalam kasus di mana tidak mungkin untuk mencapai kinerja yang diinginkan tanpa mereka - meskipun berkat pengoptimal GHC yang tidak terjadi sesering yang Anda bayangkan), Anda akan menjadi terjebak di monad IO (atau ST), yang membuat kode lebih rumit.

Karena Anda menyebut kecepatan sebagai salah satu tujuan Anda, saya harus menunjukkan bahwa seringkali ada perbedaan besar dalam kinerja antara kode Haskell yang dioptimalkan dengan tangan dan kode Haskell yang ditulis tanpa terlalu memikirkan kinerja (lebih daripada dalam bahasa lain). Dan kode Haskell yang dioptimalkan dengan tangan sering kali sangat jelek (meskipun saya kira itu juga berlaku di sebagian besar bahasa lain).

— sepp2k
sumber

1

Fungsional murni sebenarnya adalah fitur penjualan, bukan kelemahan. Bahasa menjadi "malas" tidak masuk akal, lazy vs ketat adalah masalah tipe, dan tipe malas dan ketat memiliki kegunaannya. (Jadi Haskell sama lumpuh dengan tidak memiliki tipe yang ketat karena kebanyakan bahasa lumpuh dengan tidak memiliki tipe malas.) Kelemahan utama Haskell adalah sistem modul jeleknya (modul bukan kelas satu) dan kelas tipe fakta sebenarnya memecah modularitas (yang Aturan "satu instance per tipe" memaksa kompiler untuk menyimpan daftar global tipe kelas type).

— pyon

21

"Dan kode Haskell yang dioptimalkan dengan tangan sering kali sangat jelek (meskipun saya kira itu juga berlaku di sebagian besar bahasa lain)." Ini. Ketika orang ingin menunjukkan keanggunan Haskell, mereka menerbitkan kode pendek dan manis, yang sayangnya akan memberi Anda kinerja yang sangat buruk jika dijalankan pada jumlah data yang seperti produksi. Ketika orang ingin menunjukkan bahwa "Haskell secepat C ++", mereka menerbitkan kode yang berbelit-belit dan sulit dibaca, yang masih lebih lambat daripada versi yang lebih mudah dibaca dalam C.

— quant_dev

12

Saya bukan ahli Haskell: Saya telah mempelajari dasar-dasarnya tetapi sayangnya saya belum memiliki kesempatan untuk melakukan beberapa proyek serius di Haskell (saya ingin, karena saya suka bahasa ini).

Namun, dari apa yang saya ketahui dan dari diskusi dengan seseorang yang telah bekerja di bidang yang cukup dekat dengan pemrograman fungsional, Haskell mungkin bukan solusi terbaik ketika Anda ingin menerapkan algoritma grafik, di mana Anda perlu misalnya berjalan melalui grafik dan melakukan banyak perubahan lokal pada struktur grafik.

Karena grafik tidak memiliki struktur rekursif secara umum, perasaan saya adalah bahwa pendekatan terbaik adalah membangun satu salinan grafik menggunakan struktur dan pointer di antara mereka (seperti yang dapat Anda lakukan misalnya dalam C ++) dan memanipulasi salinan itu dengan mengubah pointer, membuat atau menghancurkan node, dan sebagainya.

Saya bertanya-tanya bagaimana struktur dan operasi data tersebut dapat ditangani dengan benar di Haskell, karena sepengetahuan saya di Haskell tidak mungkin menggunakan representasi / pendekatan di atas. Beberapa masalah dengan algoritma grafik di Haskell dibahas secara singkat di artikel ini

SUNTING

Saya baru-baru ini berbicara dengan seorang ahli pemrograman fungsional dan dia mengkonfirmasi bahwa menerapkan algoritma grafik tertentu secara efisien bisa sangat rumit di Haskell: bergerak di sekitar pointer seperti yang Anda lakukan di C atau C ++ bisa jauh lebih cepat.

— Giorgio
sumber

Catatan menarik (dan tautan) pada manipulasi grafik / traversal dalam dunia fungsional murni. Tidak mempertimbangkan itu.

— Demian Brecht

7

Algoritma grafik yang murni fungsional adalah topik yang menarik. Solusi idiomatik adalah untuk meniru representasi imperatif dengan mengganti pointer dengan kamus fungsional murni, misalnya memetakan simpul yang diberikan ke set simpul yang memiliki tepi. Namun, kecuali jika kamus lemah digunakan, ini akan membocorkan memori karena subgraph yang tidak dapat dijangkau tidak dapat dikumpulkan dan tidak ada kamus lemah yang murni berfungsi. Pada akhirnya, solusi fungsional murni canggih jauh lebih rumit dan jauh lebih efisien!

— Jon Harrop

1

Di sisi lain, algoritma grafik bisa sangat sulit untuk di-debug dan struktur data yang persisten dapat mengatasi masalah ini ...

— Jon Harrop

Saya bertanya-tanya apakah mungkin untuk mengembangkan tipe data grafik (mengikuti ide ByteString: representasi internal yang efisien ditambah fungsi konversi / akses). Dengan menggunakan monad, grafik mungkin bisa berubah. Tentu saja ini akan membahas masalah mewakili grafik tetapi tidak mengimplementasikan algoritma grafik.

— Giorgio

DAG adalah satu hal. Untuk yang lainnya, Anda dapat memanfaatkan kemalasan dan "mengikat ikatan".

— danielm

4

Sisi negatif dari Haskell adalah berbeda. Ini adalah langkah lebih besar dari bahasa yang lebih umum diajarkan atau dibicarakan, sehingga akan ada kurva belajar yang lebih besar. Bahasa ini juga kurang populer dari bahasa yang dapat membatasi ketersediaan bantuan jika Anda mengalami kesulitan. Ini sebenarnya bukan kerugian besar.

Satu hal yang menjadi kelemahan potensial adalah bahasa fungsional, sehingga kurang bermanfaat untuk domain masalah tertentu, tetapi ini juga berlaku untuk bahasa berorientasi objek. Secara umum bahasa tidak memiliki negatif sebenarnya di luar kurva belajar, setidaknya untuk bahasa yang relatif populer. Selama bahasa Turing lengkap, secara teori ia mampu melakukan apa saja.

— Ryathal
sumber

3

Kelengkapan Turing adalah herring merah. Teori perhitungan! = Pemrograman praktis.

1

@delnan itu sebabnya saya katakan secara teoritis

— Ryathal

2

Apa "domain masalah" yang menurut Haskell kurang berguna?

— Andres F.

3

Meskipun benar komunitasnya lebih kecil , sebenarnya aktif secara tidak proporsional. Saya pikir saluran #haskell di freenode hanya di belakang #python dalam popularitas di dalam saluran bahasa, dan menjawab pertanyaan tentang Haskell di SO secara mengejutkan kompetitif :)

— Tikhon Jelvis

@AndresF. - Saya tidak akan mengatakan "kurang berguna," tetapi di sini ada beberapa area di mana Haskell masih menunjukkan masa pertumbuhannya: 1) DP yang besar - Saya membuat kode algoritma ransel sederhana, dan benar-benar terkejut melihat betapa lambat itu. Itu menggunakan array kotak, jadi saya mengharapkan beberapa overhead, tapi itu jauh lebih buruk daripada yang saya perkirakan. 2) game non-sepele yang besar - AFRP masih dalam tahap awal, sehingga tidak ada kerangka kerja yang sangat baik, dan kinerjanya masih terlalu sulit untuk diprediksi. Akan lama sekali sebelum kita melihat versi Haskell dari Doom. (frag tidak masuk hitungan - tidak ada AI.)

— rtperson

0

Jadi, mengingat ini, apa yang saya cari adalah kelemahan atau masalah yang menyertai Haskell

"Masalah dengan Haskell" cenderung muncul di domain tertentu. Haskell adalah bahasa yang bagus untuk pemrograman aplikasi, jauh lebih menyenangkan untuk ditulis daripada hal lainnya. Masalahnya cenderung muncul ketika Anda mencoba melakukan sesuatu yang tidak memiliki dukungan yang baik, seperti:

Kompilasi silang. GHC dapat dibangun sebagai kompiler silang, tetapi prosesnya agak terlibat.
Aplikasi tertanam. Haskell memiliki manajemen memori melalui pengumpul sampah, jadi yang ini tidak terlalu mengejutkan.
Kecepatan. Haskell tidak secepat Rust, meskipun dalam kebanyakan kasus itu akan bersaing dengan cukup baik. Ini sangat tergantung pada domain aplikasi - perhitungan murni dioptimalkan dengan baik, tetapi sesuatu seperti "membaca file ke buffer dan menghitung jumlah baris" lebih sulit untuk diekspresikan di Haskell.