4 ms·

I always scares me how little I understand from comments talking about Haskell. Either I'm much more dumb that I though, or the whole community decided that pur

I always scares me how little I understand from comments talking about Haskell. Either I'm much more dumb that I though, or the whole community decided that purity beat practicality.

lmm 8y ago
Quite the opposite; the community is very practicality-oriented. There's just a different style of naming things, because things in Haskell tend to be more general. But in most languages any frameworks will introduce their own terminology; comments about the details of (say) React observables are just as incomprehensible if you're not familiar with React.
- sametmax 8y ago
  Well, the facebook team decided to use a specific variation (monodirectional with no side effect) of MVC and rename it flux to confuse everybody. So I react is probably not a good software to measure yourself against when it comes to clarity.
  - lmm 8y ago
    It was a random choice of big-name framework; I could say the same of Rails or Spring or anything. Naming things is hard, and the same pattern is constantly rediscovered in different places. If anything I'd say Haskell's difficulties come from the other end: being too willing to respect the "original" name of a concept from an old mathematical paper rather than coming up with a branding that programmers will be more comfortable with.
    - sametmax 8y ago
      I get the point: we love to rename things, and Haskell is using the proper mathematical name. There must be a balance somewhere though.
      - mickronome 8y ago
        The parent seems to agree with you, that Haskell is maybe too eager to keep to 'mathematical' names, but it almost sounds like you interpreted the parent the other way around? Your comment reads almost equally well with two different interpretations. One a restatement of fact, and the other a rather rude response to a misunderstood message.
      - bbeonx 8y ago
        One issue I have with ad hoc naming convention is that while they may make the first month of learning nice and easy they usually don't have the nice synthesizing effect where all of your notations come together beautifully. Math is terse and there is an initial hurdle to get over. However, once that initial hurdle is cleared there are a lot of things that become obvious as a direct consequence of the notational bootstrapping that we did. With that said, every time I start looking at Haskell I end up playing with category theory instead which may be indicative of something.
      - pyrale 8y ago
        There may not be a general balance. That would explain why so many languages scratch different people's itches.
Filligree 8y ago
Eta-conversion is just the statement that having function(x) { f(x) }, in JS, is equivalent to having f. In short, wrapping a function in another function (or removing such a layer) makes no difference. Like most of lambda calculus, this is extremely intuitive once described that way. Therefore, a situation for which it is false is disconcerting. It's also considered one of the "monad laws", which is the small set of rules that everyone assumes is true for every monad, but which the language doesn't (can't) enforce via the type system. ⊥, pronounced bottom, is a "value" that, if you ask for it, your program breaks. It may go into an infinite loop, or it may crash. The GP post is therefore explaining that, because eta conversion in this case fails when the function returns bottom, we should be disconcerted. It's a mild form of disconcertion, however: Things would only go wonky if you try to run code that would, in any case, hang or crash. The reason it isn't completely harmless is that the difference may be observable: A crash in pure code triggers an exception, which can be caught in its impure wrapper code, and a hang can in some cases be converted to an exception by the garbage collector. In theory all bottoms are equal, but in practice they aren't.
- sametmax 8y ago
  Thank you.
kazagistar 8y ago
You arent "dumb" if you don't known how to play some game or speak some language; you just haven't taken the time to learn it yet.
- sametmax 8y ago
  Yeah but I'm suppose to be a "game player" with 15 years of experience at this point :)
  - bojo 8y ago
    I've been playing the game of Go for 15 years. I barely know how to play Chess beyond moving the pieces. They are both board games played on a grid. I should be a pro at Chess based on my Go experience? Haskell isn't completely different from your standard imperative programming language (functions, variables, etc), but it is definitely a different enough paradigm that you can't just pick it up in a day or two based on your existing experience. My biggest struggle when I picked it up 4 years ago was unlearning my imperative knowledge. Once I was able to throw away my initial preconceptions things got easier. On the other hand, software engineering is still software engineering. Regardless of what tools you use, you usually have to solve them in a similar way. Your 15 years are still useful :)
    - sametmax 8y ago
      That's actually the most encouraging comment about haskell i read in a while.
deleted 8y ago
[deleted]

I always scares me how little I understand from comments talking about Haskell. Either I'm much more dumb that I though, or the whole community decided that purity beat practicality.

lmm 8y ago

Quite the opposite; the community is very practicality-oriented. There's just a different style of naming things, because things in Haskell tend to be more general. But in most languages any frameworks will introduce their own terminology; comments about the details of (say) React observables are just as incomprehensible if you're not familiar with React.

sametmax 8y ago
Well, the facebook team decided to use a specific variation (monodirectional with no side effect) of MVC and rename it flux to confuse everybody. So I react is probably not a good software to measure yourself against when it comes to clarity.
- lmm 8y ago
  It was a random choice of big-name framework; I could say the same of Rails or Spring or anything. Naming things is hard, and the same pattern is constantly rediscovered in different places. If anything I'd say Haskell's difficulties come from the other end: being too willing to respect the "original" name of a concept from an old mathematical paper rather than coming up with a branding that programmers will be more comfortable with.
  - sametmax 8y ago
    I get the point: we love to rename things, and Haskell is using the proper mathematical name. There must be a balance somewhere though.
    - mickronome 8y ago
      The parent seems to agree with you, that Haskell is maybe too eager to keep to 'mathematical' names, but it almost sounds like you interpreted the parent the other way around? Your comment reads almost equally well with two different interpretations. One a restatement of fact, and the other a rather rude response to a misunderstood message.
    - bbeonx 8y ago
      One issue I have with ad hoc naming convention is that while they may make the first month of learning nice and easy they usually don't have the nice synthesizing effect where all of your notations come together beautifully. Math is terse and there is an initial hurdle to get over. However, once that initial hurdle is cleared there are a lot of things that become obvious as a direct consequence of the notational bootstrapping that we did. With that said, every time I start looking at Haskell I end up playing with category theory instead which may be indicative of something.
    - pyrale 8y ago
      There may not be a general balance. That would explain why so many languages scratch different people's itches.

Filligree 8y ago

Eta-conversion is just the statement that having function(x) { f(x) }, in JS, is equivalent to having f. In short, wrapping a function in another function (or removing such a layer) makes no difference. Like most of lambda calculus, this is extremely intuitive once described that way. Therefore, a situation for which it is false is disconcerting. It's also considered one of the "monad laws", which is the small set of rules that everyone assumes is true for every monad, but which the language doesn't (can't) enforce via the type system. ⊥, pronounced bottom, is a "value" that, if you ask for it, your program breaks. It may go into an infinite loop, or it may crash. The GP post is therefore explaining that, because eta conversion in this case fails when the function returns bottom, we should be disconcerted. It's a mild form of disconcertion, however: Things would only go wonky if you try to run code that would, in any case, hang or crash. The reason it isn't completely harmless is that the difference may be observable: A crash in pure code triggers an exception, which can be caught in its impure wrapper code, and a hang can in some cases be converted to an exception by the garbage collector. In theory all bottoms are equal, but in practice they aren't.

sametmax 8y ago
Thank you.

kazagistar 8y ago

You arent "dumb" if you don't known how to play some game or speak some language; you just haven't taken the time to learn it yet.

sametmax 8y ago
Yeah but I'm suppose to be a "game player" with 15 years of experience at this point :)
- bojo 8y ago
  I've been playing the game of Go for 15 years. I barely know how to play Chess beyond moving the pieces. They are both board games played on a grid. I should be a pro at Chess based on my Go experience? Haskell isn't completely different from your standard imperative programming language (functions, variables, etc), but it is definitely a different enough paradigm that you can't just pick it up in a day or two based on your existing experience. My biggest struggle when I picked it up 4 years ago was unlearning my imperative knowledge. Once I was able to throw away my initial preconceptions things got easier. On the other hand, software engineering is still software engineering. Regardless of what tools you use, you usually have to solve them in a similar way. Your 15 years are still useful :)
  - sametmax 8y ago
    That's actually the most encouraging comment about haskell i read in a while.

deleted 8y ago

[deleted]