This is just gold!
All the Haskellers I have met seem to be quite normal, helpful. Maybe this guy rubs them up the wrong way.
- A Haskeller once said Haskell is just as easy as Go to learn. I mean, yeah, many moderately complex languages might be as complex as Haskell, but seriously, Go? It is designed to be as simple as possible. Hell, it even doesn't have generics, which is considered pretty essential in nowadays' statically typed languages. And this claim isn't an outcome of ignorance. He is the author of a very popular Haskell learning material.
- Another said: "Steep learning curve is an interesting expression, because what it actually means is that one is learning quickly." Ok, that's not my interpretation of "steep learning curve" of Haskell.
- "The average Java programmers are worse than the average Haskell programmers" thing. This sentiment even existed in one of the "how to spread Haskell to the industry" presentation. I'm pretty sure if Haskell does be accepted by the industry, it will have the exactly same dumb programmers using it. So, what's the point?
You must be lucky if you haven't met any of them in the Haskell community. Actually, their reputation outside of the community is quite terrible. This must be resolved if Haskell wants to succeed. (And yeah, please stop saying "avoid success at all cost". I know it can be interpreted as "avoid $ success at all cost", just stop it.)
I think this is quite relevant.
https://gist.github.com/quchen/5280339
All communities of significant size will have good and bad apples. The Haskell community is no exception. But in my experience most of the community are fantastically patient and helpful people.
That is technically correct in the original meaning of "learning curve".
Many technically inclined people totally disregard changes of language and cling to their perceived "pure" meaning.
But every language community has its toxic elements.
That's a property of all niche languages. Yes, if they get mainstream, they'll lose it, but until then it makes for an easy way to bias in a good way the set of people you could hire for a position.
If we assume companies do not filter well their hires, or that filtering them is costly (a huge "if"), it becomes a competitive advantage. And, as most competitive advantages, if enough people use it, it goes away.
This is actually what the rest of the world says about the tech industry.
(Yeah, I just finished pushing a commit or two in Haskell to my github. And I hang out with Ed Kmett once a month. Oy.)
This is the same kind of weak response you see from Rubyists whenever someone points out their community's well-documented asshole problem (eg: Steve Klabnik bringing a woman to tears by publicly ridiculing her project and offering only an insincere non-apology when called on it, any blog post ever by DHH or ZS, Felipe Contreras' tantrums on public mailing lists):
"Well, in my experience, everyone in my community is super nice and helpful, so you must be wrong."
Off the top of my head, I can easily recall several Haskellers on HN who've come across to me in the past as pricks, and on multiple occasion at that: dons, loup-vaillant, and coolsunglasses.
The Haskell community, like that of Ruby, is quickly getting the reputation it deserves.
I've experienced some cases where I've been spoken to a bit sharply, and some where people have come across a bit impatient when I haven't "got" something they understand. The thing is that I don't process it as people coming across as a dick, so my subjective experience is that the community is helpful. As to the three examples [1] you picked out of Haskellers coming across as pricks, I honestly, truely, completely don't see anything in any of these comments beyond forthright assertions of opinion. Would you be able to maybe break down what you find objectionable?
[1] As disclosure: I currently work with dons, and I also know willtim.
By the same token, you could describe the community of Haskell as witty and friendly by taking SPJ as an example. In my experience, the Haskell community is fairly free of vitriol and of the drama which is fairly common in open-source communities.
This thread reminds me of Tortuous Convolvulus.
> Yoneda-crazy: I know Haskell, I know some category theory, but I am highly sceptical that teaching the Yoneda Lemma to C++ programmers is actually useful in any way.
This is infuriatingly true. Everything you do in Haskell you can understand in terms of what code gets executed where and how. This is just as true of Haskell as it is of any other high-level language.
Indeed, you can take an arbitrary Haskell program, and rewrite it in C with the same semantics, and all you'll learn is how GHC's runtime is implemented and how it executes your program. For a small concise program, this actually makes for a nice exercise. I don't know why, but people sometimes seem to think the runtime is "magic".
A side comment, this one's more about CT itself, is that the standard texts don't seem to really have many results. Not compared to, say, any undergrad book on algebra or number theory, where cool theorems come at you every few pages to twist up your brain. Category Theory always felt almost mechanical to me. Lots of definitions and rules for assembling diagrams and such, but then what. Just the Yoneda Lemma and that's it? If anyone can point me to the fun CT theorems, I'd love to hear about them.
Oh man. If you like math, CT gives nice mathematical definitions for stuff. I would love to use my algebra skills to do general programming like I can use my linear algebra knowledge in numerical programming.
I'm making bold claim that I hope someone can debunk with awesome counterexamples:
"CT HAS ZERO APPLICABILITY IN PROGRAMMING"
Using CT to Linear algebra analogy: CT in programming is like learning definitions of vector spaces, subspaces, span, and basis and stopping there. No CT equivalent for solving linear systems, linear transformations, least-squares or eigenvalues. Just because you have rooted programming in cool algebraic notation does not mean anything in itself.
Category Theory is more about getting (as one of my professors put it) "a God's-eye view of mathematics". What I have found to be the most deep and useful is the way it provides concrete definitions which unite constructions that mathematicians were already calling the same thing (e.g. products, co-products). It is also absolutely amazing at showing links between different (seemingly unrelated) parts of mathematics. In this way, it forms a sort of lingua-franca for mathematics. This math StackExchange answer[1] gives some really good concrete examples.
If you want a book which gives a lot of more concrete results along with category theory, you should try Algebra: Chapter 0. It is more focused on abstract algebra, but it does it all from a categorical perspective while not assuming you know one iota of category theory (at the start).
[1]: http://math.stackexchange.com/questions/312605/what-is-categ...
On the other hand, CT was invented to talk about homology, so if you want to see a ton of examples of CT being used "in its natural habitat" then look there.
I think anyone who really understands what they're talking about (which is, admittedly, not everyone who talks, sometimes loudly) would happily agree with you and then wonder what we were arguing about :)
Haskell tries to take the line that the "compilation semantics" are second class citizens to the "equational semantics". A lot of the technology Haskell introduces is in some way or another directly aimed at this. It doesn't, however, mean that the compilation (or operational, though that word gets abused and won't take you where you want to go exactly if you google it) semantics isn't totally valid, interesting in it's own right, and a useful thing to study.
Some of the core-er Haskellers like to write about this stuff too. I particularly love Edward Yang's posts on the Haskell Heap
http://blog.ezyang.com/2011/04/the-haskell-heap/
What we really want is a language with many compatible and well-developed choices of semantics! Then we can pick and choose our reasoning tools on the fly and know that we won't be led astray by small (or vast) incompatibilities.
It turns out this is tremendously difficult.
It's also important to note that Haskell only does a so-so job at it. Interestingly, this makes it one of the absolute best examples of any large language pulling it off. SML probably takes the cake depending on what flavos you're interested in, though.
So, Perl6.
> It turns out this is tremendously difficult.
Yep.
Apparently somewhere in the last 20 years people stopped learned about how compilers work.
That knowledge is now kept by the few druids that possess the abilities to read the old runes and release the enchantments that reside in them.
I think getting lost in the implementation details is what gets many Haskell learners, because the majority know an imperative language and use it as the base.
Law number 3.
What I dislike the most is that the Haskell execution order in particular isn't hard to reason about[+]. Yet, because it's things don't simply happen in the order you write them, people tell beginners to not think about execution order at all, and wait until laziness bite them.
[+] Really. If you just assume that the only things that gets evaluated is the first argument of the IO monad (>>) operator (not (>>=)), and it pulls evaluation until it gets all the data it needs, you'll have 99.9% of the model done. Read about GHC green threads and the FFI and you'll get everything that does not use unsafePerformIO right.
[1] http://stackoverflow.com/questions/23727768/which-parts-of-r...
The main advantage for me is in code reuse and refactoring, something that really shines for medium-to-large projects, and is unfortunately hard to showcase in tutorial style.
Getting started wasn’t easy, but as you imply, not really due to the language—mainly because the learning materials didn’t suit me. I couldn’t bring myself to finish Learn You a Haskell or any other tutorial, so I just used the language to build stuff and figured things out.
Been thinking about writing a book about my experiences, but it’s Yet Another Project I’ll have to make the time for…
For me, using yesod has been quite a revelation. All of the errors in db operations get caught during my cabal build. This link https://github.com/yesodweb/yesod/wiki/ghci is something i used to test my db code all within the repl cycle after setting some pg env variables. All in all, its way smoother than many other environments i have worked with.
How about a URL shortener instead of a Twitter clone?
https://github.com/ryantrinkle/memoise
Video here: https://vimeo.com/59109358
Pandoc (http://pandoc.org/) is written in Haskell and its modular design makes it easy to peruse without understanding everything.
Haskell shines the brightest when refactoring a moderately sized project (I have been yearning for this, working in a smallish Python codebase), but nothing prevents using it for small things.
"FP communities: like debating which brand of natural spring water to give millions of thirsty people in the desert"
https://twitter.com/jordwalke/status/566719390272335872
Note that I do genuinely appreciate the discussion, while finding the overall scene humorous.
Case in point: I've probably done more to evangelize functional programming by just demonstrating to colleagues that they too can write their own higher-order functions - just like LINQ! - in C# than an army of Haskellers could accomplish in a lifetime of hurling jargon from category theory. My thought is, if FP is really so great then I should be able to show people by writing some functional code and then having someone else come along later and go, "Hey, that's great!" When I find I can't do that then that's a signal that it's time to double-check the ingredients of my fruit-flavored beverage.
Yeah, that does mean I have to accept that Racket will forever be a hobby language for me. My boring sellout Herman Miller-cradled enterprise developer butt is comfortable with that.
I don't know about that. Sometimes people must make the effort to move beyond their comfort zones in order to find tools that are (potentially) more useful. You cannot expect every improvement to be self-evident with minimal effort. There are significant rewards in "making the jump", so to speak.
...who all claim that they're not thirsty and prefer beer :-)
{-# LANGUAGE PatternSynonyms, ViewPatterns #-}
pattern Even <- ((`mod` 2) -> 0)
pattern Odd <- ((`mod` 2) -> 1)
testNumber x = show x ++
case x of
Even -> " is even"
Odd -> " is odd"
data Color = Color { r :: Int, g :: Int, b :: Int }
pattern RGB r g b = Color r g b
-- NB: this is bidirectional automatically
printRGB :: Color -> IO ()
printRGB (RGB r g b) = print $ "Red: " ++ show r ++ " Green: " ++ show g ++ " Blue: " ++ show b
-- pretend we have functions to and from RGB and HSV representation
toHSV :: Color -> (Int, Int, Int)
toHSV = undefined -- implement this yourself!
fromHSV :: Int -> Int -> Int -> Color
fromHSV = undefined
pattern HSV h' s' v' <- (toHSV -> (h', s', v'))
-- here we explicitly provide an inversion
where HSV = fromHSV
printHSV :: Color -> IO ()
printHSV (HSV h s v) = print $ "Hue: " ++ show h ++ " Saturation: " ++ show s ++ " Value: " ++ show v
-- demonstrating being able to use pattern
-- to construct a value
addHue :: Int -> Color -> Color
addHue n (HSV h s v) = HSV (h + n) s vTo quote Bob Harper: As a consequence, using type classes is, in Greg Morrisett’s term, like steering the Queen Mary: you have to get this hulking mass pointed in the right direction so that the inference mechanism resolves things the way you want it to. [https://existentialtype.wordpress.com/2011/04/16/modules-mat...] (I think this applies most of all if one is using type classes to emulate a module system. For other purposes, type classes are quite nice.)
Maybe Backpack will solve these issues. [http://plv.mpi-sws.org/backpack/]
Here's another recent one going in the opposite direction, like this one, but asking Clojure fans about Haskell: https://www.reddit.com/r/Clojure/comments/3h4qdk/what_are_cl...
A lot of the Clojure programmers seemed to focus on things, like records, that often bug Haskellers, too.