I want to see the list of applications written in haskell that are useful and not used for programming a computer.
This list has seemed shorter than one might expect in the past given the interest among programmers in the haskell language (this includes my own interest fwiw). A list of applications written in haskell that are used for something that isn't programming a is a useful datapoint that tells us something about the strengths and weaknesses of the language - we can argue about the subtleties of the meaning of that data point but it is useful data.
Shameless self-plug. We've started using Haskell at Vacation Labs and we even spoke about it at Functional Conf 2017, Bangalore [1]. The talk was called "Joys & frustrations of putting 34,000 lines of Haskell into production" -- so it wasn't only fan-boyism!
Like Ruby and Erlang, Haskell is used a lot for building server-side applications. It's runtime offers N*M threading and software transactional memory, which make it an attractive choice to many. It's webserver, Warp, performance-wise is competitive with Nginx.
I don't see how that's a very good measure at all.
Nevertheless, in the haskell companies I've worked at, we've used haskell for network packet inspection (not programming) and marketing automation. In both, our frontend was dependent on Haskell as well: in the former, through purescript, and in the latter, directly using reflex-js.
I'm writing a NES emulator in Haskell atm. It's still in progress, so please don't judge the code too harshly :P There's lots of nastiness I mean to fix up:
The long-term goal is to run Linux on standalone VR headsets. Right now we have something working with the HTC Vive.
The Window Manager is being written in Haskell (with lots of C/C++ FFI). It's a very serious project, attempting to do something with Haskell that isn't merely useful for more programming.
I’ve written a Bitcoin payment channel server/client in Haskell. I know it’s not exactly a well-known problem, but it felt very practical to me. So there’s a lot of logic, but also quite a lot of input/output to handle (e.g. saving payments to the database)
Not trolling here: what do you mean by "not used for programming a computer"? I'm genuinely confused because I would think that all uses of a programming language qualify as programming a computer. Do you mean applications of Haskell to domains that are messier than compilers and other classic computer science problems?
http://sentenai.com is a modern data historian replacement targeted at data science use-cases. Data science involves programming, so do we consider that using Haskell for something other than programming? If so, I think it disqualifies a broad range of software like database systems from being considered as "applications not used for programming a computer".
For many years, my employer's SDK release notes were stored as a Haskell DSL, which could be compiled and executed to produce HTML or plaintext. As far as I know, it was the only "production" Haskell in the company.
jq was originally written in haskell (then rewritten in c, mainly for a small self-contained executable, I believe).
I don't see it as a criticism that haskell is useful as a cradle in this way, just because the project later moves - it would have been much harder to start without haskell (and maybe impossible, without haskell concepts - which TBF could be acquired in other ways).
I use Haskell for a special-purpose MediaWiki parser, wikiparsec [1]. It extracts information from Wiktionary to put into the ConceptNet knowledge graph. (Does that still count as programming a computer?)
I actually do not like the Haskell ecosystem very much. I don't like the broken Prelude (standard library) that you're supposed to replace but there's no consensus on what to replace it with, and I don't like how every library introduces its own unpronounceable infix operators. I also don't even think that using the word "monad" is a good attempt at communication.
But for non-trivial LL parsing, there's no alternative. There's Attoparsec in Haskell, and there's libraries that wish they were Attoparsec.
So you are mainly interested in GUI applications for laypeople to use, right?
I think there is a simple reason for that not existing as much as you'd think or hope: writing a GUI framework from scratch is a lot of work. So what people do nowadays is try to bind to existing libraries, GTK, fltk, DOM, Qt, etc...
But that comes with a cost: Those libraries need mutation to work, and therefore feel alien, and pointless to use in an immutable functional programming context. Most of your app would need to live in `IO`, basically. Why use Haskell at that point?
But there is a way to tame this beast: Functional Reactive Programming, or FRP for short. This way one could compose pure functions, events and behaviors that drive an underlying mutating GUI library in a deterministic way.
reflex-frp comes closest to this in my experience so far, which with reflex-dom and jsaddle is able to drive a browser window through a low-latency, local websocket connection. Meaning that you can, for example, run native Haskell code and only run a very thin layer of JS to interface with the DOM. This way you can build apps that have a GUI window on the desktop (e.g. with WebkitGTK) and is much faster than Electron.
You can also build the same reflex-dom apps to Android and iOS, and I've heard others remark that due to the native code doing most of the work in the background it is able to run faster on an ARM CPU than the comparable JS on the desktop. Though I've yet to try this myself to confirm.
At any rate, I think we are getting very close to a tipping point where GUIs become easy enough to write and then you'll see more and more written with Haskell.
Edit: Another potential "attack-vector" will be WebAssembly: Instead of compiling Haskell to JS via GHCJS, you could compile it to wasm and use it on websites' front-end much more performantly. When there is a working Haskell-to-wasm compiler, (hopefully soon) you'll also likely see more and more GUIs written with Haskell on the web.
I agree, this seems like an issue to me. I work on a B2C web application, and I generally love working on projects like that, but I've seen so few made with Haskell, and every time I try to start a project along those lines (be it with Yesod, Snap, Spock, Servant, etc), I find the libraries and tooling far less productive for creating those sorts of applications than, say, Django.
I think the Haskell ecosystem desperately needs a Django/Rails level web framework, including the documentation that goes along with that, because right now nothing comes close.
Still, I don't think it's a "fair" question, because the main reason there are not many practical applications written in Haskell, is because companies prefer dynamic scripting languages. They do that to "get things done" or in other words, ship fast a product full of bugs.
My company, https://www.lumi.com (W15) uses Haskell almost exclusively on the backend. We use it to write our API and internal tools such as our custom ERP.
There’s also threadscope (even available in Ubuntu without adding new APT repositories: https://packages.ubuntu.com/xenial/threadscope) which is a visualization tool for debugging with Haskell event logs.
For people that have gotten into Haskell, but struggle to get over the intermediate level, I would warmly recommend checking out https://www.fpcomplete.com/haskell-syllabus. As for good tips, I've come to like the ReaderT "design pattern"[0].
For newcomers, I would recommend the Haskell Book[1], which covers everything quite extensively.
> Writing Haskell is almost trivial in practice. You just start with the magic fifty line {-# LANGUAGE ... #-} incantation to fast-forward to 2017, [...]
This was my biggest frustration with Haskell the last time I used it, I find it sad that it doesn’t seem like they’re trying to fix it.
As a semi-recent initiate to Haskell, it's really helpful to see such an accessible compilation of important Haskell developments. Although it's easy to find Haskell material to read, it's not as obvious to highlight what's important.
Haskell is definately one to watch for Blockchain. IOHK have released a currency with their codebase largely in Haskell. Both IOHK and Digital Asset have smart contract / modelling languages based on Haskell.
I'm particularly excited about the prospect of linear types; not so much for helping with space/GC efficiency (which is good of course) but for modeling state transitions and ensuring that, for instance, some intermediate state must get consumed once and only once. It's one of the bugs I often run into when writing Haskell code.
He writes: "Most large Haskell projects (GHC, Stack, Agda, Cabal, Idris, etc) no longer use Haddock for documentation."
So, what do they use? How do I get (I mean, build in stack) my useful documentation? (Actually I appreciate any tips how to build documentation for off-line use.)
My impression of Haskell is that the main issue is that laziness is simply wrong, since it causes space leaks that are hard to reason about, and seems generally less efficient than eagerness; furthermore, it seems rarely beneficial, so it seems more appropriate to explicitly request laziness rather than the opposite.
The next problem is that complete immutability is also wrong, because controlled mutable aliasing with linear types (like the system available in Rust) is what you really want since it's more general, efficient and expressive (allows mutable data structures), and complete immutability is just a special case of controlled mutable aliasing.
The third problem of Haskell is the weird syntax, that doesn't follow the common C/Java/JS or Python syntaxes for no good reason, making it hard to read and learn the language.
And if one were to change these things in Haskell, the result would essentially be Rust (or more precisely, a future version of Rust once all the missing abstractions like HKT, specialization, etc. are added), so I think that's what one should use instead.
[+] [-] harry8|8 years ago|reply
This list has seemed shorter than one might expect in the past given the interest among programmers in the haskell language (this includes my own interest fwiw). A list of applications written in haskell that are used for something that isn't programming a is a useful datapoint that tells us something about the strengths and weaknesses of the language - we can argue about the subtleties of the meaning of that data point but it is useful data.
I've got
to get things started. Let's get them down.[+] [-] saurabhnanda|8 years ago|reply
* Video of the talk - https://www.youtube.com/watch?v=7NB8tMa8sUk)
* Slides (with more text and written commentary) - https://docs.google.com/presentation/d/1ggTVXzqCxcmkV5mKUH_g...
[1] https://confengine.com/functional-conf-2017/proposal/5409/re...
[+] [-] TheAceOfHearts|8 years ago|reply
[0] https://code.facebook.com/posts/745068642270222/fighting-spa...
[1] https://code.facebook.com/posts/302060973291128/open-sourcin...
[+] [-] willtim|8 years ago|reply
[+] [-] quickthrower2|8 years ago|reply
https://ambiata.com/
https://www.capital-match.com/
https://circuithub.com/
https://target.com/
https://facebook.com/
https://www.frontrowed.com/
Also
https://www.quora.com/What-startups-use-Haskell-for-producti...
[+] [-] tathougies|8 years ago|reply
Nevertheless, in the haskell companies I've worked at, we've used haskell for network packet inspection (not programming) and marketing automation. In both, our frontend was dependent on Haskell as well: in the former, through purescript, and in the latter, directly using reflex-js.
You'd never know it interacting with our site.
[+] [-] domlebo70|8 years ago|reply
http://github.com/dbousamra/hnes
[+] [-] georgewsinger|8 years ago|reply
The long-term goal is to run Linux on standalone VR headsets. Right now we have something working with the HTC Vive.
The Window Manager is being written in Haskell (with lots of C/C++ FFI). It's a very serious project, attempting to do something with Haskell that isn't merely useful for more programming.
[+] [-] runeks|8 years ago|reply
https://github.com/runeksvendsen/rbpcp-handler
https://github.com/runeksvendsen/bitcoin-payment-channel/blo...
[+] [-] kccqzy|8 years ago|reply
[+] [-] maxhallinan|8 years ago|reply
[+] [-] ghc|8 years ago|reply
http://sentenai.com is a modern data historian replacement targeted at data science use-cases. Data science involves programming, so do we consider that using Haskell for something other than programming? If so, I think it disqualifies a broad range of software like database systems from being considered as "applications not used for programming a computer".
[+] [-] a_bored_husky|8 years ago|reply
[1] https://github.com/jgm/gitit
[+] [-] SllX|8 years ago|reply
[+] [-] tomjakubowski|8 years ago|reply
[+] [-] hyperpallium|8 years ago|reply
I don't see it as a criticism that haskell is useful as a cradle in this way, just because the project later moves - it would have been much harder to start without haskell (and maybe impossible, without haskell concepts - which TBF could be acquired in other ways).
[+] [-] rspeer|8 years ago|reply
I actually do not like the Haskell ecosystem very much. I don't like the broken Prelude (standard library) that you're supposed to replace but there's no consensus on what to replace it with, and I don't like how every library introduces its own unpronounceable infix operators. I also don't even think that using the word "monad" is a good attempt at communication.
But for non-trivial LL parsing, there's no alternative. There's Attoparsec in Haskell, and there's libraries that wish they were Attoparsec.
[1] https://github.com/LuminosoInsight/wikiparsec
[+] [-] Wizek|8 years ago|reply
So you are mainly interested in GUI applications for laypeople to use, right?
I think there is a simple reason for that not existing as much as you'd think or hope: writing a GUI framework from scratch is a lot of work. So what people do nowadays is try to bind to existing libraries, GTK, fltk, DOM, Qt, etc...
But that comes with a cost: Those libraries need mutation to work, and therefore feel alien, and pointless to use in an immutable functional programming context. Most of your app would need to live in `IO`, basically. Why use Haskell at that point?
But there is a way to tame this beast: Functional Reactive Programming, or FRP for short. This way one could compose pure functions, events and behaviors that drive an underlying mutating GUI library in a deterministic way.
reflex-frp comes closest to this in my experience so far, which with reflex-dom and jsaddle is able to drive a browser window through a low-latency, local websocket connection. Meaning that you can, for example, run native Haskell code and only run a very thin layer of JS to interface with the DOM. This way you can build apps that have a GUI window on the desktop (e.g. with WebkitGTK) and is much faster than Electron.
You can also build the same reflex-dom apps to Android and iOS, and I've heard others remark that due to the native code doing most of the work in the background it is able to run faster on an ARM CPU than the comparable JS on the desktop. Though I've yet to try this myself to confirm.
At any rate, I think we are getting very close to a tipping point where GUIs become easy enough to write and then you'll see more and more written with Haskell.
Edit: Another potential "attack-vector" will be WebAssembly: Instead of compiling Haskell to JS via GHCJS, you could compile it to wasm and use it on websites' front-end much more performantly. When there is a working Haskell-to-wasm compiler, (hopefully soon) you'll also likely see more and more GUIs written with Haskell on the web.
[+] [-] CannisterFlux|8 years ago|reply
[+] [-] danpalmer|8 years ago|reply
I think the Haskell ecosystem desperately needs a Django/Rails level web framework, including the documentation that goes along with that, because right now nothing comes close.
[+] [-] antouank|8 years ago|reply
Still, I don't think it's a "fair" question, because the main reason there are not many practical applications written in Haskell, is because companies prefer dynamic scripting languages. They do that to "get things done" or in other words, ship fast a product full of bugs.
[+] [-] kepano|8 years ago|reply
[+] [-] syn_rst|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] burkaman|8 years ago|reply
[+] [-] asjo|8 years ago|reply
When listing xmonad it's also worth mentioning xmobar.
Do websites that are implemented using Haskell "count"?
[+] [-] patmcguire|8 years ago|reply
[+] [-] ycmbntrthrwaway|8 years ago|reply
[+] [-] mbrock|8 years ago|reply
[+] [-] jose_zap|8 years ago|reply
Haskell's amazing ability to write parsers in it made the task a breeze.
[+] [-] kccqzy|8 years ago|reply
[+] [-] alvarosevilla95|8 years ago|reply
github.com/jpmorganchase/constellation
[+] [-] bollu|8 years ago|reply
[+] [-] Tehnix|8 years ago|reply
For newcomers, I would recommend the Haskell Book[1], which covers everything quite extensively.
[0] https://www.fpcomplete.com/blog/2017/06/readert-design-patte...
[1] http://haskellbook.com
[+] [-] MBCook|8 years ago|reply
This was my biggest frustration with Haskell the last time I used it, I find it sad that it doesn’t seem like they’re trying to fix it.
[+] [-] darkkindness|8 years ago|reply
Cheers!
[+] [-] willtim|8 years ago|reply
[+] [-] fegu|8 years ago|reply
[+] [-] jzb_|8 years ago|reply
[+] [-] xvilka|8 years ago|reply
[1] https://luna-lang.org
[+] [-] mjhoy|8 years ago|reply
[+] [-] js8|8 years ago|reply
So, what do they use? How do I get (I mean, build in stack) my useful documentation? (Actually I appreciate any tips how to build documentation for off-line use.)
[+] [-] greatNespresso|8 years ago|reply
[+] [-] topogios|8 years ago|reply
The backend, https://github.com/kirel/detexify-hs-backend, for Detexify, http://detexify.kirelabs.org/classify.html.
Parts of BazQux Reader, a commercial feedreader, https://bazqux.com
Nikki and the Robots, a platformer, https://github.com/nikki-and-the-robots/nikki
[+] [-] moocowtruck|8 years ago|reply
rewritten from clojure, used to power smart products at facebook
[+] [-] akinsketch|8 years ago|reply
[0] https://www.habito.com/
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] haskdev|8 years ago|reply
Justice prevailed despite the futile attempts by the Haskell Committee to prevent Stack becoming popular!
[+] [-] devit|8 years ago|reply
The next problem is that complete immutability is also wrong, because controlled mutable aliasing with linear types (like the system available in Rust) is what you really want since it's more general, efficient and expressive (allows mutable data structures), and complete immutability is just a special case of controlled mutable aliasing.
The third problem of Haskell is the weird syntax, that doesn't follow the common C/Java/JS or Python syntaxes for no good reason, making it hard to read and learn the language.
And if one were to change these things in Haskell, the result would essentially be Rust (or more precisely, a future version of Rust once all the missing abstractions like HKT, specialization, etc. are added), so I think that's what one should use instead.