3 ms·
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
by 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 agoIs 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 agoPersonally 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 agoIf 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...