Có bất kỳ nhược điểm hoặc vấn đề với Haskell?

Tôi đang xem xét lặn vào Haskell cho dự án cá nhân tiếp theo (tương đối tầm thường) của tôi. Những lý do mà tôi giải quyết Haskell là:

1. Đưa đầu tôi vào một ngôn ngữ hoàn toàn chức năng
2. Tốc độ. Mặc dù tôi chắc chắn rằng điều này có thể được tranh luận, hồ sơ rằng tôi đã thấy móng tay Haskell gần với C ++ (và dường như nhanh hơn một chút so với Erlang).
3. Tốc độ. Máy chủ web Warp dường như phát điên nhanh so với hầu hết mọi thứ khác .

Vì vậy, với điều này, những gì tôi đang tìm kiếm là những nhược điểm hoặc vấn đề đi kèm với Haskell. Web có một lượng thông tin khổng lồ về lý do tại sao Haskell là một điều tốt, nhưng tôi không tìm thấy nhiều chủ đề về mặt xấu của nó (ngoài những hiểu biết về cú pháp mà tôi không quan tâm chút nào).

Một ví dụ về những gì tôi đang tìm kiếm có thể giống như GIL của Python. Một cái gì đó không ngẩng cao đầu cho đến khi tôi thực sự bắt đầu xem xét sử dụng đồng thời trong môi trường CPython.

Một vài nhược điểm tôi có thể nghĩ đến:

• Do bản chất của ngôn ngữ và nguồn gốc vững chắc của nó trong thế giới học thuật, cộng đồng rất có đầu óc toán học; nếu bạn là một người thực dụng, đôi khi điều này có thể trở nên quá sức và nếu bạn không nói biệt ngữ, bạn sẽ có một thời gian khó khăn hơn so với nhiều ngôn ngữ khác.
• Mặc dù có rất nhiều thư viện đáng kinh ngạc, tài liệu thường rất ngắn gọn.
• Hướng dẫn cấp độ nhẹ nhàng rất ít và khó tìm, vì vậy đường cong học tập ban đầu khá dốc.
• Một vài tính năng ngôn ngữ là vụng về không cần thiết; một ví dụ nổi bật là cách cú pháp bản ghi không giới thiệu phạm vi đặt tên, vì vậy không có cách nào để có cùng tên trường bản ghi trong hai loại khác nhau trong cùng một không gian tên mô-đun.
• Haskell mặc định để đánh giá lười biếng, và trong khi điều này thường là một điều tuyệt vời, đôi khi nó có thể cắn bạn theo những cách khó chịu. Sử dụng đánh giá lười biếng một cách ngây thơ trong các tình huống không tầm thường có thể dẫn đến các tắc nghẽn hiệu suất không cần thiết và việc hiểu những gì đang diễn ra dưới mui xe không thực sự đơn giản.
• Đánh giá lười biếng (đặc biệt là kết hợp với độ tinh khiết và trình biên dịch tối ưu hóa mạnh mẽ) cũng có nghĩa là bạn không thể dễ dàng suy luận về thứ tự thực hiện; thực tế, bạn thậm chí không biết liệu một đoạn mã nhất định có thực sự được đánh giá trong một tình huống nhất định hay không. Do đó, việc gỡ lỗi mã Haskell đòi hỏi một tư duy khác, nếu chỉ vì bước qua mã của bạn ít hữu ích hơn và ít ý nghĩa hơn.
• Vì độ tinh khiết của Haskell, bạn không thể sử dụng các tác dụng phụ để làm những việc như I / O; bạn phải sử dụng đánh giá lười biếng đơn lẻ và 'lạm dụng' để đạt được tính tương tác và bạn phải kéo bối cảnh đơn điệu xung quanh bất cứ nơi nào bạn có thể muốn thực hiện I / O. (Đây thực sự là một tính năng tốt theo nhiều cách, nhưng đôi khi nó không thể mã hóa thực tế.)

Hầu hết các nhược điểm của Haskell (cũng như hầu hết các nhược điểm của Haskell) đến từ hai đặc điểm xác định của nó: Đó là sự lười biếng và hoàn toàn hoạt động.

Lười biếng làm cho khó khăn hơn để lý do về hiệu suất. Đặc biệt đối với những người không quen với sự lười biếng, nhưng ngay cả đối với những người Haskeller có kinh nghiệm cũng khó có thể thấy sự lười biếng sẽ ảnh hưởng đến hiệu suất trong một số trường hợp nhất định.

Lười biếng cũng có nghĩa là khó tạo ra điểm chuẩn chính xác mà không sử dụng các thư viện như Tiêu chí.

Hoàn toàn là chức năng có nghĩa là bất cứ khi nào bạn cần sử dụng các cấu trúc dữ liệu có thể thay đổi (trong trường hợp không thể đạt được hiệu suất mong muốn mà không có chúng - mặc dù nhờ trình tối ưu hóa của GHC không xảy ra thường xuyên như bạn nghĩ), bạn sẽ bị mắc kẹt trong đơn vị IO (hoặc ST), làm cho mã trở nên cồng kềnh hơn.

Vì bạn đã đề cập đến tốc độ là một trong những mục tiêu của mình, tôi nên chỉ ra rằng thường có sự khác biệt lớn về hiệu suất giữa mã Haskell được tối ưu hóa bằng tay và mã Haskell được viết mà không cần suy nghĩ nhiều về hiệu suất (hơn cả các ngôn ngữ khác). Và mã Haskell được tối ưu hóa bằng tay thường khá xấu (mặc dù tôi cho rằng điều đó cũng đúng trong hầu hết các ngôn ngữ khác).

Tôi không phải là chuyên gia của Haskell: Tôi đã học được những điều cơ bản nhưng tiếc là tôi chưa có cơ hội thực hiện một dự án nghiêm túc nào đó ở Haskell (mặc dù tôi rất thích, vì tôi thích ngôn ngữ này rất nhiều).

Tuy nhiên, từ những gì tôi biết và từ một cuộc thảo luận với ai đó đang làm việc trong một lĩnh vực khá gần với lập trình chức năng, Haskell có thể không phải là giải pháp tốt nhất khi bạn muốn thực hiện các thuật toán đồ thị, nơi bạn cần ví dụ để đi qua biểu đồ và thực hiện nhiều thay đổi cục bộ trên cấu trúc đồ thị.

Do biểu đồ nói chung không có cấu trúc đệ quy, cảm giác của tôi là cách tiếp cận tốt nhất là xây dựng một bản sao của biểu đồ bằng cách sử dụng các cấu trúc và con trỏ giữa chúng (như bạn có thể làm như trong C ++) và điều khiển bản sao đó bằng cách thay đổi con trỏ, tạo hoặc phá hủy các nút, v.v.

Tôi tự hỏi làm thế nào các cấu trúc dữ liệu và hoạt động như vậy có thể được xử lý đúng cách trong Haskell, vì theo hiểu biết của tôi về Haskell, không thể sử dụng cách biểu diễn / cách tiếp cận ở trên. Một số vấn đề với thuật toán đồ thị trong Haskell được thảo luận ngắn gọn trong bài viết này

BIÊN TẬP

Gần đây tôi đã nói chuyện với một chuyên gia về lập trình chức năng và anh ấy đã xác nhận rằng việc triển khai một số thuật toán đồ thị hiệu quả có thể khá khó khăn trong Haskell: di chuyển xung quanh các con trỏ như bạn làm trong C hoặc C ++ có thể nhanh hơn nhiều.

Mặt trái của Haskell là nó khác biệt. Đó là một bước tiến lớn hơn so với các ngôn ngữ thường được dạy hoặc nói nhiều hơn, vì vậy sẽ có một đường cong học tập lớn hơn. Nó cũng ít phổ biến hơn về ngôn ngữ có thể hạn chế khả năng trợ giúp nếu bạn gặp khó khăn. Đây thực sự không phải là nhược điểm lớn.

Một điều có một nhược điểm tiềm năng là nó là ngôn ngữ chức năng, vì vậy nó ít hữu ích hơn đối với các miền có vấn đề nhất định, nhưng điều này cũng đúng với các ngôn ngữ hướng đối tượng. Nói chung, các ngôn ngữ không có tiêu cực thực sự ngoài các đường cong học tập, ít nhất là đối với các ngôn ngữ tương đối phổ biến. Miễn là một ngôn ngữ là Turing hoàn chỉnh, về mặt lý thuyết nó có khả năng cho bất cứ điều gì.

Vì vậy, với điều này, những gì tôi đang tìm kiếm là những nhược điểm hoặc vấn đề đi kèm với Haskell

"Các vấn đề với Haskell" có xu hướng xuất hiện trong một số miền nhất định. Haskell là một ngôn ngữ tuyệt vời để lập trình ứng dụng, dễ viết hơn nhiều so với bất kỳ thứ gì khác. Các vấn đề có xu hướng tăng lên khi bạn cố gắng làm điều gì đó không hỗ trợ tốt, chẳng hạn như:

• Biên dịch chéo. GHC có thể được xây dựng như một trình biên dịch chéo, nhưng quá trình này khá liên quan.
• Ứng dụng nhúng. Haskell có quản lý bộ nhớ thông qua bộ thu gom rác, vì vậy điều này không quá ngạc nhiên.
• Tốc độ. Haskell không nhanh như Rust, mặc dù trong hầu hết các trường hợp, nó sẽ cạnh tranh khá tốt. Nó phụ thuộc rất nhiều vào miền ứng dụng - các tính toán thuần túy được tối ưu hóa tốt, nhưng một cái gì đó như "đọc tệp vào bộ đệm và đếm số dòng" khó diễn đạt hơn trong Haskell.