Haskell 개발자들은 언어의 어떤 점을 개선하고 싶어할까?

설문조사에서는 텍스트 데이터 타입으로 String 대신 Text 사용을 제안하는 의견이 다수였다. 특히, `base` 라이브러리에서 `Text`를 사용할 수 없어 초보자와 숙련자 모두에게 불편함을 야기한다는 지적이다. 이는 Haskell 생태계에서 문자열 처리(String Handling)의 일관성을 높이고, 성능 최적화(Performance Optimization)를 위한 중요한 개선 사항으로 여겨진다.

Haskell 커뮤니티는 초보자를 위한 자료 부족(Lack of Resources)과 중앙화된 진입점 부재(Centralized Entry Point)에 대한 우려를 표명했다. 최신 자료(Up-to-date Content)와 쉬운 접근성(Easy Accessibility)을 강조하며, Haskell Wiki의 기여 감소를 지적했다. 이는 언어의 학습 곡선(Learning Curve)을 완화하고, 커뮤니티 참여(Community Participation)를 활성화하기 위한 중요한 과제이다.

설문조사 참여자들은 Haskell 언어의 복잡성(Complexity), 과거의 잔재(Historical Cruft), 그리고 언어와 라이브러리의 일관성 부족(Lack of Consistency)을 지적했다. 특히, `Prelude`의 부분 함수(Partial Functions) 사용을 지양하고, 안전한 기본값을 설정하는 것을 제안했다. 이는 Haskell의 핵심 강점(Core Strengths)을 살리고, 개발자 생산성(Developer Productivity)을 향상시키기 위한 노력의 일환이다.

Haskell 커뮤니티는 컴파일 시간(Compilation Time) 단축과 개발자 경험(Developer Experience) 개선을 강력하게 요구했다. 특히, GHC 컴파일러의 속도 향상과 오류 메시지(Error Messages) 개선에 대한 요구가 높았다. 또한, uv와 같은 통합된 툴체인(Toolchain)을 예시로 들며, 도구 생태계(Tooling Ecosystem)의 통합을 희망했다. 이는 개발 과정의 효율성(Efficiency)을 높이고, 학습 장벽(Learning Barrier)을 낮추는 데 기여할 것이다.

Haskell 개발자들은 레이지 평가(Lazy Evaluation)에 대한 어려움을 지속적으로 호소하며, 디버깅 도구(Debugging Tools) 개선을 요구했다. Lazy I/O와 같은 런타임 동작(Runtime Behavior)에 대한 이해 부족으로 인한 문제점을 지적하며, StrictData 확장과 같은 해결책을 제시했다. 이는 Haskell 프로그램의 안정성(Reliability)을 높이고, 디버깅 과정(Debugging Process)을 용이하게 하기 위한 노력이다.