Seeing so much stuff about Haskell lately, but there seems to be a curious dearth of actual software written in it, if it's so great. How is it that janky hacked together languages like JS and PHP have huge numbers of projects built with them, while a supposedly superior language like Haskell is mostly academic? If it really makes you that much faster, where are the apps?
I understand the critique being made, but this seems like a slightly outdated view of Haskell. There is quite a bit of software being written in Haskell these days. One project that got some press recently is a long existing project that recently went open source, Cryptol [0].
While lots of projects in Hasekll continue to be libraries written for Haskell, there are also lots of languages using Haskell for their implementation language. Browse the GitHub trending repositories listing for Haskell [1] for an idea of what is being done with it.
To be fair most of the trending github projects are libraries for use in Haskell. There are very few actual applications - there is pandoc, git-annex and hakyll and that is it.
It's worth pointing out that the presenter's first language was Haskell and he's been coding in it for over a decade.
LYAH won't get you from apples to expert in weeks, much less months; more likely years.
Consider me skeptical -- needing to build the latest and greatest of Haskell [7.8] from source on a modern Linux distro (CentOS binary with antiquated libgmp.so.3 dependency, seriously?) is a gigantic PITA compared to virtually every other language where you just download a standlaone binary of latest & greatest from langugage X, modify your PATH, and hit the ground running.
Why do you need to build the latest and greatest? Building the very latest gcc/clang is also going to be a PITA. In either case, there's a perfectly servicable binary distribution and the stuff packaged in my OS's repo is still plenty usable.
> Why do you need to build the latest and greatest?
Why shouldn't I? When Scala 2.11 was released I downloaded the binary, changed my PATH, fired up a new terminal and started exploring the latest release. Takes 2 minutes or so.
I'd like to do the same with Haskell. 7.8 looks to have significant language improvements that I want to explore vs. read about and be stuck on 7.4.1 (Fedora 18's provided version).
Indeed I did just that, the issue is that the only binary distributions for Linux are CentOS 6 and some flavor of Debian, both of which are dinosaurs compared to any modern distro. The long and short is the installation fails due to a missing dependency on antiquated libgmp.so.3, thus cooking my CPU for an hour and building from source.
If you want to talk about barriers to Haskell adoption, this is certainly one of them.
"both of which are dinosaurs compared to any modern distro."
Without any clue of what constitutes "any modern distro" in your mind, I don't see how this can proceed further. Note that Centos 6.5 and Debian wheezy are the latest from their respective projects. I believe the Debian version will happily install under recent Ubuntu and derivatives.
I'm sorry your preferred distro doesn't have better support.
On average, people that don't know much about software development, but want to make software, will do it using a language that has a lower cost to entry. For all the elegance and purity of a language like Haskell, it seems to be completely overwhelming for most beginners.
Not all software is created by such people, but I think it explains quite a bit.
I think the package ecosystem is a big barrier. I code on OS X, and it seems like half the Haskell packages I try to install fail to compile. I always get super motivated to do my next project in Haskell, but then give up when I can't install the required libraries. Maybe the situation is better on Linux.
In any case, I think Haskell will need reliable package management on at least OS X and Linux before most developers consider it a serious choice for real projects.
I'm not sure which issues you're running into, but for what it's worth, I've had a lot better success using the newer cabal sandboxes[1] than just running `cabal install foo` all the time. (If you're from the Ruby world, it acts a lot more like bundler with `--standalone`).
Previously, I had more issues with conflicting version constraints which I think is more of an issue with library authors and not necessarily cabal itself.
I'd love to, but Haskell Platform ships with an old version of Cabal that doesn't have sandboxes. The new version of Cabal itself doesn't compile on the Mac. (In keeping with the theme of "nothing compiles.")
Edit: At least, I can't get the new version of Cabal/Cabal Install working on my Mac.
There was a relatively serious bug caused by Mavericks' clang being a non-standard CPP, but I think that's fixed in newer versions of GHC. It's certainly possible to get a Cabal compiled on Mac, though.
Against the usual recommendations, I install the Haskell platform with Homebrew. After that a 'cabal update ; cabal install cabal-install' gives a newer version without any problems.
Manual is OK if there's at least a clear path to getting something to install. I don't see that path, though.
My biggest issue is that I don't have the expertise to debug an obscure Haskell compilation error. I won't develop that expertise unless I can use Haskell over the long term on real projects. I can't do that unless libraries are available. So it's a chicken and egg problem.
I think the same is true for many people who'd like to dive deeper into Haskell. If we can't initially lean on the work of expert package maintainers, we can't ever become Haskell experts ourselves. I believe the developer community could expand very quickly if this problem could be solved.
Certainly the case. Much eased (though not eliminated) by the recent addition of cabal sandboxes. There's still no good way to see all the native libraries required by a cabal install, and occasionally there are actual conflicts between packages... I've been meaning to populate http://en.wikibooks.org/wiki/Haskell/Resolving_Cabal_Hell but have been kinda hoping (almost certainly in vain) that someone with deeper knowledge beats me to it.
People generally learn by forming patterns from many examples, not by studying the patterns themselves. Attempts to directly communicate abstract patterns generally fails (any school anywhere: "this is boring because we are never going to use it").
Programmers are inherently attracted to building on imperfect abstractions, because that brokenness is something to latch on and set about easily solving (as it's been solved many times before and they don't even need to solve it perfectly). If the abstraction did exactly what they wanted, they would have to recognize that, understand what was given to them, and then confront the essential complexity of their problem that much sooner.
Honestly, it seems to me like if you don't understand category theory and type theory well, using Haskell will be either hard or impossible. That's what people who are into Haskell are into, and they seem to be a relatively rare breed. (I have a lot of trouble understanding these subjects, though I continue to try. I still don't know what the hell a monad really is.)
Do you want to know "what a monad is" in math or Haskell?
In programming, a monad is a particular design pattern, which is exposed in a particular interface (appropriately called Monad) in Haskell. The design pattern supports a certain way of combining things. The fact that so many disparate things support this interface (State, IO, Software Transactional Memory, Readers, Writers, Continuations...) means that all of the code we write that generically talks to that interface can talk about any of those things, and that's pretty powerful. The fact that one of those things is, in a certain sense, voodoo (IO) shouldn't lead you to think they all are - Monad is just an interface for combining things according to certain patterns.
>if you don't understand category theory and type theory well, using Haskell will be either hard or impossible
Absolutely not true. I never completed a single credit of university and struggled with high school math. I don't know any type theory or category theory.
Not only am I comfortable in Haskell, I teach Haskell.
Just throwing my voice into the chorus, I know nothing about category theory either, and I don't think that hinders learning Haskell.
I do think there is a subset of Haskellers who use category theory to prove certain ideas and they are able to easily express that in code. However I haven't found it necessary to understand the theory behind why something is sound in order to practically use their work in my projects. That says more about Haskell's expressiveness than the target audience to me.
Setting aside years of imperative (and also OO) programming and learning a different approach to solving problems has been the biggest challenge for me, by far. That's why I agree wholeheartedly with https://news.ycombinator.com/item?id=7687200
I think a more apt analogy would be: no furnace to forge your own cooking utensils (hour long build from source to get latest and greatest [7.8] installed) which you use to prepare the meals (wait for your application to compile) that you then stuff into your mouth (deploy to server).
The 7.6 packaged in Debian is perfectly usable and compatible with everything I've wanted to grab from Hackage. There's a few new bells and whistles in 7.8 (like TypedHoles and -fdefer-type-errors) that I'm looking forward to, but their lack doesn't mean I can't build existing code and when developing new code it just means I lack some new tools. Since these tools are lacking everywhere else, their temporary lack is obviously not keeping people away from Haskell.
Basically, you can get yourself access to a furnace to forge your own melon baller, but you've already got a spoon, and someone else will be shipping you a melon baller next month.
> Well, JS is used because it's the only way to run code on a client system.
Not sure what you mean by this - I guess you're assuming the "client system" is always a web browser?
Currently, I'm writing code for a piece of middleware that is a client to a server that models networking equipment. This client then pushes hundreds of thousands of responses into a fast message queue. None of this is written in JS.
The ecosystem plays a big part in this. NPM is actually a pretty nice package manager to work with. Cabal, on the other hand, took me quite some time to setup and use.
Cabal is actually an extremely nice package manager... it just, like much of Haskell, likes to tell you things won't work far before they fail. In particular, building things with Cabal requires that everything compiles together successfully. This is a much stronger requirement than NPM and has push some more sophistication into the dependency resolution Cabal does.
Indeed, if we deferred all type errors and compile failures from Cabal to runtime like Javascript/NPM then nobody would complain about Cabal! I think it's unfortunate that Cabal get's so much unnecessary blame when the problem is often in some other place entirely.
This is mostly true, but I think we do see more dependency related issues than other languages. My working theory is that this is because we wind up building more small, generally useful packages that get used by lots of things and which can therefore be in conflict. I haven't set out to carefully validate this, though.
