7 ms·

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 hacke

by woah 13y ago

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?

recursive 13y ago
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.
- Guvante 13y ago
  Beginners wouldn't have a problem with Haskell, the intermediates are the problem. If you learned Java or another imperative language, picking up another imperative language is nearly trivial.
dmunoz 13y ago
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. [0] http://cryptol.net/ http://cryptol.net/ [1] https://github.com/trending?l=haskell https://github.com/trending?l=haskell
- m0a0t0 13y ago
  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.
  - ibotty 13y ago
    hakyll is a library and not an application, technically, as is xmonad, another famous haskell "application". pandoc is often used as library as well. the point is, that often you have one-off applications that are just a few lines and use these libraries.
sctb 13y ago
There are some examples here: http://www.haskell.org/haskellwiki/Haskell_in_industry http://www.haskell.org/haskellwiki/Haskell_in_industry
spitfire 13y ago
Well, JS is used because it's the only way to run code on a client system. 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.
- ephemeralgomi 13y ago
  Partially because McDonalds/PHP lets you eat/deploy by cramming/uploading the food/file directly into your mouth/server. No utensils/tools required.
  - virtualwhys 13y ago
    > No utensils/tools required 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).
    - dllthomas 13y ago
      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.
- cgh 13y ago
  > 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.
platz 13y ago
It's a good question which I think deserves thought, for now I'll just be slightly tongue-in-cheek and link this: http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
- mindslight 13y ago
  Tongue in cheek? No, it's completely spot-on. 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.
  - deleted 13y ago
    [deleted]
bilalq 13y ago
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.
- tel 13y ago
  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.
  - freyrs3 13y ago
    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.
  - dllthomas 13y ago
    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.
jarrett 13y ago
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.
- IsTom 13y ago
  It's not that much better on Linux. As a fan of Haskell it makes me sad.
  - dllthomas 13y ago
    It's tractable, but a lot more manual than it should be. It makes everyone sad.
    - jarrett 13y ago
      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.
      - dllthomas 13y ago
        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 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.
gamegoblin 13y ago
Fairly popular tiling window manager: http://en.wikipedia.org/wiki/Xmonad http://en.wikipedia.org/wiki/Xmonad
wting 13y ago
Haskell is used in the NYTimes special features group that deploys 60+/yr web apps. http://www.infoq.com/presentations/haskell-newsroom-nyt 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.
- virtualwhys 13y ago
  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.
  - coolsunglasses 13y ago
    IMVUs average spin-up time for new engineers that don't know any Haskell is ~8-15 days. 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 https://gist.github.com/bitemyapp/8739525 Should get you going quickly.
  - dllthomas 13y ago
    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.
    - virtualwhys 13y ago
badman_ting 13y ago
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.)
- mjhoy 13y ago
  I couldn't really tell you anything about category theory. But I am beginning to grasp monads. (At least in the context of Haskell programs.) 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 https://www.youtube.com/watch?v=o6L6XeNdd_k
- coolsunglasses 13y ago
  >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. Here's my guide for learning Haskell: https://gist.github.com/bitemyapp/8739525 https://gist.github.com/bitemyapp/8739525
- zmoazeni 13y ago
  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 https://news.ycombinator.com/item?id=7687200
- dllthomas 13y ago

by woah 13y ago

recursive 13y ago

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.

Guvante 13y ago
Beginners wouldn't have a problem with Haskell, the intermediates are the problem. If you learned Java or another imperative language, picking up another imperative language is nearly trivial.

dmunoz 13y ago

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. [0] http://cryptol.net/ http://cryptol.net/ [1] https://github.com/trending?l=haskell https://github.com/trending?l=haskell

m0a0t0 13y ago
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.
- ibotty 13y ago
  hakyll is a library and not an application, technically, as is xmonad, another famous haskell "application". pandoc is often used as library as well. the point is, that often you have one-off applications that are just a few lines and use these libraries.

sctb 13y ago

There are some examples here: http://www.haskell.org/haskellwiki/Haskell_in_industry http://www.haskell.org/haskellwiki/Haskell_in_industry

spitfire 13y ago

Well, JS is used because it's the only way to run code on a client system. 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.

ephemeralgomi 13y ago
Partially because McDonalds/PHP lets you eat/deploy by cramming/uploading the food/file directly into your mouth/server. No utensils/tools required.
- virtualwhys 13y ago
  > No utensils/tools required 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).
  - dllthomas 13y ago
    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.
cgh 13y ago
> 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.

platz 13y ago

It's a good question which I think deserves thought, for now I'll just be slightly tongue-in-cheek and link this: http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html

mindslight 13y ago
Tongue in cheek? No, it's completely spot-on. 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.
- deleted 13y ago
  [deleted]

bilalq 13y ago

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.

tel 13y ago
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.
- freyrs3 13y ago
  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.
- dllthomas 13y ago
  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.

jarrett 13y ago

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.

IsTom 13y ago
It's not that much better on Linux. As a fan of Haskell it makes me sad.
- dllthomas 13y ago
  It's tractable, but a lot more manual than it should be. It makes everyone sad.
  - jarrett 13y ago
    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.
    - dllthomas 13y ago
      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 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.

gamegoblin 13y ago

Fairly popular tiling window manager: http://en.wikipedia.org/wiki/Xmonad http://en.wikipedia.org/wiki/Xmonad

wting 13y ago

Haskell is used in the NYTimes special features group that deploys 60+/yr web apps. http://www.infoq.com/presentations/haskell-newsroom-nyt 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.

virtualwhys 13y ago
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.
- coolsunglasses 13y ago
  IMVUs average spin-up time for new engineers that don't know any Haskell is ~8-15 days. 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 https://gist.github.com/bitemyapp/8739525 Should get you going quickly.
- dllthomas 13y ago
  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.
  - virtualwhys 13y ago

badman_ting 13y ago

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

mjhoy 13y ago
I couldn't really tell you anything about category theory. But I am beginning to grasp monads. (At least in the context of Haskell programs.) 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 https://www.youtube.com/watch?v=o6L6XeNdd_k
coolsunglasses 13y ago
>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. Here's my guide for learning Haskell: https://gist.github.com/bitemyapp/8739525 https://gist.github.com/bitemyapp/8739525
zmoazeni 13y ago
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 https://news.ycombinator.com/item?id=7687200
dllthomas 13y ago