6 ms·

Haskell without lens, text, vector, etc... is a bit like rust with only core not std. The haskell standard library is tiny. Libraries like lens are not optiona

Haskell without lens, text, vector, etc... is a bit like rust with only core not std. The haskell standard library is tiny. Libraries like lens are not optional. In practice you won't understand any open source Haskell without rudimentary understanding of lens. I get why parser libraries were banned, but excluding lens, vector, and text? I like Rust a lot, but haskell minus it's more advanced type system is just Rust plus GC. Lets not pretend this is a fair comparison of languages when it's primarily a comparison of standard libraries.

sbergot 7y ago
This is why I gave up on Haskell. Lens works as advertised, but is a pain to learn and to use in practice: the abstraction is tough to grasp and it is hard to form an intuition about it. The compilation errors are laughingly esoteric. The number of adhoc squwiggly operators is ridiculous. You also need to understand a lot of language extensions to get how the type checking works. To me it looks like an impressive proof of concept for a future programming language based around it. If I were to start a project with Haskell the use of lens would be explicitly forbidden.
- dymk 7y ago
  It's about as esoteric as somebody learning C++ for the first time. And from that perspective, it's totally normal for errors or syntax to be weird looking for a long time. Most of us, including myself, are biased towards languages like Java, C, C++, Javascript, because those are what we learn first - and so our expectations of what errors (or syntax) look like are shaped by our early experiences. So I don't think it's fair to say that Haskell's compiler errors or quirks are fundamentally less intuitive than something that GCC/G++ spits out even on a sunny day. Just odd when we expect errors to look a particular way, but Haskell is playing a totally different (not exactly harder) game.
  - posterboy 7y ago
    We learn those first, that are not developed as a research platform that happens to have a little production use.
  - sbergot 7y ago
    I didn't say Haskell's error messages are bad. If you stick with explicit types on your functions and no language extension they are absolutely great. I wanted to point out that type checking errors with lens are hard unless you really know how all the different type aliases relate to each other. It was a few years ago so maybe things are better. C++ also had this problem with the standard containers. However it is much easier to get what is a dictionary compared to a random "optic".
    - dymk 7y ago
      > However it is much easier to get what is a dictionary compared to a random "optic". This is exactly what I disagree with. We come from a prior understanding of mutable/imperative dictionary/shared_ptr/std::pair, because that's what we started out with. Had we been initially been trained on monads, functors, lenses, those would be the familiar tools, and we'd go "Huh, that's an... interesting way to write code" when faced with C++ for the first time.
      - smallnamespace 7y ago
        > because that's what we started out with Yes, but not from programming, but from general life experience. Everyone knows what an actual dictionary is, and even non-programmers can easily grasp how a one-way 'map' works. Mutation is also how the real world works. If you want to record something, you write it down—you've just mutated the world, not encapsulated your operation in the WorldState monad. You need to build a pile of mathematical abstractions in your head before you can really get off the ground with lenses. Not everyone has that aptitude or interest.
        dymk 7y ago
        Haskell has maps. You 100% do not need to build a "pile of mathematical abstractions in your head" to use lenses. It's a handful of types and functions. Do you need to build a pile of abstractions in your head to use `std::unordered_map` or getters/setters in C++?
  - StreamBright 7y ago
    Not at all. Several languages Rust included takes understandable errors seriously. I am a Rust newbie but the errors are extremely easy to grasp and fix my code.
    - dymk 7y ago
      You say "not at all", but only cite Rust (which I didn't mention). C++ has horiffic error messages, certainly at the level of a bad Haskell error message. I'd say my point stands pretty well.
      - Avamander 7y ago
        Some C++ has horrific messages, new compilers do a much better job at complaining about most errors - some even suggest fixes. I don't remember seeing Haskell doing that.
        agentultra 7y ago
        Haskell does do that. It provides suggestions and alternatives: you probably meant X or you forgot an import to Y or try enabling the Z extension.
      - oblio 7y ago
        So your defense for Haskell's error messages is that they're slightly better than what you get from a massively entrenched language with famously user hostile error messages? Good luck with that :)
      - liquidify 7y ago
        I don't think C++ errors are bad any more. 2019 compilers generally produce very good error messages. The situations where you get into pages of template nonsense in an error are becoming fewer and further between all the time.
        fmap 7y ago
        C++ has bad error messages because of language design. Contemporary C++ compilers are very good at reporting clear error messages about common mistakes, but template heavy code still yields arcane error messages. Templates are untyped, so there is no way to give sensible error messages when defining or instantiating a template. Instead you have to typecheck after template expansion, at which point you are left with an error message about compiler generated code. There are some proposals which address this (e.g., concepts), but none of them are part of the language standard yet. Concepts in particular made it into the C++20 draft, but they also made it into a draft of the C++17 standard and were ultimately rejected. Somewhat vexingly C++ concepts actually come with the same problems only at the level of concepts instead of at the level of templates.
  - fluffything 7y ago
    > And from that perspective, it's totally normal for errors or syntax to be weird looking for a long time. This isn't normal. This is just using a tool that sucks. Those who consider this normal are just masochists. Rust, elm, etc. have great error messages. That took a lot of time and effort to achieve. The fact that it is impossible to implement a C++ compiler that produces good error message is just proof about how broken the language is. The fact that some people find this normal is just Stockholm syndrom at work.
- Avi-D-coder 7y ago
  Take a look at https://github.com/well-typed/optics https://github.com/well-typed/optics. It's like lens, but with the design goal of being easier to use and producing better error messages.
- mlthoughts2018 7y ago
  Same for me, except also the incredibly obtuse set of ~20 compiler pragmas you need in Haskell. If you ask for help to do some simple programming concept, like multiple dispatch based on type at runtime, then from the Haskell community you first get a bunch of tone deaf “you shouldn’t want to ever do that” responses, followed by a huge tome of all the language extensions (fundamentally changing or adding syntax) that you need.
  - tathougies 7y ago
    With the exception of very few extensions that I've never seen used in practice, Haskell language extensions are mutually compatible and create a language that is a strict superset of the old language. In this sense, I'm not sure how they're much different than the --c++=14 flag in GCC.
    - mlthoughts2018 7y ago
      If you need to know and understand syntax implications on highly generic type pattern constructs coming from a dozen external pragmas, just to be able to read the code then it’s a severe language design problem.
orbifold 7y ago
That's a total stretch, lens is not used in GHC for example and lots of other smaller compilers written in Haskell. It is used in Ermine but that is stuck in a semi complete state for a while now and Ekmett has moved on.
- runeks 7y ago
  I second this. I’ve written tens of thousands of lines of Haskell, and I’ve never used lens. Also, putting it in the same category as text and vector doesn’t make sense — these are indeed unavoidable, and practically all my projects use them.
  - deleted 7y ago
    [deleted]
  - smichael 7y ago
    Thirded. No lens in pandoc (50k lines of haskell), darcs (40k), most hledger packages (15k).
- deleted 7y ago
  [deleted]
k_bx 7y ago
I disagree about lens. My new projects don't use them in main code-base and it was a great decision: - TAGS work like a charm to access field definitions - compile times are ok Of course, if library's API needs lens, they're used.
- deleted 7y ago
  [deleted]
- exceptione 7y ago
  What do you mean with TAGS?
  - sanityinc 7y ago
    Presumably etags/gtags/hasktags etc., ie. having built a TAGS database for such a helper program, you can use it in an editor to jump from a field name to its definition. That wouldn't be the case with a lens accessor.
  - k_bx 7y ago
    File named TAGS generated from hasktags (in case of Haskell) that gives you an easy way to "jump to definition" from Emacs or other editors. Good way to navigate codebases even if you don't know how to build them.
Kenji 7y ago
> I like Rust a lot, but haskell minus it's more advanced type system is just Rust plus GC. Complete baloney. Haskell does not allow any imperative programming. Haskell is functional and disallows imperative, Rust supports functional but is largely imperative. Rust is vastly superior to Haskell and I say this as someone who has put many hours in both languages at this point. Also, its*.
lngnmn1 7y ago
GHC does not use lens and it is, it seems, ok.

sbergot 7y ago

This is why I gave up on Haskell. Lens works as advertised, but is a pain to learn and to use in practice: the abstraction is tough to grasp and it is hard to form an intuition about it. The compilation errors are laughingly esoteric. The number of adhoc squwiggly operators is ridiculous. You also need to understand a lot of language extensions to get how the type checking works. To me it looks like an impressive proof of concept for a future programming language based around it. If I were to start a project with Haskell the use of lens would be explicitly forbidden.

dymk 7y ago
It's about as esoteric as somebody learning C++ for the first time. And from that perspective, it's totally normal for errors or syntax to be weird looking for a long time. Most of us, including myself, are biased towards languages like Java, C, C++, Javascript, because those are what we learn first - and so our expectations of what errors (or syntax) look like are shaped by our early experiences. So I don't think it's fair to say that Haskell's compiler errors or quirks are fundamentally less intuitive than something that GCC/G++ spits out even on a sunny day. Just odd when we expect errors to look a particular way, but Haskell is playing a totally different (not exactly harder) game.
- posterboy 7y ago
  We learn those first, that are not developed as a research platform that happens to have a little production use.
- sbergot 7y ago
  I didn't say Haskell's error messages are bad. If you stick with explicit types on your functions and no language extension they are absolutely great. I wanted to point out that type checking errors with lens are hard unless you really know how all the different type aliases relate to each other. It was a few years ago so maybe things are better. C++ also had this problem with the standard containers. However it is much easier to get what is a dictionary compared to a random "optic".
  - dymk 7y ago
    > However it is much easier to get what is a dictionary compared to a random "optic". This is exactly what I disagree with. We come from a prior understanding of mutable/imperative dictionary/shared_ptr/std::pair, because that's what we started out with. Had we been initially been trained on monads, functors, lenses, those would be the familiar tools, and we'd go "Huh, that's an... interesting way to write code" when faced with C++ for the first time.
    - smallnamespace 7y ago
      > because that's what we started out with Yes, but not from programming, but from general life experience. Everyone knows what an actual dictionary is, and even non-programmers can easily grasp how a one-way 'map' works. Mutation is also how the real world works. If you want to record something, you write it down—you've just mutated the world, not encapsulated your operation in the WorldState monad. You need to build a pile of mathematical abstractions in your head before you can really get off the ground with lenses. Not everyone has that aptitude or interest.
      - dymk 7y ago
        Haskell has maps. You 100% do not need to build a "pile of mathematical abstractions in your head" to use lenses. It's a handful of types and functions. Do you need to build a pile of abstractions in your head to use `std::unordered_map` or getters/setters in C++?
- StreamBright 7y ago
  Not at all. Several languages Rust included takes understandable errors seriously. I am a Rust newbie but the errors are extremely easy to grasp and fix my code.
  - dymk 7y ago
    You say "not at all", but only cite Rust (which I didn't mention). C++ has horiffic error messages, certainly at the level of a bad Haskell error message. I'd say my point stands pretty well.
    - Avamander 7y ago
      Some C++ has horrific messages, new compilers do a much better job at complaining about most errors - some even suggest fixes. I don't remember seeing Haskell doing that.
      - agentultra 7y ago
        Haskell does do that. It provides suggestions and alternatives: you probably meant X or you forgot an import to Y or try enabling the Z extension.
    - oblio 7y ago
      So your defense for Haskell's error messages is that they're slightly better than what you get from a massively entrenched language with famously user hostile error messages? Good luck with that :)
    - liquidify 7y ago
      I don't think C++ errors are bad any more. 2019 compilers generally produce very good error messages. The situations where you get into pages of template nonsense in an error are becoming fewer and further between all the time.
      - fmap 7y ago
        C++ has bad error messages because of language design. Contemporary C++ compilers are very good at reporting clear error messages about common mistakes, but template heavy code still yields arcane error messages. Templates are untyped, so there is no way to give sensible error messages when defining or instantiating a template. Instead you have to typecheck after template expansion, at which point you are left with an error message about compiler generated code. There are some proposals which address this (e.g., concepts), but none of them are part of the language standard yet. Concepts in particular made it into the C++20 draft, but they also made it into a draft of the C++17 standard and were ultimately rejected. Somewhat vexingly C++ concepts actually come with the same problems only at the level of concepts instead of at the level of templates.
- fluffything 7y ago
  > And from that perspective, it's totally normal for errors or syntax to be weird looking for a long time. This isn't normal. This is just using a tool that sucks. Those who consider this normal are just masochists. Rust, elm, etc. have great error messages. That took a lot of time and effort to achieve. The fact that it is impossible to implement a C++ compiler that produces good error message is just proof about how broken the language is. The fact that some people find this normal is just Stockholm syndrom at work.
Avi-D-coder 7y ago
Take a look at https://github.com/well-typed/optics https://github.com/well-typed/optics. It's like lens, but with the design goal of being easier to use and producing better error messages.
mlthoughts2018 7y ago
Same for me, except also the incredibly obtuse set of ~20 compiler pragmas you need in Haskell. If you ask for help to do some simple programming concept, like multiple dispatch based on type at runtime, then from the Haskell community you first get a bunch of tone deaf “you shouldn’t want to ever do that” responses, followed by a huge tome of all the language extensions (fundamentally changing or adding syntax) that you need.
- tathougies 7y ago
  With the exception of very few extensions that I've never seen used in practice, Haskell language extensions are mutually compatible and create a language that is a strict superset of the old language. In this sense, I'm not sure how they're much different than the --c++=14 flag in GCC.
  - mlthoughts2018 7y ago
    If you need to know and understand syntax implications on highly generic type pattern constructs coming from a dozen external pragmas, just to be able to read the code then it’s a severe language design problem.

orbifold 7y ago

That's a total stretch, lens is not used in GHC for example and lots of other smaller compilers written in Haskell. It is used in Ermine but that is stuck in a semi complete state for a while now and Ekmett has moved on.

runeks 7y ago
I second this. I’ve written tens of thousands of lines of Haskell, and I’ve never used lens. Also, putting it in the same category as text and vector doesn’t make sense — these are indeed unavoidable, and practically all my projects use them.
- deleted 7y ago
  [deleted]
- smichael 7y ago
  Thirded. No lens in pandoc (50k lines of haskell), darcs (40k), most hledger packages (15k).
deleted 7y ago
[deleted]

k_bx 7y ago

I disagree about lens. My new projects don't use them in main code-base and it was a great decision: - TAGS work like a charm to access field definitions - compile times are ok Of course, if library's API needs lens, they're used.

deleted 7y ago
[deleted]
exceptione 7y ago
What do you mean with TAGS?
- sanityinc 7y ago
  Presumably etags/gtags/hasktags etc., ie. having built a TAGS database for such a helper program, you can use it in an editor to jump from a field name to its definition. That wouldn't be the case with a lens accessor.
- k_bx 7y ago
  File named TAGS generated from hasktags (in case of Haskell) that gives you an easy way to "jump to definition" from Emacs or other editors. Good way to navigate codebases even if you don't know how to build them.

Kenji 7y ago

> I like Rust a lot, but haskell minus it's more advanced type system is just Rust plus GC. Complete baloney. Haskell does not allow any imperative programming. Haskell is functional and disallows imperative, Rust supports functional but is largely imperative. Rust is vastly superior to Haskell and I say this as someone who has put many hours in both languages at this point. Also, its*.

lngnmn1 7y ago

GHC does not use lens and it is, it seems, ok.