5 ms·

As a recent beginner to Haskell, are there other big outstanding issues with the GHC to watch out for?

by dopu 10y ago

MichaelBurge 10y ago
The record issue is a widespread inconvenience, but ultimately nothing more than an inconvenience. Most people just prepended the type in their fields: 'person_name' and 'object_name'. Some other issues might be: * The Prelude is hard to update for compatibility reasons, so it clashes with modern Haskell somewhat. A lot of projects will roll their own prelude and add 'NoImplicitPrelude' to the project options. * There's also this presentation: https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why-haskell-sucks.html#1 https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why... * Deploying Haskell programs to older corporate servers is doable, but not at all obvious. Stick with C, Bash, and older Perls(5.8.8 is on my router) for maximum portability, if you expect to deploy to servers with a 10 year old image.
- iso-8859-1 10y ago
  Regarding deployment, why not just link statically? http://stackoverflow.com/a/5953787/309483 http://stackoverflow.com/a/5953787/309483
  - jeremyjh 10y ago
    This isn't portable with glibc. (It isn't for C/C++ programs, either). You can build GHC with musl libc and then make truly portable static binaries but it isn't that easy. https://www.reddit.com/r/haskell/comments/37m7q7/ghc_musl_easier_static_linking/ https://www.reddit.com/r/haskell/comments/37m7q7/ghc_musl_ea...
  - MichaelBurge 10y ago
    You can't link glibc statically for technical reasons. In some sense, this is the only problem I had. If there was a way to use an alternate libc, it would probably eliminate this issue entirely.
    - carterschonwald 10y ago
      I know there was some work to do a musl and or alpine Linux build. Or both, probably easy to google. Also I'm moderately certain that ghc on FreeBSD and Mac don't need glibc ;)
      - cm3 10y ago
        Targeting musl works out of the box with the musl toolchain and once you have a musl build you can build another ghc with that one with musl as the host. I haven't tried building a statically linked musl ghc, and I honestly don't know how, but it'd be great to figure out. Any pointers? Speaking of static musl builds, that can be a good choice to create a single bindist of GHC that works on CentOS, Debian, Alpine, and any other Linux distro. Seeing how Docker defaults to Alpine images, it could be beneficial in that regard as well.
      - mitchty 10y ago
        Already built for alpine linux, and I have it setup to use a stage 2 bootstrap. So you build off debian, then build locally to build an alpine apk. https://github.com/mitchty/alpine-linux-ghc-bootstrap https://github.com/mitchty/alpine-linux-ghc-bootstrap Recently updated last week to 8.0.1, and its submitted upstream but not yet accepted because alpine linux 3.4 is about to come out. If you want to try it now you can docker pull mitchty/alpine-ghc:8.0
- carterschonwald 10y ago
  we've deployed modern haskell onto RHEL 6.5 systems at work, and thats not too bad (just some dy load library path hackery at worst)
- userbinator 10y ago
  Most people just prepended the type in their fields: 'person_name' and 'object_name'. Coincidentally, the reason why that practice is still visible in some C structures today is because very early C compilers had a similar limitation: http://stackoverflow.com/questions/35874187/prefixes-in-member-names-of-a-struct http://stackoverflow.com/questions/35874187/prefixes-in-memb...
- GreaterFool 10y ago
  Record issue is more than just an inconvenience. I consider it a genuine issue. Having to add 2 lines of import (unqualified name of the type and qualified record module to get the accessors) for every record type you use is a pain. When you work with data-heavy code this ends up hundred of lines of import (see amazonka packages for instance where each request has a record type).
  - gizmo686 10y ago
    Even if it doubles the number of import statements, I still don't see how that is more than an inconvenience. Having said that, the record issue alone is not the only reason to need qualified imports (as they are also used to resolve collisions of functions that are not auto generated from records). What would be nice is if Haskell would allow any name collision so long as it could use the type system to disambiguate the function.
    - eru 10y ago
      > What would be nice is if Haskell would allow any name collision so long as it could use the type system to disambiguate the function. That would need very careful design to work well with type inference, I suppose?
      - johncolanduoni 10y ago
        Idris[1] already has a working system for this, and it's type system is more complicated (it has much more support for dependent typing). It allows this principle for regular function names as well. [1]: http://www.idris-lang.org/ http://www.idris-lang.org/
        eru 10y ago
        Thanks! I'm glad we have a working model we can probably copy from.
    - chadaustin 10y ago
      Your argument generalizes to "The lack of any feature that can be worked around is an inconvenience", which, okay, but it's not a very useful statement. By that definition, lots of really important things are inconveniences.
deleted 10y ago
[deleted]
rjayatilleka 10y ago
There was a large (but informal) survey done on /r/haskell (one of the largest Haskell communities) last month about "Why Haskell sucks". The results were collated into a presentation linked below. It's a very detailed review that covers just about everything "bad" about Haskell (though I think it views each issue rather optimistically). Presentation: https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why-haskell-sucks.html#1 https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why... EDIT: Also, if you find the colors on the slide show intolerable, the page source is well-formatted and readable. Content starts at line 200.
- Johnny_Brahms 10y ago
  about the edit: you can just disable js and read it as a markdown source if you like.
sdegutis 10y ago
Here are some useful Haskell extensions: http://sdegutis.github.io/2015-03-17/haskell-extensions/ http://sdegutis.github.io/2015-03-17/haskell-extensions/

As a recent beginner to Haskell, are there other big outstanding issues with the GHC to watch out for?

by dopu 10y ago

As a recent beginner to Haskell, are there other big outstanding issues with the GHC to watch out for?

The record issue is a widespread inconvenience, but ultimately nothing more than an inconvenience. Most people just prepended the type in their fields: 'person_name' and 'object_name'. Some other issues might be: * The Prelude is hard to update for compatibility reasons, so it clashes with modern Haskell somewhat. A lot of projects will roll their own prelude and add 'NoImplicitPrelude' to the project options. * There's also this presentation: https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why-haskell-sucks.html#1 https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why... * Deploying Haskell programs to older corporate servers is doable, but not at all obvious. Stick with C, Bash, and older Perls(5.8.8 is on my router) for maximum portability, if you expect to deploy to servers with a 10 year old image.

iso-8859-1 10y ago
Regarding deployment, why not just link statically? http://stackoverflow.com/a/5953787/309483 http://stackoverflow.com/a/5953787/309483
- jeremyjh 10y ago
  This isn't portable with glibc. (It isn't for C/C++ programs, either). You can build GHC with musl libc and then make truly portable static binaries but it isn't that easy. https://www.reddit.com/r/haskell/comments/37m7q7/ghc_musl_easier_static_linking/ https://www.reddit.com/r/haskell/comments/37m7q7/ghc_musl_ea...
- MichaelBurge 10y ago
  You can't link glibc statically for technical reasons. In some sense, this is the only problem I had. If there was a way to use an alternate libc, it would probably eliminate this issue entirely.
  - carterschonwald 10y ago
    I know there was some work to do a musl and or alpine Linux build. Or both, probably easy to google. Also I'm moderately certain that ghc on FreeBSD and Mac don't need glibc ;)
    - cm3 10y ago
      Targeting musl works out of the box with the musl toolchain and once you have a musl build you can build another ghc with that one with musl as the host. I haven't tried building a statically linked musl ghc, and I honestly don't know how, but it'd be great to figure out. Any pointers? Speaking of static musl builds, that can be a good choice to create a single bindist of GHC that works on CentOS, Debian, Alpine, and any other Linux distro. Seeing how Docker defaults to Alpine images, it could be beneficial in that regard as well.
    - mitchty 10y ago
      Already built for alpine linux, and I have it setup to use a stage 2 bootstrap. So you build off debian, then build locally to build an alpine apk. https://github.com/mitchty/alpine-linux-ghc-bootstrap https://github.com/mitchty/alpine-linux-ghc-bootstrap Recently updated last week to 8.0.1, and its submitted upstream but not yet accepted because alpine linux 3.4 is about to come out. If you want to try it now you can docker pull mitchty/alpine-ghc:8.0
carterschonwald 10y ago
we've deployed modern haskell onto RHEL 6.5 systems at work, and thats not too bad (just some dy load library path hackery at worst)
userbinator 10y ago
Most people just prepended the type in their fields: 'person_name' and 'object_name'. Coincidentally, the reason why that practice is still visible in some C structures today is because very early C compilers had a similar limitation: http://stackoverflow.com/questions/35874187/prefixes-in-member-names-of-a-struct http://stackoverflow.com/questions/35874187/prefixes-in-memb...
GreaterFool 10y ago
Record issue is more than just an inconvenience. I consider it a genuine issue. Having to add 2 lines of import (unqualified name of the type and qualified record module to get the accessors) for every record type you use is a pain. When you work with data-heavy code this ends up hundred of lines of import (see amazonka packages for instance where each request has a record type).
- gizmo686 10y ago
  Even if it doubles the number of import statements, I still don't see how that is more than an inconvenience. Having said that, the record issue alone is not the only reason to need qualified imports (as they are also used to resolve collisions of functions that are not auto generated from records). What would be nice is if Haskell would allow any name collision so long as it could use the type system to disambiguate the function.
  - eru 10y ago
    > What would be nice is if Haskell would allow any name collision so long as it could use the type system to disambiguate the function. That would need very careful design to work well with type inference, I suppose?
    - johncolanduoni 10y ago
      Idris[1] already has a working system for this, and it's type system is more complicated (it has much more support for dependent typing). It allows this principle for regular function names as well. [1]: http://www.idris-lang.org/ http://www.idris-lang.org/
      - eru 10y ago
        Thanks! I'm glad we have a working model we can probably copy from.
  - chadaustin 10y ago
    Your argument generalizes to "The lack of any feature that can be worked around is an inconvenience", which, okay, but it's not a very useful statement. By that definition, lots of really important things are inconveniences.

deleted 10y ago

[deleted]

rjayatilleka 10y ago

There was a large (but informal) survey done on /r/haskell (one of the largest Haskell communities) last month about "Why Haskell sucks". The results were collated into a presentation linked below. It's a very detailed review that covers just about everything "bad" about Haskell (though I think it views each issue rather optimistically). Presentation: https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why-haskell-sucks.html#1 https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why... EDIT: Also, if you find the colors on the slide show intolerable, the page source is well-formatted and readable. Content starts at line 200.

Johnny_Brahms 10y ago
about the edit: you can just disable js and read it as a markdown source if you like.

sdegutis 10y ago

Here are some useful Haskell extensions: http://sdegutis.github.io/2015-03-17/haskell-extensions/ http://sdegutis.github.io/2015-03-17/haskell-extensions/