This is not a bash on Haskell as I like Haskell, but is every Haskell article or discussion academic? It's all fascinating and interesting (especially the OP), but some of us would like to learn about Haskell's applicability in the real world, not just in computer science academia. I would like to read about Haskell workflows, productivity, and the positives/negatives of using it in your organization. Languages like Go and Clojure bring up these kinds of conversations all the time, so why is it so silent (or at least very low volume) on Haskell's front?
These show up from time to time but I don't think they get the same popularity boost that the cute academic ones do. I also don't think there are as many people trying to sell Haskell internally or externally. Most of what you see with Haskell-in-practice posts is that (a) powerful static typing improves maintainability in various ways (b) training people isn't as hard as people think (c) monad transformers are really important (d) stack dumps don't really exist and that's tough sometimes (e) space leaks happen but you can learn to avoid them without too much effort (f) both robust and scripty/throwaway code is easy to write once you learn how (g) concurrency rocks (h) the awkward squad is still awkward (i) many libraries are abnormally high quality (j) there's some missing library coverage, though.
These posts exist and come up from time to time on /r/haskell as well as after the Commercial Users of Functional Programming conference each year. If you go fishing in the /r/haskell archives you'll find quite a few.
There aren't a lot of consumer facing companies using Haskell. Scrive is one, but I can't find blogs.
Galois makes "highly reliable" software stuff for hardware manufactures and crypto clients.
Edward Kmett is writing/using a Haskell variant for use at the bank where he works.
http://elm-lang.org/
Elm is a FRP/DHTML webapp-building language Haskell variant whose compiler is a Haskell program. Check out Prezi and Evan's blogs
Prezi.com recent hired its author Evan Czaplicki
Yesod (Michael Snoyman) is a full-festured webapp stack. Michael blogs its features.
Ultimately, you don't see large teams using Haskell, and there isn't full integration with all the popular consumer web infrastructure. So instead you have a bunch of small niche products, and the language used to teach mathematical concepts in blogs like Dan Piponi's
But even there the goal is not about adopting Haskell in the large, but using rather using Haskell to create a DSL for end users/employees internally in FB to easily create search/spam filter behaviors.
I think the problem is that Haskell is very much an academic project. It is the go to language for research in functional programming, and its strict insistence on its principles has resulted in many advances in the field.
In contrast, Go is a language designed by Google to meet their needs in programming code. This means that it takes some of the best concepts, pioneered by earlier languages, and combined them into a production oriented language.
Personally, the reason I use Haskell is because some of the awesome stuff they have developed has not yet reached production oriented languages yet.
I think this "problem" can be viewed from a different angle: Mathematicians have managed to find a language which they feel confortable expressing their ideas in (whether for fun in this case or for more serious applications). I don't see this as a bad thing, and I say this as someone who definitely prefers to write practical close to metal type programs in Haskell, and doesn't care much for the all the mathematical theory some other adore.
On the other hand, it turns out that these mathematicians are giving back some great things to the community. People like Edward Kmett have done a lot of work in using category theory in Haskell, and it's given us lovely things like lenses. They can tell us why things things we think should work but dont (some things you can write a Monad instance for, for example, don't obey the monad laws, and more often than not that leads to problems).
The only problem I see if that there are often two different languages being spoken, and it takes a while for us less maths inclined to catch onto why this work is beneficial to us in every day code.
Perhaps when I've got something working, I can write a blog post for you showing my Haskell implementation of a decompressor for LZ4, which is most definitely low level and applicable to the real world (there's lots of pointer arithmetic going on).
If Haskell didn't have anything interesting to offer besides QuickCheck (and everything special about Haskell that QuickCheck depends one, but it has been ported to other languages with varying level of completeness) it would still be a massive contribution to software engineering.
I had no idea that draught is pronounced draft. I always thought that whatever I heard was always "draft", and that draught was some word that I only came across in written english.
I have a shockingly large "read-only" English vocabulary, at least relative to my age (42) and native language (American English). I still get caught out from time to time -- "quay" was a particularly humiliating bête noire.
My favorite was at a party where the (verbal) quiz question was what a "yamikah" is. I had absolutely no idea. Then they told me what it was, and I said - as if the quiz question had gotten it wrong - "Ohhhhh! You mean a YAR-MULK."
Something similar happened to me: a friend of mine kept telling me he worked for a security company called Semantic, and much later I realized he meant Symantec (pronounced like "semantic").
Me neither. I would have thought draught and drought were homophones. Interesting, my EN-US spellchecker here in Firefox is also insisting that draught is misspelled, and is most likely "fraught" (with drought next). I guess I've never had to read that word aloud in front of anyone who would laugh at me....
Some of the homophone pairs the author used seem pretty dubious to me: ant/aunt, choral/coral, air/err, awed/odd, veldt/felt. This is partly British versus American English, but not wholly.
My personal homophony group is not trivial (I think); in particular, I believe that for all pairs of words I regard as having the same pronunciation, the number of "v"s is the same. The counterexample alleged on the linked page is "veldt = felt", but I (like the Dutch, I believe) pronounce "veldt" with a "v" rather than an "f" sound.
I can reduce everything else to the identity using only (what I think are) uncontroversial homophone pairs, so I claim that every native English speaker of large enough vocabulary has a homophony group that's either trivial or isomorphic to Z (and generated by "v").
(I did need some uncommon words, though I didn't try very hard to avoid them: od, gneiss, phlox, qat, flyte, lam. And some somewhat-uncommon ones: banns, rapt, wright.)
> Most people pronounce the verb "affect" and the noun "effect" the same.
Most people I've encountered pronounce the verb "affect" and noun "effect" differently, though the difference can be slight. (schwa for affect vs. short e for effect)
I'm going to put on my math hat for a second, because this blog post was a bit confusing for me at first. I had to read through the post a few times to understand what the "homophony group" was.
For this comment, I don't want to dive into this post from the perspective of someone who's never studied abstract algebra before, so what I'm about to write won't make much sense to anyone who hasn't. If you know a little bit of group theory, though, you should be able to follow along.
Defining a group this way is called a "group presentation". The symbols to the left of the | are called "generators" and the symbols to the right are called "relations." For example, one presentation of the integers modulo 4 with mod-4 addition is
Anyhow, the blog post confused me at first because the "homophony group" is a kind of mathematical double entendre. In algebra one often omits the group operation explicitly, writing "xy" instead of "x.y," where "." is the group operation. This implicit understanding is what makes the "joke" work.
So, on the one hand, we write down the relation "ad=add" in our presentation because ad and add are homophones in English. On the other hand, in group-land, we mean a.d = a.d.d, where (again) "." is the group operation. In group-land, however, there's no sense that "a" is anything special. The 26 symbols "a" to "z" are arbitrary and we could easily write, say,
<σ,b,c,...,z | knight=night, σd=σdd, ...>
or use any other 26 distinct symbols for "a" to "z." The generators tell us what symbols we have at our disposal and the relations tell us how we can reduce combinations of those symbols to the identity element.
Math jokes. Oh buddy.
For the CS folks among us, there's a computational problem called the "group isomorphism problem" which asks, "Given two group presentations, are they isomorphic?" This problem is provably undecidable: http://en.wikipedia.org/wiki/Group_isomorphism_problem This means you can't write a single algorithm which takes two arbitrary group presentations as inputs and correctly determines whether the groups as presented are isomorphic.
