5 ms·

Readability : although I'm not proficient in Haskell it seems to lend itself towards perl-like clever one liners.

by ioseph 10y ago

rtpg 10y ago
I share this feeling , esp. when each third party lib wants to introduce some variant of <$../<>). But I've found some of the more common symbols end up being how you think about your code when you become more versed. The big one is <$> for fmap. If you have some functor/monad/thingy, you'll often be like "I have this pure function that I want to apply to the inner value of my functor", and <$> is the perfect analog to $. The high abstraction level of Haskell makes reaching for these really tempting and easy. And the alternatives are verbose and harder to read in many situations. compare "capitalise <$> readStrLn" to do val <- readStrLn return capitalise val (though "fmap capitalize readStrLn" isn't too bad)
- taylorfausak 10y ago
  This post explores the differences in those two styles: http://www.yesodweb.com/blog/2015/10/beginner-friendly-code-and-apis http://www.yesodweb.com/blog/2015/10/beginner-friendly-code-... > It seems like my progression as a Haskeller results in forcing myself to write in a harder-to-parse style to make my code shorter, to satisfy some base need for "better" code, even though by most measurements I just made, the longer/explicit/pattern matching code is in fact better.
- chriswarbo 10y ago
  To be fair, "<$>" is a synonym for "fmap", so "fmap capitalise readStrLn" is the go-to alternative. The "do" example is not only more verbose, but less general (it only applies to monads rather than all functors), and relies on special syntax (despite its awkwardness, "<$>" is still just a function call). You could also do "capitalise `fmap` readStrLn", which is kind of intermediate between the two :)
  - Iceland_jack 10y ago
    `ApplicativeDo`[1] do-notation works with Functors [1] https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#ghc-flag--XApplicativeDo https://downloads.haskell.org/~ghc/master/users-guide/glasgo...
Ericson2314 10y ago
The article is about things that impact professionals (thought they also beginners). For better or worse, experienced Haskell users can read the one liners just fine.
- b34r 10y ago
  Sure, but you've also nuked a developer's ability to easily onboard and understand the codebase with "clever" one liners. Good, maintainable code tends to trend toward lower cognitive load more often than compact solutions.
  - nilkn 10y ago
    I'm generally of this opinion, but with Haskell I think more often than not the "clever" one liners are actually not clever -- they're just completely standard usages of fundamental language constructs, and they only appear clever to people who haven't used the language. It's very common to see newcomers or people who've never used Haskell at all mention <$> and friends in this regard. Then someone will say that if you just used do notation explicitly it'd be a lot clearer. And then someone will point out that do notation might look familiar, but semantically it can be spectacularly different from what one might expect from truly imperative languages (e.g., when using the nondeterminism of the list monad). So by encouraging overuse of do notation, you're making the code feel familiar, but you're not actually making it more understandable; if anything, you're making it harder to understand, because you're making it look like something that it's not. Additionally, while do notation is very generic and broadly powerful, <$> does exactly one thing: it applies a function to a wrapped value, producing a new wrapped value. Once you've used Haskell a fair bit, you very strongly internalize this and tend to immediately understand code involving <$>. If all this code were expanded out to use do notation, you'd have to spend a lot of extra timing reading through the do notation to realize that, oh, this is just a re-implementation of fmap, over and over again.
    - blowski 10y ago
      Is that then a limitation of the language? I've only briefly toyed with Haskell (and most of the time I use PHP, so my opinion is almost moot). But from what you've written, it sounds like it's hard to write Haskell that's expressive for novices and experts at the same time.
thesz 10y ago
The less decisions you make through you programming day, the more you achieve and the less stressful the job is. Naming variables is a decision (I am looking at you, function arguments in most mainstream languages). Naming variables once and for all is a big and heavy decision (and now it is time for class members to be looked at). For one operator in Haskell I often have to invent names for three-to-five variables in C#.
- tikhonj 10y ago
  That's a great way of putting it. Sure, sometimes an intermediate name helps—that's when I reach for `where` or `let`. But much of the time the extra name would just be extra noise that obscures what the code is doing and makes it harder to read at a glance.
eof 10y ago
Interesting, readability is something I would put on a list of upsides of Haskell. I agree that the abundant use of operators can make things difficult in some cases, but this is largely naivety on the part of the reader rather than complexity like Perl. Perl's obfuscated one-liners are just vanilla things that every perl programmer will understand, while Haskell's weird lines are generally package specific operators that one needs to become familiar with. Once familiar (unlike in Perl) a seasoned Haskeller will be able to grok a lot of what is going on very quickly. As a further point, the strictness of it all makes understanding the entire system a much easier experience than many other languages.
hyperpape 10y ago
I suspect that there's a grab bag of things that happen in those one liners, and whether they are a good idea or not depends on the details. For instance, <$> seems pretty helpful, but I shudder when I see flip. I'd go out on a limb and speculate that even for experienced readers, flip is going to be a bit difficult to parse. But I'll have to come back to that when I have more experience.

Readability : although I'm not proficient in Haskell it seems to lend itself towards perl-like clever one liners.

by ioseph 10y ago

Readability : although I'm not proficient in Haskell it seems to lend itself towards perl-like clever one liners.

rtpg 10y ago

I share this feeling , esp. when each third party lib wants to introduce some variant of <$../<>). But I've found some of the more common symbols end up being how you think about your code when you become more versed. The big one is <$> for fmap. If you have some functor/monad/thingy, you'll often be like "I have this pure function that I want to apply to the inner value of my functor", and <$> is the perfect analog to $. The high abstraction level of Haskell makes reaching for these really tempting and easy. And the alternatives are verbose and harder to read in many situations. compare "capitalise <$> readStrLn" to do val <- readStrLn return capitalise val (though "fmap capitalize readStrLn" isn't too bad)

taylorfausak 10y ago
This post explores the differences in those two styles: http://www.yesodweb.com/blog/2015/10/beginner-friendly-code-and-apis http://www.yesodweb.com/blog/2015/10/beginner-friendly-code-... > It seems like my progression as a Haskeller results in forcing myself to write in a harder-to-parse style to make my code shorter, to satisfy some base need for "better" code, even though by most measurements I just made, the longer/explicit/pattern matching code is in fact better.
chriswarbo 10y ago
To be fair, "<$>" is a synonym for "fmap", so "fmap capitalise readStrLn" is the go-to alternative. The "do" example is not only more verbose, but less general (it only applies to monads rather than all functors), and relies on special syntax (despite its awkwardness, "<$>" is still just a function call). You could also do "capitalise `fmap` readStrLn", which is kind of intermediate between the two :)
- Iceland_jack 10y ago
  `ApplicativeDo`[1] do-notation works with Functors [1] https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#ghc-flag--XApplicativeDo https://downloads.haskell.org/~ghc/master/users-guide/glasgo...

Ericson2314 10y ago

The article is about things that impact professionals (thought they also beginners). For better or worse, experienced Haskell users can read the one liners just fine.

b34r 10y ago
Sure, but you've also nuked a developer's ability to easily onboard and understand the codebase with "clever" one liners. Good, maintainable code tends to trend toward lower cognitive load more often than compact solutions.
- nilkn 10y ago
  I'm generally of this opinion, but with Haskell I think more often than not the "clever" one liners are actually not clever -- they're just completely standard usages of fundamental language constructs, and they only appear clever to people who haven't used the language. It's very common to see newcomers or people who've never used Haskell at all mention <$> and friends in this regard. Then someone will say that if you just used do notation explicitly it'd be a lot clearer. And then someone will point out that do notation might look familiar, but semantically it can be spectacularly different from what one might expect from truly imperative languages (e.g., when using the nondeterminism of the list monad). So by encouraging overuse of do notation, you're making the code feel familiar, but you're not actually making it more understandable; if anything, you're making it harder to understand, because you're making it look like something that it's not. Additionally, while do notation is very generic and broadly powerful, <$> does exactly one thing: it applies a function to a wrapped value, producing a new wrapped value. Once you've used Haskell a fair bit, you very strongly internalize this and tend to immediately understand code involving <$>. If all this code were expanded out to use do notation, you'd have to spend a lot of extra timing reading through the do notation to realize that, oh, this is just a re-implementation of fmap, over and over again.
  - blowski 10y ago
    Is that then a limitation of the language? I've only briefly toyed with Haskell (and most of the time I use PHP, so my opinion is almost moot). But from what you've written, it sounds like it's hard to write Haskell that's expressive for novices and experts at the same time.

thesz 10y ago

The less decisions you make through you programming day, the more you achieve and the less stressful the job is. Naming variables is a decision (I am looking at you, function arguments in most mainstream languages). Naming variables once and for all is a big and heavy decision (and now it is time for class members to be looked at). For one operator in Haskell I often have to invent names for three-to-five variables in C#.

tikhonj 10y ago
That's a great way of putting it. Sure, sometimes an intermediate name helps—that's when I reach for `where` or `let`. But much of the time the extra name would just be extra noise that obscures what the code is doing and makes it harder to read at a glance.

eof 10y ago

Interesting, readability is something I would put on a list of upsides of Haskell. I agree that the abundant use of operators can make things difficult in some cases, but this is largely naivety on the part of the reader rather than complexity like Perl. Perl's obfuscated one-liners are just vanilla things that every perl programmer will understand, while Haskell's weird lines are generally package specific operators that one needs to become familiar with. Once familiar (unlike in Perl) a seasoned Haskeller will be able to grok a lot of what is going on very quickly. As a further point, the strictness of it all makes understanding the entire system a much easier experience than many other languages.

hyperpape 10y ago

I suspect that there's a grab bag of things that happen in those one liners, and whether they are a good idea or not depends on the details. For instance, <$> seems pretty helpful, but I shudder when I see flip. I'd go out on a limb and speculate that even for experienced readers, flip is going to be a bit difficult to parse. But I'll have to come back to that when I have more experience.