4 ms·

>>So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. I

by tmptmp 10y ago

>>So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. If the lenses for records thing in Haskell is amongst the simplest things for you, I beg to differ. I spent considerable time trying to get this working but could not succeed beyond toyish examples. Combine lenses/records with exceptions, applicatives, monads and monad-transformers as they become necessary once you try to expand your toy-example code and the Haskell thing becomes anything but simplest. Yet, other languages support records flawlessly and almost out of the box. The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it and due to almost arbitrary overloading of these symbols to mean different things in different contexts (libraries) just adds more cognitive overhead without any benefit. The almost cult-like insistence on the excessive usage of meaningless-to-humans symbols reminds me of the great practical programming language known as brainfuck [1]. Sorry but no sarcasm intended. Some Haskellers harp on succinctness, when talked about this religious fetish for symbolism in Haskell. So I ask, such succinctness at what cost? The excessive and obsessive usage of symbols may give mental kicks to the hardcore Haskellers out there, but sorry, I don't see any incentive to waste my time trying to wade through the gobble-de-gook of brainfuck type code. So sadly, Haskell and me are not a match. Maybe some most common things in other languages when tried in Haskell seem to be (are) rocket-science (e.g. lenses for records) and/or maybe I am a daft blockhead, but that's so. [1] https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck

thinkpad20 10y ago
> The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. Once you're familiar with them (which you almost certainly will quickly become, for the common ones like `>>=`, and `< * >`) they make the code easier to read, not harder, in general. Few would complain about having to write "<" to compare two numbers in most languages, rather than, say, "lessThan", because it's all over the place, and having a symbol for it makes it easier for a developer to read. The same is true for many common combinators in Haskell. There is no "cult-like insistence" on them; it's simply the case that many Haskell developers find them more pleasant to write than named functions. Honestly, the comparison to brainfuck is completely unfounded, and the references to cults and religious fetishes are IMO unnecessarily derisive. Furthermore, I'd add that what makes the symbols seem hard is not the fact that they're symbols, but that the ideas that they're representing are challenging when coming from the world of imperative programming. Using a named function like "bind" rather than ">>=" or "apply" rather than "< * >" is not going to help the fact that these functions are complicated and unintuitive to newcomers. I think a lot of the complaints about Haskell symbols, much like complaints about Haskell syntax, are more driven by how different Haskell semantics are to mainstream languages. Once a developer becomes comfortable with the "zen" of Haskell, these criticisms tend to melt away. That isn't to say that everything becomes easy: there are many concepts that one is only likely to encounter in Haskell, and they can often be challenging, or make someone else's code hard to grok. But the difficulty does not stem from the fact that they're written as symbols. IMO. As for your comments on lenses and records, I've been writing Haskell for a good number of years and still haven't really spent the time to grok lenses. I think they're probably great, but certainly mastery of them is not required to be productive with the language.
- mercurial 10y ago
  > This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. Once you're familiar with them (which you almost certainly will quickly become, for the common ones like `>>=`, and `< * >`) they make the code easier to read, not harder, in general. Few would complain about having to write "<" to compare two numbers in most languages, rather than, say, "lessThan", because it's all over the place, and having a symbol for it makes it easier for a developer to read. The same is true for many common combinators in Haskell. There is no "cult-like insistence" on them; it's simply the case that many Haskell developers find them more pleasant to write than named functions. Honestly, the comparison to brainfuck is completely unfounded, and the references to cults and religious fetishes are IMO unnecessarily derisive. My issue, back when I was exploring Haskell, was not so much with the symbols in the standard library (eg, for applicative functors), but with the amount of library authors who thought they needed their own little shitty ASCII DSL.
- tmptmp 10y ago
  >>As for your comments on lenses and records, I've been writing Haskell for a good number of years and still haven't really spent the time to grok lenses. I think they're probably great, but certainly mastery of them is not required to be productive with the language. Give me any non-trivial industry scale web/database application which doesn't rely on the notion of records. The support for records in Haskell is if not pathetic is very poor.[1] (This is a rather older reddit post but I haven't kept track of it.) I can be productive with Haskell if I restrict myself to math-type pure computations (e.g. DSL compiler) but if you want anything to do with web/database type non-trivial IO using Haskell, good luck. So, I restrict myself to use Haskell only for doing pure computations that require extremely simple and trivial IO (mostly just readFile/writeFile). >>This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. How about Haskell's notion of fixity of the symbols/operators/names? It seems this almost arbitrary fixity [2] notion just adds cognitive overhead with little to zero semantic benefits. Correct me if I am wrong and please enlighten me on exactly what semantically significant benefits are offered by the notion of fixity and at what cost. Most other mainstream languages don't offer such a useless flexibility like fixity which causes so much cognitive distraction when used by different people with different semantics, and that too just for kicks. [1] https://www.reddit.com/r/haskell/comments/k4lc4/yesod_the_limitations_of_haskell/ https://www.reddit.com/r/haskell/comments/k4lc4/yesod_the_li... [2] https://www.haskell.org/tutorial/functions.html https://www.haskell.org/tutorial/functions.html

by tmptmp 10y ago

thinkpad20 10y ago

> The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. Once you're familiar with them (which you almost certainly will quickly become, for the common ones like `>>=`, and `< * >`) they make the code easier to read, not harder, in general. Few would complain about having to write "<" to compare two numbers in most languages, rather than, say, "lessThan", because it's all over the place, and having a symbol for it makes it easier for a developer to read. The same is true for many common combinators in Haskell. There is no "cult-like insistence" on them; it's simply the case that many Haskell developers find them more pleasant to write than named functions. Honestly, the comparison to brainfuck is completely unfounded, and the references to cults and religious fetishes are IMO unnecessarily derisive. Furthermore, I'd add that what makes the symbols seem hard is not the fact that they're symbols, but that the ideas that they're representing are challenging when coming from the world of imperative programming. Using a named function like "bind" rather than ">>=" or "apply" rather than "< * >" is not going to help the fact that these functions are complicated and unintuitive to newcomers. I think a lot of the complaints about Haskell symbols, much like complaints about Haskell syntax, are more driven by how different Haskell semantics are to mainstream languages. Once a developer becomes comfortable with the "zen" of Haskell, these criticisms tend to melt away. That isn't to say that everything becomes easy: there are many concepts that one is only likely to encounter in Haskell, and they can often be challenging, or make someone else's code hard to grok. But the difficulty does not stem from the fact that they're written as symbols. IMO. As for your comments on lenses and records, I've been writing Haskell for a good number of years and still haven't really spent the time to grok lenses. I think they're probably great, but certainly mastery of them is not required to be productive with the language.

mercurial 10y ago
> This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. Once you're familiar with them (which you almost certainly will quickly become, for the common ones like `>>=`, and `< * >`) they make the code easier to read, not harder, in general. Few would complain about having to write "<" to compare two numbers in most languages, rather than, say, "lessThan", because it's all over the place, and having a symbol for it makes it easier for a developer to read. The same is true for many common combinators in Haskell. There is no "cult-like insistence" on them; it's simply the case that many Haskell developers find them more pleasant to write than named functions. Honestly, the comparison to brainfuck is completely unfounded, and the references to cults and religious fetishes are IMO unnecessarily derisive. My issue, back when I was exploring Haskell, was not so much with the symbols in the standard library (eg, for applicative functors), but with the amount of library authors who thought they needed their own little shitty ASCII DSL.
tmptmp 10y ago
>>As for your comments on lenses and records, I've been writing Haskell for a good number of years and still haven't really spent the time to grok lenses. I think they're probably great, but certainly mastery of them is not required to be productive with the language. Give me any non-trivial industry scale web/database application which doesn't rely on the notion of records. The support for records in Haskell is if not pathetic is very poor.[1] (This is a rather older reddit post but I haven't kept track of it.) I can be productive with Haskell if I restrict myself to math-type pure computations (e.g. DSL compiler) but if you want anything to do with web/database type non-trivial IO using Haskell, good luck. So, I restrict myself to use Haskell only for doing pure computations that require extremely simple and trivial IO (mostly just readFile/writeFile). >>This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. How about Haskell's notion of fixity of the symbols/operators/names? It seems this almost arbitrary fixity [2] notion just adds cognitive overhead with little to zero semantic benefits. Correct me if I am wrong and please enlighten me on exactly what semantically significant benefits are offered by the notion of fixity and at what cost. Most other mainstream languages don't offer such a useless flexibility like fixity which causes so much cognitive distraction when used by different people with different semantics, and that too just for kicks. [1] https://www.reddit.com/r/haskell/comments/k4lc4/yesod_the_limitations_of_haskell/ https://www.reddit.com/r/haskell/comments/k4lc4/yesod_the_li... [2] https://www.haskell.org/tutorial/functions.html https://www.haskell.org/tutorial/functions.html