하스켈에 단점이나 문제가 있습니까?

다음 (상대적으로는) 개인 프로젝트를 위해 Haskell에 뛰어 들기를보고 있습니다. 내가 Haskell을 다루는 이유는 다음과 같습니다.

1. 순전히 기능적인 언어로 머리를 숙여 라
2. 속도. 나는 이것이 논쟁의 여지가 있다고 확신하지만, 손톱 Haskell을 C ++에 가깝게 보았습니다 (Erlang보다 약간 빠릅니다).
3. 속도. 워프 웹 서버는 사실상 다른 모든 것에 비해 미친 것처럼 보입니다 .

따라서, 내가 찾고있는 것은 Haskell과 함께 제공되는 단점이나 문제입니다. 웹에는 Haskell이 왜 좋은지에 대한 엄청난 양의 정보가 있지만 추악한 측면에 대해서는 많은 주제를 찾지 못했습니다 (내가 신경 쓰지 않는 구문에 대한 그립을 제외하고).

내가 찾고있는 것의 예는 Python의 GIL과 같습니다. CPython 환경에서 동시성을 사용하기 시작했을 때까지 머리를 숙이지 않은 것.

내가 생각할 수있는 몇 가지 단점 :

• 언어의 본질과 학계에서의 확고한 뿌리 때문에 공동체는 매우 수학적인 생각을합니다. 실용적 인 사람이라면 때로는 압도적 일 수 있으며 전문 용어를 말하지 않으면 다른 많은 언어보다 어려움을 겪을 수 있습니다.
• 엄청나게 많은 라이브러리가 있지만 문서는 간결합니다.
• 부드러운 엔트리 레벨 튜토리얼은 찾기가 어렵고 찾기가 어렵 기 때문에 초기 학습 곡선은 매우 가파 릅니다.
• 몇 가지 언어 기능이 불필요하게 어색합니다. 눈에 띄는 예는 레코드 구문이 이름 지정 범위를 도입하지 않는 방법이므로 동일한 모듈 네임 스페이스 내에서 두 개의 다른 유형으로 동일한 레코드 필드 이름을 가질 수있는 방법이 없습니다.
• Haskell은 기본적으로 게으른 평가로 설정되며, 이는 종종 좋은 일이지만 때로는 불쾌한 방법으로 당신을 물 수 있습니다. 사소한 상황에서 게으른 평가를 순진하게 사용하면 불필요한 성능 병목 현상이 발생할 수 있으며, 후드에서 발생하는 상황을 이해하는 것은 정확하지 않습니다.
• 게으른 평가 (특히 순도 및 적극적으로 최적화 된 컴파일러와 결합)는 실행 순서를 쉽게 추론 할 수 없다는 것을 의미합니다. 실제로 특정 상황에서 특정 코드 조각이 실제로 평가되는지 여부조차 알 수 없습니다. 결과적으로, 코드를 단계별로 실행하는 것이 덜 유용하고 덜 중요하기 때문에 Haskell 코드를 디버깅하려면 다른 사고 방식이 필요합니다.
• Haskell의 순도 때문에 부작용을 사용하여 I / O와 같은 작업을 수행 할 수 없습니다. 대화 형 작업을 수행하려면 모나드 및 '학대'게으른 평가를 사용해야하며, I / O를 수행하려는 모든 곳에서 모나드 컨텍스트를 드래그해야합니다. (이것은 실제로 여러 가지면에서 좋은 기능이지만 때때로 실용적인 코딩이 불가능합니다.)

Haskell의 단점 (및 대부분의 Haskell의 단점)은 게으르고 순전히 기능적인 두 가지 특성에서 비롯됩니다.

게으 르면 성능을 추론하기가 더 어려워집니다. 특히 게으름에 익숙하지 않은 사람, 숙련 된 Haskeller의 경우에도 게으름이 특정 경우 성능에 어떤 영향을 미치는지 알기가 어려울 수 있습니다.

게으름은 또한 Criterion과 같은 라이브러리를 사용하지 않고 정확한 벤치 마크를 만드는 것이 더 어렵다는 것을 의미합니다.

순전히 기능적이라는 것은 변경 가능한 데이터 구조를 사용해야 할 때마다 (필요한만큼 자주 발생하지 않는 GHC 옵티 마이저 덕분에 원하는 성능을 달성 할 수없는 경우), IO (또는 ST) 모나드에 갇혀 코드가 더 번거로워집니다.

속도를 목표 중 하나로 언급 했으므로 성능에 많은 생각을하지 않고 작성된 다른 손으로 최적화 된 Haskell 코드와 Haskell 코드간에 성능에 큰 차이가있는 경우가 많습니다 (다른 언어보다). 그리고 수동으로 최적화 된 Haskell 코드는 종종 매우 추악합니다 (그러나 대부분의 다른 언어에서도 마찬가지라고 생각합니다).

저는 Haskell 전문가가 아닙니다. 기본 사항을 배웠지 만 불행히도 Haskell에서 심각한 프로젝트를 수행 할 기회가 없었습니다 (이 언어를 좋아하기 때문에 원합니다).

그러나 내가 아는 것과 기능 프로그래밍과 매우 가까운 분야에서 일하고있는 누군가와의 토론에서 Haskell은 그래프 알고리즘을 구현하려는 경우 최상의 솔루션이 아닐 수 있습니다. 그래프 구조에 대한 많은 지역 변화.

그래프에는 일반적으로 재귀 구조가 없기 때문에 가장 좋은 방법은 (C ++에서와 같이) 구조와 포인터를 사용하여 그래프의 사본 하나를 작성하고 포인터를 변경하여 사본을 조작하는 것입니다. 노드 생성 또는 파괴 등.

Haskell에 대한 지식으로 인해 위의 표현 / 접근 방식을 사용할 수 없으므로 Haskell에서 이러한 데이터 구조 및 작업을 올바르게 처리하는 방법이 궁금합니다. Haskell의 그래프 알고리즘과 관련된 몇 가지 문제는 이 기사 에서 간략하게 설명합니다.

편집하다

필자는 최근 함수 프로그래밍 전문가와 이야기를 나 Has 고 Haskell에서 특정 그래프 알고리즘을 효율적으로 구현하는 것이 매우 까다로울 수 있음을 확인했습니다.

Haskell의 단점은 다릅니다. 더 일반적으로 배우거나 이야기하는 언어에서 멀어지기 때문에 더 큰 학습 곡선이 있습니다. 또한 언어에 대한 인기도 떨어지기 때문에 도움을받을 수 없을 때 도움을받을 수 없습니다. 이것들은 실제로 큰 단점이 아닙니다.

잠재적 단점은 기능 언어이므로 특정 문제 영역에서는 유용하지 않지만 객체 지향 언어에서도 마찬가지입니다. 일반적으로 언어는 적어도 상대적으로 인기있는 언어에 대해서는 학습 곡선 이상의 진정한 부정을 갖지 않습니다. 언어가 튜링이 완료되는 한 이론적으로는 아무 것도 가능합니다.

그래서, 내가 찾고있는 것은 Haskell과 함께 오는 단점이나 문제입니다.

"하스켈 문제"는 특정 도메인에 나타나는 경향이 있습니다. Haskell은 응용 프로그램 프로그래밍을위한 훌륭한 언어로, 다른 어떤 것보다 훨씬 즐겁게 작성합니다. 다음과 같이 잘 지원되지 않는 작업을 수행하려고하면 문제가 발생하는 경향이 있습니다.

• 크로스 컴파일. GHC는 크로스 컴파일러로 구축 될 수 있지만 프로세스는 다소 복잡합니다.
• 임베디드 애플리케이션. Haskell은 가비지 콜렉터를 통한 메모리 관리 기능을 갖추고 있으므로 놀랍지 않습니다.
• 속도. Haskell은 Rust만큼 빠르지는 않지만 대부분의 경우 상당히 잘 경쟁합니다. 순수한 계산은 잘 최적화되지만 "파일을 버퍼로 읽고 행 수를 세는 것"과 같은 것은 Haskell에서 표현하기가 더 어렵습니다.