4 ms·

The biggest wart for me is the complexity introduced by language extensions, many of which can significantly alter the behaviour and feature set. There is not

The biggest wart for me is the complexity introduced by language extensions, many of which can significantly alter the behaviour and feature set. There is not one Haskell, there are many flavors of Haskell, and every file can be a different subset because extensions can be toggled by file ( `{-# LANGUAGE <Extension> #-}` ). My second biggest wart is the heterogeneous nature of the ecosystem due to lack of established paradigms, and the heavy use of complex type system abstractions in some libraries (plus the common lack of good documentation). I love Haskell as a language for the learning experience, but I would not use it in a professional/production environment.

mightybyte 6y ago
I agree with you that the many flavors of Haskell are problematic when it comes to uniformity. C++ and Scala have similar challenges. The old trope of every C++ shop using their own unique subset of the language is pretty relevant here. One thing in Haskell's favor though...with the language extension paradigm you have a very clear and tangible path to enforcing uniformity in your codebase that you don't have in C++ or Scala. You can use simple code analysis tools (I believe hlint already has this functionality, but just grep is sufficient actually) to enforce your team's choice of language extensions.
- agentultra 6y ago
  Many build tools also let you configure the common set of extensions. You shouldn't be forced to set them on a per-file basis. There's finally an effort to update the Haskell spec and many of the most common extensions are slated to be included so we won't have to use so many for "common Haskell" soon.
  - the_duke 6y ago
    > There's finally an effort to update the Haskell spec That's great to hear! But in the future it would also be great if Haskell took a route similar to Rust. In Rust, extensions (called features) only work on the nightly compiler. On stable and beta compilers, they produce an error. Only once they are officially accepted and finalized will they work on stable. That gives both users and compiler/std lib developers the freedom to experiment, but prevents a proliferation of a complicated feature matrix and centralizes the ecosystem on a coherent language spec. This has worked out really well. In the early days many users were stuck nightly because of essential features, but by now libraries are expected to work on stable.
    - agentultra 6y ago
      I'm glad that works for Rust but I don't see it being compatible with the way Haskell has been developed. Haskell the language is defined by a specification called the Haskell Report. The last one was Haskell 2010 [0]. The news is that the next version of this report will incorporate advances from several GHC-specific language extensions. How useful this is in modern Haskell remains to be seen. As far as I can tell the de-facto Haskell compiler is GHC. Hugs is unmaintained and UHC and LHC are mostly experimental or in-development. However without a spec we can't get innovation from alternative implementations of the language. [0] https://www.haskell.org/onlinereport/haskell2010/ https://www.haskell.org/onlinereport/haskell2010/

mightybyte 6y ago

I agree with you that the many flavors of Haskell are problematic when it comes to uniformity. C++ and Scala have similar challenges. The old trope of every C++ shop using their own unique subset of the language is pretty relevant here. One thing in Haskell's favor though...with the language extension paradigm you have a very clear and tangible path to enforcing uniformity in your codebase that you don't have in C++ or Scala. You can use simple code analysis tools (I believe hlint already has this functionality, but just grep is sufficient actually) to enforce your team's choice of language extensions.

agentultra 6y ago
Many build tools also let you configure the common set of extensions. You shouldn't be forced to set them on a per-file basis. There's finally an effort to update the Haskell spec and many of the most common extensions are slated to be included so we won't have to use so many for "common Haskell" soon.
- the_duke 6y ago
  > There's finally an effort to update the Haskell spec That's great to hear! But in the future it would also be great if Haskell took a route similar to Rust. In Rust, extensions (called features) only work on the nightly compiler. On stable and beta compilers, they produce an error. Only once they are officially accepted and finalized will they work on stable. That gives both users and compiler/std lib developers the freedom to experiment, but prevents a proliferation of a complicated feature matrix and centralizes the ecosystem on a coherent language spec. This has worked out really well. In the early days many users were stuck nightly because of essential features, but by now libraries are expected to work on stable.
  - agentultra 6y ago
    I'm glad that works for Rust but I don't see it being compatible with the way Haskell has been developed. Haskell the language is defined by a specification called the Haskell Report. The last one was Haskell 2010 [0]. The news is that the next version of this report will incorporate advances from several GHC-specific language extensions. How useful this is in modern Haskell remains to be seen. As far as I can tell the de-facto Haskell compiler is GHC. Hugs is unmaintained and UHC and LHC are mostly experimental or in-development. However without a spec we can't get innovation from alternative implementations of the language. [0] https://www.haskell.org/onlinereport/haskell2010/ https://www.haskell.org/onlinereport/haskell2010/