4 ms·
If it is language-specific jargon, then people's problem is that Haskell has way too much jargon for them to wade through. No matter how you phrase it, to many
by chc 14y ago
If it is language-specific jargon, then people's problem is that Haskell has way too much jargon for them to wade through. No matter how you phrase it, to many people, any real Haskell is an impenetrable morass of esoteric abstractions.
Basically, Haskell itself is pretty easy. The language is small, simple and elegant. But the libraries are massively, massively complex and do things in ways that are very often not at all intuitive if you're not familiar with the math behind them. That's what people mean when they say it's too heavily based in math.
This is not to say that you can't use Haskell in the real world, but it has some attributes that make it daunting for many people. I don't think this a bad thing, either — not everything should be for everyone. Variety is the spice of life.
- pilgrim689 14y ago> But the libraries are massively, massively complex and do things in ways that are very often not at all intuitive if you're not familiar with the math behind them. I'm just a beginner Haskeller, but this seems like a pretty bold (and false) claim. I've used Parsec for writing a Scheme (while reading the book), Shelly and Shake for build and test automation, and some statistics libraries for, well, statistics. They were all intuitive to use, and there was no "impenetrable morass of esoteric abstractions". I'm not sure what you're on about. Maybe provide examples?
- chc 14y agoI will write this answer in the flavor of your average Haskell library, as read by somebody who has learned the core language very well but not that library: you <*$%^> everyone %%<#>%% experience Are you really going to tell me you have never looked at code written with a package you haven't learned and initially found it to be unintelligible? If not, then I would guess that you are simply well-suited to Haskell. Again, I'm not saying Haskell is bad, but that it does have attributes that make it daunting to many people. The top-rated comment on here even talks about how easy Haskell is now that he's "over the hump." Even compared to a relatively esoteric language like Clojure, Haskell's hump is pretty big. I believe the canonical example of a weird math-based library that makes beginners cry is Control.Arrow. Reading arrow-based code without having fully grasped both the idea of arrows and the API itself (do you think <&&&> could use a few more ampersands?) is an exercise in frustration. Even the humble monoid — simple as it may be — is hard for many people to grasp, because they're such a frustratingly generic idea with horribly unhelpful terminology attached to them. Want more? Here's one of the top Haskell projects on Github — a library that does lenses, folds, traversals, getters and setters: https://github.com/ekmett/lens https://github.com/ekmett/lens With that library, you can write things like _1 .~ "hello" $ ((),"world")
- tomp 14y agoYou mean that the example would be more readable if it used proper function names instead of operators? You would still need to "learn the library", i.e. look-up what the functions do.
- rayiner 14y agoI'm pretty sure all the railing hard on the symbols above the number keys must be symptomatic of some sort of verbal learning disability in Haskell programmers...
- chc 14y agoI don't think that's fair. It allows for some really concise code that actually is quite readable once you're conversant. For example, I do not think Parsec would be better off if "<|>" were renamed to "parsecOR" or something like that. It's just, like I said, obscure and daunting.
- sanderjd 14y agoI do think Parsec would be better off if "<|>" were something like "parsecOR". Good function names are good.
- chc 14y agoIf you're really interested in this, I'd encourage you to take some actual Parsec code and make this change, then compare the two for readability. My guess is that while it's conceptually nice, you'll find in practice it hampers readability more than it helps.
- sanderjd 14y agoThanks for the constructive suggestion - I don't have much invested in this particular little debate so I'm not sure I'll take the time to do that, but it's definitely a good idea. I will say that in my opinion, the alternative in the reply above this (which I can't reply to) looks fairly nice, is clearer, and not even a little bit harder to follow. But I'll allow that as a very casual Haskell programmer, my opinions about Haskell are probably not particularly valid.
- ericssmith 14y agoI think you are correct here. In my view, advanced languages facilitate the development of complex abstractions in the libraries. I find this to be the case in both Haskell and Scala. But I also don't think we will ever return to the innocent days of yore. Programming is growing up after six decades of trying to figure out what 'mainstream' ought to be. I suspect that the whole business will bifurcate into easy-to-use languages and increasingly complex libraries atop more sophisticated languages to meet the challenges of scale and speed.