3 ms·

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

by 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.
  - catnaroek 10y ago
    > Is that then a limitation of the language? How exactly is it a limitation that the language has greater expressive power than most? Haskell does have serious limitations: laziness is a horrible default, modularity is a joke, reasoning about performance is very difficult, and the correctness of most basic abstractions is conditional on the user never ever using a partial function, not even accidentally - or else hilarity ensues. But functors, applicatives and monads are godsend.
  - nilkn 10y ago
    Personally I don't think it's a limitation of the language so much as it is an artifact of Haskell's relative uniqueness. Most programmers have never encountered a type system stronger than that of, say, Java, so they have little to no precedent for this sort of language. Consequently, the very idea of a generic fmap (i.e., <$>) is foreign and new.
  - eof 10y ago
    > it's hard to write Haskell that's expressive for novices and experts at the same time. That is definitely a fair analysis. Though I suppose that is a limitation it is not necessarily a severe one, or one that should matter to most people putting code in production. Haskell in general is extremely unfriendly to novices; but what you lose in accessibility you gain ten fold in maintainability. Haskell in general requires far, far more upfront problem solving than something like PHP or Javascript. It's easy to take for granted the implicit coercion, smart defaults, overlapping scopes when working in PHP to iteratively work on a problem. In haskell you are more likely to need a pretty good idea of what the final solution will look like before you even get the code compiling the first time, unlike php/js where you can write one or two lines, check the output, rinse and repeat.
  - sclv 10y ago
    If you think reading X loc/min is the norm, and then hit a language where you read much slower, you might think "this is hard to read". But if you're reading the same density of _logic_ at the same speed, then that's not a drawback. If the haskell is say 3x as dense in logic, then reading at 1/3 the speed isn't a drawback at all...
fusiongyro 10y ago
There are much bigger fish to fry than "clever" one-liners when onboarding a new Haskell programmer.
bad_user 10y ago
Cognitive load has nothing to do with your ability to "easily onboard". If you can't understand German, would you say that usage of German increases one's cognitive load? No, that would be preposterous. If you need to speak in German, then you hire Germans or people willing to learn the language. Onboarding might be a challenge, but it wouldn't have anything to do with the performance of those that do know German. I myself speak English as a second language, because I had to learn it in order to do my job. Seeing you're from NYC, there's a high probability that English was imposed on you from birth. Good for you given our profession, but a lingua franca is context sensitive, temporary and English isn't even the second most spoken language. And do you know what language is more universal than all natural languages and that doesn't change much? Math. And math uses symbols, not English words. And Haskell is much closer to math than all mainstream languages.

by b34r 10y ago

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.
- catnaroek 10y ago
  > Is that then a limitation of the language? How exactly is it a limitation that the language has greater expressive power than most? Haskell does have serious limitations: laziness is a horrible default, modularity is a joke, reasoning about performance is very difficult, and the correctness of most basic abstractions is conditional on the user never ever using a partial function, not even accidentally - or else hilarity ensues. But functors, applicatives and monads are godsend.
- nilkn 10y ago
  Personally I don't think it's a limitation of the language so much as it is an artifact of Haskell's relative uniqueness. Most programmers have never encountered a type system stronger than that of, say, Java, so they have little to no precedent for this sort of language. Consequently, the very idea of a generic fmap (i.e., <$>) is foreign and new.
- eof 10y ago
  > it's hard to write Haskell that's expressive for novices and experts at the same time. That is definitely a fair analysis. Though I suppose that is a limitation it is not necessarily a severe one, or one that should matter to most people putting code in production. Haskell in general is extremely unfriendly to novices; but what you lose in accessibility you gain ten fold in maintainability. Haskell in general requires far, far more upfront problem solving than something like PHP or Javascript. It's easy to take for granted the implicit coercion, smart defaults, overlapping scopes when working in PHP to iteratively work on a problem. In haskell you are more likely to need a pretty good idea of what the final solution will look like before you even get the code compiling the first time, unlike php/js where you can write one or two lines, check the output, rinse and repeat.
- sclv 10y ago
  If you think reading X loc/min is the norm, and then hit a language where you read much slower, you might think "this is hard to read". But if you're reading the same density of _logic_ at the same speed, then that's not a drawback. If the haskell is say 3x as dense in logic, then reading at 1/3 the speed isn't a drawback at all...

fusiongyro 10y ago

There are much bigger fish to fry than "clever" one-liners when onboarding a new Haskell programmer.

bad_user 10y ago

Cognitive load has nothing to do with your ability to "easily onboard". If you can't understand German, would you say that usage of German increases one's cognitive load? No, that would be preposterous. If you need to speak in German, then you hire Germans or people willing to learn the language. Onboarding might be a challenge, but it wouldn't have anything to do with the performance of those that do know German. I myself speak English as a second language, because I had to learn it in order to do my job. Seeing you're from NYC, there's a high probability that English was imposed on you from birth. Good for you given our profession, but a lingua franca is context sensitive, temporary and English isn't even the second most spoken language. And do you know what language is more universal than all natural languages and that doesn't change much? Math. And math uses symbols, not English words. And Haskell is much closer to math than all mainstream languages.