* 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...
[0] https://code.facebook.com/posts/745068642270222/fighting-spa...
[1] https://code.facebook.com/posts/302060973291128/open-sourcin...
I think the energy that used to go into alternate Haskell runtimes is now going into alternate languages, like PureScript.
That might have the same appeal for some, but as much as I like Haskell, that sounds like an ancient legacy enterprise monolith to me.
Yeah I don't really understand this. From what I've heard, Goldman Sachs for example, have systems written in a language that no one outside of GS has used, was kinda clever in the early 90s, but hasn't really evolved since and therefore is difficult to get expertise in, and that developers working with it struggle with moving to other companies as their skills are somewhat less transferable.
Edit: at least Facebook and Google open source their internal languages/tools (Go, React, etc) so that those skills become somewhat more transferable.
Number of haskellers in some particular company (despite your attempt at labeling it as "largest" without providing any evidence), do not prove or disprove quality of haskell.
Number of developers implying perfection of language is also easily disproved. PHP or JS are good examples, where original languages become popular because of other factors.
Also, original poster was trying to sell us single data point as measure of popularity O_O
Getting good quantitative informations about languages is hard. But claiming that X devs hired in some company implies poor quality but X+10 would imply good quality is just ridiculous.
Vanilla Ice song, Titanic song (my heart will go on), and Hansen Mmmbop might make you cringe, but people went nuts over those songs for a reason. At the time they were amazing. Php might not be the world's greatest language, but at the time it had what people needed in the way they needed it (easy to build websites). Haskell may be objectively better than Php from a language design standpoint, but there is still a LOT that keeps your average Joe/Jane developer from really learning the language (which string library to use as the seemingly default one is really slow, bad IDE support, unpredictable performance due to laziness, monads...etc). You can tell me Haskell is great all day and on paper I would agree, but due to the simple fact that in reality nobody is using it in production or hiring for it (yes some outliers exist), that tells the average person all they need to know. Where is Haskell on tiobe (yes not a perfect source I'm aware, but good enough)? I don't think it even shows up in the top 50 languages. That means drastically reduced employability to many people.
I'm definitely not bashing Haskell btw. I think it's great, but I could also understand a lot of people shying away for good reason.
I think what makes Haskell harder is that when you go to work, everyone is using Java, Python etc.
Just like it is harder to learn Arabic than English if you live in an English speaking country.
Not sure how this can be addressed, or if it needs to be.
https://code.facebook.com/posts/745068642270222/fighting-spa...
Galois uses it for their financial products,
https://galois.com/about/haskell/
A German company, CMED, uses for their medical services server
Other than that, not all companies are found of putting all their golden eggs on Github.
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.
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.
https://github.com/runeksvendsen/rbpcp-handler
https://github.com/runeksvendsen/bitcoin-payment-channel/blo...
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".
How I'd go on the "used for programming question"
A database of haskell libraries - used for programming - rejected.
A database used as storage for a web site shopfront - used for a web site shop front (or data that isn't to assist a programmer doing programming) - accepted.
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 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 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.
So yes, collect the data of "how many practical applications are there in X language", but also collect the data that show why X language is picked, and the results ( quality, bugs, maintainability, etc ) That's very hard to do though.
When listing xmonad it's also worth mentioning xmobar.
Do websites that are implemented using Haskell "count"?
Signal to noise is awful on such a thing other than to provide the confirmation bias we might be looking for. We're better than that.
Haskell's amazing ability to write parsers in it made the task a breeze.
github.com/jpmorganchase/constellation
Which buries applications in libraries and makes it challenging to get the actual list of applications, which is what I want here and is just one useful datapoint (of many). There is definitely a very long list of haskell libraries, many of which are excellent - this is a separate datapoint that can be considered separately or indeed in concert once we have the actual datapoint of the haskell applications that exist, are used and used for something that isn't programming.
Thanks for mentioning it, I will give it a try!
A certain kind of strengths and weaknesses, but not the only kind. It feels like you're asking a someone who mostly makes raku pottery to show how many pieces they have sold in Walmart... Haskell certainly can be used in the way you're looking for examples, as someone could find a market for their pottery through Walmart, but I think it's ok to let Haskell be in that more artful or avant garde space.
Businesses avoid the new and unusual, because it is new and unusual,
and the artful revel in it, because it is new and unusual!
that's certainly a question that makes sense to ask when you're a business aiming for the big bucks
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.