In my opinion, much of the (justified) fear and apprehension that I see in the “I feel like Haskell is dying” thread is due to poor accessibility to Haskell production users’ experiences. The resulting mismatch of information appears to even affect core GHC contributors, and it appears that most non-Haskell-employed Haskellers feel that the language and its job market are dead or dying.
One of the biggest rebuttals we see from Haskell-is-alivers are the strongly-held claims that the Haskell job market is up to 10x larger than it was 10 years ago. This generally aligns with my experience, but I have no real data to go off: linking to some “usage” metrics is obviously not going to cut it - those sites are an awful estimate of usage or language-death and are without a doubt not a substitute for lived experiences.
So in order to ameliorate this imperfect information exchange collect subjective but standardized experience reports of real world Haskell. I want these reports to accumulate into reference points that might help non-visionaries believe in the economic utility of a language like Haskell .
The following is all up for debate: I am stating everything as fact to make it easier to discuss, but please push back on anything and everything
A Haskell Experience Report will convey the lived experiences of using Haskell in a production setting with money and full-time employees involved . The target audience will be anyone no more familiar with Haskell’s ecosystem than a newbie Haskeller: think Hacker News, not r/haskell.
I want Haskell Experience Reports to make Haskell a language that when an outsider says “yeah but who actually uses Haskell”, instead of linking to pandoc, we link to a single webpage (or the HF website) and they see myriad experience reports from a variety of domains, markets, and company sizes.
The target audience will be non-technical non-Haskellers. The reports should exclude as few readers as possible and the reports should be able to communicate the value of Haskell whilst keeping technical details to a minimum.
For example, it might be reasonable to mention using the Polysemy library and that it made code more maintainable and easier to use. It would likely not be relevant to discuss different encodings of monads or the differences between algebraic effects and monad transformer architecture.
The experience reports should be rigidly formatted and non-casual. These features will aid in conveying professionalism and will communicate a data-minded approach to the experiences offered by the authors. To be clear, the content will still be fully subjective, but when comparing any two experience reports, the user should be able to easily observe the similarities in format and writing style.
Reports should use a formal tone, and attempt to extract value-oriented judgments of the usability of Haskell and its ecosystem, even in social/emotional evaluations. For example, instead of, “I really liked using lens - it was fun and made waking up easier”, it would be preferable for a report to say, “We found that lens had the benefit of improving engineer morale, who reported that working on the code base was more motivating and exciting as a direct result of using it”. The reason for choosing a formal tone is because we would like these reports to be some sort of match to insert_favourite_PL_usage_graph, and so appealing less-so emotion (where appropriate) is critical. A formal tone also communicates a business-oriented mindset that readers might not have seen from Haskell users.
The format as I have imagined it should be rather rigid. There will likely be at least one catch-all Other Thoughts section, but when addressing major evaluation metrics, such as hiring or performance, there will be designated heading/subheadings. Such rigidity enables a manager considering Haskell to efficiently find/consume the information they need in a reports, which is greatly aided by a rigid format. Another added bonus of a rigid format is that it makes experience reports far faster to write and we could therefore (hopefully) get more content.
There will be a final letter grading (e.g. D <=> A) at the end of the report for a number of metrics (no suggestions: totally up for debate), so that we can give quick glance summaries of the report’s subjective opinions. I think such a section adds readability/fun factor, and it gives a good summary for someone skimming the article. If the grades are colored and attractive, a user might say to themselves, “Ooh Haskell got an A for hiring/team-building; what’s that about?” and then click directly to that section. I’m interested to see what others think here.
This section is very open to debate, and so I don’t want to push the conversation in any direction, other than coming up with some ideas on section headings:
- Problem Domain (perhaps standardized to keywords or a word description)
- Process of choosing Haskell and other (dismissed) choices
- Engineering experience:
- Code review
- Haskell ecosystem:
- Tooling (IDEs etc.)
- Libraries: docs, quality etc. (perhaps this should be a separate section?)
- How did Haskell work post-deployment:
- Runtime performance
- Errors/bugs/customer experience
- Biggest successes (not mentioned above)
- Biggest gripes/regrets/lessons (not mentioned above)
- Future of Haskell at company
I don’t want to talk about this too much because I think this should be discuss later. Some general ideas to help orient us is that I think we might publish these reports every other week on public forums, and that their content would be hosted on the Haskell foundation website, or some other larger Haskell organization.
I’ll add to this section as we go:
- For now, I want to limit to in-production reports. Future iterations might add reports for educators or open-source projects, but we won’t discuss that today.
- How the articles are written (raw text; markdown). These are implementation details for later down the road.
- Who will take on the work. I would happily take on a lot (all?) of the work. But perhaps someone would take it off my hands - we can decide later
- How reports are chosen for publication.
- Who is eligible for a Haskell Experience Report? Should we have a minimum time limit on Haskell usage? Should there be a minimum team size?
- Perhaps these reports should happen only at major time intervals for a team; say 6 months, 2 years, 5 years? Perhaps they can happen at any time for any team? I’m inclined to say they can happen whenever…
 Gabriella Gonzalez – How to market Haskell to a mainstream programmer
 For now, I am limiting the scope of experience reports to for-profit organizations, but future additions to the format could support open source and full-time volunteer work.