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.
the point is, that often you have one-off applications that are just a few lines and use these libraries.
http://www.infoq.com/presentations/haskell-newsroom-nyt
tldw:
- RoR shop, too slow and can't afford to scale simply by spinning up more AWS instances.
- Haskell type system results in fewer bugs, less downtime than RoR.
- Haskell's Conduit library is great for information flow (e.g. scanning Twitter firehose for breaking stories).
- Static binaries for easy deployment.
- Declarative style and expressiveness helps coworkers understand code quickly.
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.
I don't recommend LYAH and don't think it's an efficient way to learn Haskell at all.
My guide for learning Haskell: https://gist.github.com/bitemyapp/8739525
Should get you going quickly.
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).
https://www.haskell.org/ghc/download_ghc_7_8_2#binaries
You're not comparing apples to apples.
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.
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.
CentOS binary is the only choice and it won't work. FWIW CentOS 6 is equivalent to Fedora 12 or so (latest is Fedora 20).
Anyway, it's done, but a serious PITA, hopefully in future there will be a more sane way to get started exploring the latest & greatest.
Not all software is created by such people, but I think it explains quite a bit.
If you learned Java or another imperative language, picking up another imperative language is nearly trivial.
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.
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.
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.
Edit: At least, I can't get the new version of Cabal/Cabal Install working on my Mac.
Have you sought help from the #haskell IRC channel?
And I agree that sandboxes are great!
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.
I think the important thing is to see how they work, see what they do.
btw, you might try this video: https://www.youtube.com/watch?v=o6L6XeNdd_k
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.
Here's my guide for learning Haskell: https://gist.github.com/bitemyapp/8739525
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
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 there were a byte-code available you can bet people would be using other languages. ASM.js exists, and many languages compile to js at the moment.
As for PHP, lots of people still eat at McDonalds. I can't explain why.
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).
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.
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.