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.
Your list should include Standard Chartered and Barclays. Standard Chartered probably has the largest commercial Haskell codebase in the world, it has over 30 full-time Haskell developers and many more users.
They call it a Haskell codebase, but as far as I understand it's their own fork of Haskell 98, that is strict not lazy, with quite a few modifications.
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.
hello! i worked there for 2 years. yes it is a fork called Mu, no it is not not lazy. The Mu Core team are devout Haskellers so don't be too quick to dismiss them as abandoning Haskell's core values.
Thanks for the clarification! I never thought they were not devout Haskellers, but I do always wonder about projects that fork a more standard thing for internal use ending up as poorly maintained legacy software.
They didn't fork GHC. They wrote a new Haskell compiler to target a pre-existing runtime that existed inside the bank. For various reasons related to the runtime that meant the language had to be strict. Mu's creation was, in fact, a step away from legacy.
There is plenty of GHC Haskell in the codebase. It's very common for banks to have proprietary in-house scripting languages. Mu, is at least based on a language standard and is not some ad-hoc design.
The codebases of Facebook and Google would be no less "ancient legacy enterprise monolith".
> It's very common for banks to have proprietary in-house scripting languages
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.
30 developers is either sad, or really sad. Unfortunately, if software is going to wind up restricted to specialized druids adhering to Haskell, I'm not sure that is a good thing
IMHO, sad is when you have large numbers of people hacking on a multi-million line codebase in Python with no static types, unfortunately a far more common situation in finance!
Why would it be sad? There are 30 Haskell developers at SCB, 0 Ruby developers and probably 100s of Excel developers. I don't see why one of these facts should make you sad (or happy) and not the others.
His point is obviously that they should hire more to make Haskell seem popular, even though one of the reasons they don't need more than 30 is because it's Haskell and not JavaScript.
Or OP's point was the largest company using Haskell only employs 30 Haskell devs. A Haskell proponent will say exactly, you only need a few developers with Haskell, while someone suspicious will say if this tech were truly great more people would use it
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.
Sure but these companies develop mission-critical software applications in Haskell. They are not open source for the most part, but in terms of demonstrating that Haskell is practical they are good examples.
They're just names of companies, which aren't very useful as demonstrations. If you could describe some particular problems these companies have solved in Haskell, then that would certainly be useful.
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?
This is a strange distinction to make when evaluating a programming language. I can understand an evaluation that begins like "I need a language that is useful for solving x problem" or even "problem of x type". But if you're trying to evaluate Haskell in general terms, a list of the Haskell apps targeted at a non-technical audience is a dubious heuristic.
I'm pretty sure what OP is considering is that Haskell is well known for its usage in theory heavy works (where the domain is mostly well-specified, and possibly even beautifully so), but not well known for applications where you have to make unspecified, awkward, temporary and sometimes nonsensical updates (anything that so much as breathes near a layman). And given haskell's background as a research language, it makes sense for it to be biased towards the former. So the question is, by how much?
I disagree. C++ is hard to use too (for different reasons), but tons of non-programming related applications are written in it. Most problems aren't programming related, so it makes sense to measure a PL by its effectiveness in non-programming related applications.
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".
Yeah at the margin these things will always be somewhat arbitrary. I would fall on the side of data science is not programming. The purpose of data science (aka practical statistical analysis) is to perform some data transform with a purpose being to provide insight on the world. Programming (in haskell or any other language) is a tool to achieve that insight into crop yields or sales figures or economic policy effect or whatever.
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.
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.
shellcheck is great, I use it, endorse it and recommend it. It is used for programming a computer, I want to exclude those applications. Pugs for the same reason without comparing the two.
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.
I've written and deployed 3 applications written with Yesod so far. I also have some experience with Ruby on Rails. I'd say the two frameworks are rather on the same level of abstraction and similar in terms of productivity in my experience. And I like the type safety Yesod is able to provide, e.g. even for routes.
My experience with Haskell for a webserver is that, yes, it's finnicky to get going. However, type checking from URL router to database [0], with esqueleto, is wonderful. With stack and docker the setup has gotten better.
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.
data is neither fair not unfair. It is collected or not. The collection has a bias or doesn't. It's not fair to count the number of haskell applications compared to pdp-11 assembly language apps to prove the superiority of soft cheese over those hard cheese heretics! Counting however is just counting. Once counted inference can be drawn, debated, rejected, alternative hypotheses advanced. All better done in the presence rather than absence of data, no?
I just meant the interpretation of the data is not fair if you say "not many practical applications are made with Haskell, so it's not a practical language".
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.
I did. I can't imagine anybody other than you made your interpretation, as the asking for data was clearly intended into subsidizing a specific conclusion.
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.
Thanks for bringing it up. That's a terrible list. Each use is unknown in both content and purpose and you can't verify it or really draw much in the way of conclusion from it at all. Was it an intern project that was abandoned or is it now performing core functionality. We'd wish the latter but no way to know. Have 10% of those not worked out (which would be a fabulous success rate or 99% which would be comparable to Java? </troll></just kidding></java is ok really>
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.
Thanks for mentioning Wire! Although I guess the question was about applications and not "services". FWIW, our backend services are almost exclusively written in Haskell.
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.
34 items on that list. Looking at the content I don't think it's fair to use it as much of a datapoint you'd have to reduce that 34 number down yet it's missing git annexe, xmonad and pandoc which exist and are well used! Also as you point out it notes that it's obsolete. Next to where it notes that the list is obsolete it links here: https://wiki.haskell.org/Libraries_and_tools
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.
> 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
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.
The question here is: is Haskell an artful, avant garde language, or is it one that's effective for line-of-business apps? There is space for both kinds of language but it's worth knowing which is which.
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.