undefined | Better HN

0 pointstikhonj13y ago0 comments

All of the terminology used widely in the community can be--and almost always is--defined in terms of Haskell rather than math. You can pretend the math does not exist and treat it as language-specific jargon. You might miss out on the truly cutting-edge libraries until somebody writes a nice tutorial for them, but that would still be true even if the abstractions were not mathematical in nature.

Many of the people in the community do not know much of the math beyond the terminology they learned in Haskell. That's certainly what I gathered talking to people at a local Haskell meetup and it matches my impression of many of the people online (e.g. in the mailing list or StackOverflow.

0 comments

4 comments · 1 top-level

chc13y ago· 3 in thread

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.

pilgrim68913y 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?

chc13y ago

I 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

With that library, you can write things like

  _1 .~ "hello" $ ((),"world")

2 more replies

ericssmith13y ago

I 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.

j / k navigate · click thread line to collapse