Growing the Haskell Community - VideoChat

Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.

Hazem

I think most of us here agree that Haskell is great. We can also probably agree that the world would be a better place if Haskells becomes more popular.

But Haskell is currently #41 per the TIOBE Index:
https://www.tiobe.com/tiobe-index/

It is ranking below languages like Rust (#27), Scala (#28), LISP (#32), and F# (#33).

The rank alone doesn't tell the full story, and the TIOBE index may not be the best indicator for language adoption (this is for another discussion), but clearly it would be worthwhile to actively invest in growing our community.

It is especially challenging in the case of Haskell (e.g. as opposed to Rust) because many programmers have never heard of Haskell, and many will probably find the learning curve steeper than that of widely used languages. Learning Haskell is more intimidating than learning Rust, for example, and I think this is a major factor affecting Haskell adoption.

I know the Haskell community has probably discussed this before but I think it's worth discussing in a dedicated video session if there is enough interest.

Proposed discussion points:

  • The current state of Haskell adoption
  • Past and current organized dedicated efforts to grow the Haskell community
  • How can we contribute to pre-existing community growth efforts?
  • Discussing ideas for new dedicated community growth initiatives

The current quarantine situation is the reason I started thinking about this topic. I noticed Haskell meetups shifting to online streaming. ZuriHac2020 will be held online. Our video chat sessions here also started due to the quarantine. Personally, I found learning Haskell to be more enjoyable and less intimidating thanks to these new changes, and this made me wonder if this increased level of community interaction can be maintained in the future, and how helpful it would be to the growth of the Haskell community going forwards.

Anyway, I'm up for discussing these points in a video chat session if anyone else is interested. Feel free to suggest the ideal date/time for the chat + any additional points for discussion about this topic

Thanks!

Hazem

Update: We discussed this after today's General chat and it was very informative. Let's use this post for the ongoing discussion and planning future chat sessions for this topic.

Vance Palacio

I have another thought to add to this discussion.

There were comments made about the success of languages like Go and Rust - they're success is attributed in part to the fact that big companies are pushing them and using them.

Maybe the question:
"How do we foster greater adoption of Haskell?"

Is closely related to the question:
"What are the major blockers with getting Haskell software into production?"

My line of thought is - at the end of the day, it doesn't matter if people like a language or not. Businesses want to make money, and you're going to use the language they tell you to use.

If Haskell provided enough value, businesses would be all over it, and adoption grows due to necessity. I believe business adoption is key to language adoption. Anyways! That's enough out of me! Just my 2¢

One more question that might be helpful: "What would have helped James successfully beat his co-worker in creating that service in Haskell?"

Hazem

Great points @Vance Palacio . A great example to support the point about business:
Apple made Swift de facto mainstream by making it the official language for the Apple ecosystem, which itself is popular/mainstream.

Swift has a bunch of functional features but doesn't seem to advertise that heavily. It's almost certain that Swift as a language would not have gone mainstream without Apple's patronage.

It's unlikely that that a large company that owns a popular platform would adopt Haskell, but I think we can still make it compelling for a large number of users in the industry. I know this sounds overly optimistic but this is for an upcoming discussion.

As for the last question, I think there also is a chicken and egg problem involved (to some extent).
more adoption = more libraries, or more libraries = more adoption

Ruby had a library that did 80% of the work in that example, and this seemed to be a major factor in the final outcome.

Regardless of the specifics of the situation James described, I'm willing to bet similar situations have occurred in other companies as well, and I agree it's really instructive to think about adoption from that perspective.

Thanks again. Today's discussions convinced me to take this topic more seriously and to look further into it.

Sridhar Ratnakumar

Somewhat related: there are successful indie products written in Haskell. Eg: bazqux.com ... I'd imagine that Haskell helps the author to deliver in time and maintain the app with greater reliability ...

Your friend for reading feeds.
Ahmad Abdelwahed

I am not part of Haskell community to judge but from what I read and heard about Haskell history, the language is more tight to the academic realm more than business/engineering, and that's what makes it unique and different but -in my humble opinion- that'a also what makes far from adoption.

If you read articles, books, or questions in any main stream language, you will find discussions about microservices, SOAP vs RESTful, NoSQL, bigdata, cloud...etc whatever technology occupy the field at specific time, while Haskell community -according to my very little search- barely discuss these topics which makes it look as an alien to the software community.

I might be wrong, but functional programming communities in general and Haskell in specific focuses on the language features and correctness more than software engineering and system solutions so they don't show on business radars that much.

Hazem

ooh I never knew BazQux was written in Haskell!

"I'd imagine that Haskell helps the author to deliver in time and maintain the app with greater reliability ."

This is the kind of thing outsiders should be hearing about Haskell. I think many may take it with a grain of salt until provided with compelling evidence that it is possible + worth the effort. I'm not sure what that sort of evidence should look like. Definitely worth thinking about.

@Ahmad Abdelwahed I think a major part of this issue is related to outsider awareness. Since Haskell is somewhat niche in the industry, many decision makers in business simply don't know much about what it can offer in practical terms, especially in the long run. I suspect Haskell gets rapidly dismissed in those settings (or never even considered in the first place), and this is one of the major adoption bottlenecks we should be addressing. The benefits are clear to Haskellers, but not to outsiders. The delta is awareness/education IMO.

Sridhar Ratnakumar

@Hazem Perhaps someone can encourage the author of BazQux to give talks, and write blog posts, on how Haskell particularly benefited his solo entrepreneurship. Once you can see how Haskell makes making a living easier (the most compelling evidence there ever is), few people would continue to have reservations about Haskell.

Hazem

I think that would be cool for sure!

I think the BazQux example alone isn't enough, though. It might get perceived as:
A really smart programmer who had a good business idea was capable enough to be productive with a notoriously difficult language. (the genius lone hacker stereotype)

I'm trying to think of ideas that would be much harder to dismiss from an outsider perspective

Georgi Lyubenov // googleson78

pandoc is also a good example imo

Sridhar Ratnakumar

I think the BazQux example alone isn't enough, though.

petit à petit, l’oiseau fait son nid

gilmi

You seem interested so here are a few more cool open source applications written in Haskell:
https://github.com/soupi/haskell-study-plan/blob/master/README.org#a-few-cool-open-source-applications

An opinionated list of resources for learning Haskell - soupi/haskell-study-plan
gilmi

I don't have an idea on what is needed to make more people interested in Haskell, but I think the lack of a better ux wrt tooling and learning resources doesn't help.

Sandy Maguire

^ These things are huge

Sandy Maguire

we aren't making potential adoptees' lives easier by:

  • not offering easy, out of the box language servers
  • not being able to easily target the web
  • not being able to easily target UI
Sandy Maguire

convince the programmer masses of hs, and the businesses will follow

Sandy Maguire

the business guys _do not give a fuck_ what the nerds are doing so long as it makes them money

Sandy Maguire

for the most part business tech stacks are determined by whoever was the first engineer

Sandy Maguire

focus on UX for engineers, and they will naturally penetrate the business market

gilmi

tbf I don't think most languages make it easy to target the web or gui either.

Also I think general business people are somewhat afraid of using Haskell and will try to find reasons not to use it.

But if developers have a good ux when they start with Haskell - be it the tooling, the learning resources and ecosystem, in a way that enables them to go and do what they want to do fairly quickly, more people will want to use it.

TheMatten

Maybe we're sort of going against ourselves when trying to promote new solutions to business people - I mean, their business is doing fine, they're making money, we are fixing bugs and adding features and somehow getting through the deadlines and when we're asked about our progress and feelings, we're inclined to say we're doing fine, and then we suddenly come and start talking about how everything is broken and we need to switch tools we use - from ones everyone uses to ones some academics are talking about.

Look at the case of Rust - I would say it's one of the few languages with FP origins that's getting a really good traction recently. It has a long way to go, but big business are starting to slowly depend on it in critical infrastructure. But notice one thing: it mostly sells itself on one specific thing - prohibiting memory-related bugs, ones that are filling CVE database and make headlines for exposing serious vulnerabilities. That's something concrete, something business people can see by themselves, something you can measure, something you can point to in C++/C code and say "this wouldn't happen in Rust". I think we're often much less concrete when presenting e.g. Haskell itself - at the end, other languages have type systems and first-class functions too, we someone have to get through that they're _different_ there.

gilmi

Memory-related issues are just too big to ignore. I don't know if null pointer exceptions, cast errors, concurrency bugs, etc. Are that big of a deal to a business in comparison.

gilmi

Two places where I see Haskell can bring value very quickly are writing tests with quickcheck and build systems with shake, but those aren't too visible to stack holders.

Hazem

Disclaimer: I'm not a seasoned Haskeller. Wild speculation below. You will probably change my mind

Re: UX for engineers @Sandy Maguire

I think those pain points are definitely worth fixing. Haskell should be much less painful to work with. No question about that.

During our last video chat we discussed this in the context of increasing adoption, and the question was:

If Haskell suddenly had great UX for programmers, will that significantly increase adoption?
(great UX in this case was referring to tooling and libraries)

and my wild guess is: Probably not. The biggest barrier to adoption is elsewhere.

I imagine the journey of someone assessing whether to adopt Haskell somewhat follows this order:

  1. Awareness of pain points / bad ideas in mainstream languages/paradigms
  2. Awareness of the FP paradigm / Haskell and its benefits
  3. Learning FP -> Learning Haskell
  4. Using Haskell to build something
  5. Maintaining something built in Haskell
    ...

My guess is that the Haskell adoption bottleneck for MOST developers in the industry happens around stage 1 (or 0 if I have no faith in humanity)

I'm also guessing that a sizable majority of those who make it through stage 1 abandon Haskell in stage 2 (I'm an example of that, but I repented :P)

Past this point, I think a lot of people get hooked on Haskell (not necessarily for practical use), and this group will be served greatly by improving the daily pain points of dealing with Haskell (i.e. better tooling etc). Some people quit Haskell due to those UX issues, but I doubt it's a majority. Once someone understands the benefits of Haskell, it's hard to let go.

So I think great UX wont necessarily improve Haskell adoption in a noticeable way. We should absolutely fix those issues ASAP, but for different reasons. (Again, by UX I'm specifically referring to tooling and libraries)

Awareness about Haskell and its benefits is probably way lower than it should be. Furthermore, Haskell is uniquely difficult to learn (compared to mainstream languages). The adoption bottlenecks for most developers are probably at those stages.

So based on the above speculation, I'm proposing that:

  • If Haskell gets great tooling, it might increase adoption a bit.
  • If Haskell gets great learning resources and provides clear claims about its benefits, it might bring Haskell much closer to mainstream adoption. (a lot of emphasis on great)

I think @TheMatten pointed out something really important in the Rust example. You can sell the benefits of using the language in one sentence. The sentence is educational in nature:
Memory safety is a major problem, and Rust solves this issue without sacrificing performance.

I realized I am not a representative sample, but this is how I got into Rust: I was a noob who didn't know why memory safety was a big deal. Someone told me having memory safety was a major benefit. I opened the Rust website and found the official Rust book. 20 minutes of reading later, I was sold on learning the language. The benefits were already clear to me. A few weeks later, I was going through a second book already.

I had a somewhat similar experience with Racket. I read somewhere about the benefits of language-oriented programming, and I found the book Beautiful Racket via the Racket website. The book explained the benefits of this paradigm, with clear examples, and I was sold on learning it.

My experience in Haskell has not been similar, sadly. The main thing that kept me here is my prior conviction that FP is really worth using, along with realizing that I need a powerful type system. It took me a while to understand the benefits of using Haskell. It might be an issue with how I think, but I'm guessing my experience might be generalize-able.

We can try to sell Haskell in one sentence. The official Haskell website has this at the top:

"Declarative, statically typed code."

The implications of this setence will not be understood by a large number of developers (the majority, I'd bet). The benefits are not clear without prior knowledge about these topics.

The website then lists these headings:

  • Statically Typed
  • Purely functional
  • Type inference
  • Concurrent
  • Lazy
  • Packages (active open source contribution)

I can group them up to form a sentence:

"Haskell is a statically-typed, purely-functional, lazy-evaluated, concurrent programming language with powerful type inference and an active open source package ecosystem."

and again I'm willing to bet a lot of developers wont really get the implications of this statement. The features are listed, and the benefits are implied only to those with prior knowledge of these topics.

I think the selling point should be through emphasizing the benefits of these features. To be fair, the benefits are somewhat explained below each heading, but I think they should be the main attraction; They should be clarified in one sentence.

I really like how Rust does it. This is from the official website:
"A language empowering everyone to build reliable and efficient software."

This is explaining the benefits, without listing any features. Below that, there are these headings:

Why Rust?
- performance
- reliability
- productivity

and this is followed by more info on why Rust is practical and how it's being used in production.

The features are listed throughout the homepage, but mainly in the context of explaining the benefits.

Contrast the Rust homepage to Haskell's homepage. There is no attempt to explain that Haskell is in fact used successfully in production at Microsoft and Facebook, for example.

In my opinion, we can focus on summarizing the benefits of Haskell when talking about the language. It would be cool if the homepage explained it like so:

"Haskell lets you build maintainable high-performance applications with much less code and much less bugs than mainstream languages."

If we had GREAT learning resources, we can add this to the homepage:

  • Is it true that Haskell is difficult to learn?

  • This used to be the case, but we solved it. It is true that programming in Haskell is done differently from mainstream languages, so it requires some learning. Luckily, we have an excellent selection of resources to teach you how to use Haskell. They will teach you Haskell from scratch by guiding you, step-by-step, through building practical projects and libraries, and show you the skills you need to use Haskell in production.

So this is why I think we should prioritize raising awareness about the benefits of Haskell + providing GREAT learning material as a way to increase adoption.

My experience with Haskell books has been really sub-optimal, and that was after reading multiple books on FP first. It must be much harder for developers who are not even familiar with the FP paradigm.

I started this discussion to share my wild speculation on the matter. I realize I'm probably wrong, but if Haskell education really has a chance of removing a major adoption bottleneck, I'm very likely to commit to working on this issue for the upcoming 6~12 months. I have a lot of free time on my hands and this would be a worthy pursuit if it has a really good chance of being effective. I'm already drafting a concrete plan, but discussing it in text form will be too lengthy. @anyone please feel free to DM me if you want to chat about specific details.

Thanks a lot and sorry for the long post. I'm just really interested in figuring this out.

EDIT: I picked the wrong primary sentence from the Haskell homepage. The primary one below the logo is:
"An advanced, purely functional programming language"
Which again is a statement about features rather than benefits.

Vance Palacio

Just to chime in further, theres been many different reasons stated for why Haskell hasn't seen as much success as it should - I feel like there's sort of a greater theme emerging here in a sense.

Haskell is a hard to learn language, the learning resources for it are lacking, the UX/tooling is not great, and by and large, not many really understand the benefits it provides.

I think all of these attributes combine to make Haskell feel like beta software. The overall quality of Haskell isn't inspiring confidence among business owners and engineers. No one wants to invest in a painfully difficult language with no blatently clear benefits just to see it disappear.
Sure the language itself is quite mature, but it's presentation doesn't say that.

I know it's probably not the most clear cut solution, but it seems to me that we really need to ban together as a community to attack all of these pain points. Maybe no one thing is the clear bottle neck but everything together as a whole. More efforts like the ghcide + hie project merging is what we need to see

Sridhar Ratnakumar

@Hazem Would you consider posting these thoughts in https://discourse.haskell.org/ and even perhaps offer to improve the haskell.org website? Does the Haskell committee take in contributions and discuss ideas like this? I too thought the same as you about the website. It is a little too jargony to attract new programmers. (By the way, I posted this thread to r/haskell).

A place for all discussions related to Haskell
Sridhar Ratnakumar

Actually right below the website it reads "Got changes to contribute to the site? Fork or comment on Github" with a link to https://github.com/haskell-infra/www.haskell.org/

www.haskell.org site source. Contribute to haskell-infra/www.haskell.org development by creating an account on GitHub.
TheMatten

BTW I think @Emily Pillmore mentioned on Slack that team managing common Haskell infrastructure (specifically Hackage) would welcome contributions

gilmi

This discussion inspired me to write a bit about Haskell as a practical language and good use cases for it.

This is another something that I feel isn't communicated too well to beginners and onlookers, which might leave them with the impression that Haskell is just a pretty face.

Sridhar Ratnakumar

@gilmi I'd love to add your content to the Haskell Zettelkasten, specifically as a zettel or as multiple zettels to be used from this place: https://haskell.zettel.page/2012503.html

gilmi

@Sridhar Ratnakumar sure go right ahead. This is the link to the blog post: https://gilmi.me/blog/post/2020/04/28/consider-haskell

Sridhar Ratnakumar

By the way, if you guys want a publicly accessible permalink to this conversation, for use in your blog posts and what not, it is: https://funprog.srid.ca/videochat/growing-the-haskell-community.html

I think most of us here agree that Haskell is great. We can also probably agree that the world would be a better place if Haskells becomes more popular. But Haskell is currently #41 per the TIOBE Index: https://www.tiobe.com/tiobe-index/ It is ranking below languages like Rust (#27), Scala (#28), LI
Simon Michael

Thanks for linking the transcript on Reddit. Just FYI https://haskellcosm.com is a good haskell-in-industry list that I think was not mentioned.

Sandy Maguire

@Hazem excellent post, thanks for writing it up

Hazem

@Simon Michael I was not aware of this link. Thanks a lot for sharing!

@Sridhar Ratnakumar I personally prefer participating on Zulip but I think it's good for the topic to be discussed everywhere. As for submitting a PR to update the website, I think it's too early. It will probably backfire to strongly advertise the promised benefits of Haskell on the homepage without supporting these claims with practical educational resources that clearly demonstrate (to newcomers) those benefits in the context of production-ready applications.

What we should avoid is making promises that seem too good to be true, then ending up with frustrated newcomers who didn't find great resources to see those benefits in action. This will really hurt adoption.

I will submit a PR once such learning resources are available. I'm currently exploring what I can do about this issue (learning resources) and these discussions have been really great in guiding the process. :heart:

gilmi

What we should avoid is making promises that seem too good to be true, then ending up with frustrated newcomers who didn't find great resources to see those benefits in action. This will really hurt adoption.

This. I think there's too much hype and the learning resources we currently have usually don't get to the point quickly if at all.
One of the better resources in terms of approach and pacing is in my opinion cs240h, but it still leaves a lot to be desired as well.

James King

I've tried to bring Haskell into a small company twice and it has mostly failed.

The first time I was asked to prototype and jump start a greenfield project. The project was a system to manage custom forms and workflows used in food and drug manufacturing: software regulated by the FDA Part 11 in the US and ISO (I think? I can't remember exactly) Annex 14 in EU. I felt like prototyping in Haskell to work out some ideas I had around FRP and event sourcing. When I was discussing my results with a senior colleague they asked, "Why not just do the project in Haskell?"

So I made the case to the business stakeholders and they agreed. I hired a colleague from outside the company with experience writing serious amounts of Haskell to help me teach engineers and get the project off the ground. I put out a fairly popular job ad on reddit and elsewhere. I spoke at a local university about our use of Haskell. I started building a team.

However early on before all of that got off the ground there was another engineer at our company who was dubious of my choice to use Haskell for the project. He felt that I wasn't experienced enough with it, that nobody else at the company knew Haskell, that it would be hard to hire for... that it was too risky. I should choose a stack that is more tried and true.

A few months into the project and for many reasons there were plenty of roadblocks in my way. The business owners changed their minds about allowing me to hire remotely. We were given an arbitrary deadline and were asking for more time on our roadmap. We spent a little too much of the novelty budget and tried to implement a GraphQL API and were grinding our wheels on getting it to work well. We were making good progress but people were worried we weren't going fast enough.

Our unimpressed engineer, with the best of intentions and watching from the sidelines, heroically spent their free time implementing their own solution in Rails. I felt like I couldn't keep it from the light of day so we met with the stakeholders and his project was chosen to go ahead and mine was put in the ground. I had to fire my colleagues, turn down someone whom I was about to send an offer to, and archive all that work.

Undeterred I found another opportunity for a project where I felt like Haskell was a good fit. We have a size-able document database with entirely schema-less data from our applications. The applications have been around for almost a decade and have changed the format over time as errors were found, features added, and features removed. Unsurprisingly our customers, as we grew, were requesting access to this data to integrate it with their other software systems. This is the project I've been working on to this day.

I started by writing code that would safely parse this unstructured data and format it into a consistently structured format. I had started parsing these documents using Haskell as a side project for another idea I had so when this project came along I conveniently had enough code to carry it forward. With the help of Sandy we wrote a nice library to help with migrating types and I put it through the ringer on this project. It's good stuff.

Learning from my mistake in the past I decided to grow the team that would support this code internally. I started a group to teach Haskell from the first project and carried that onward. I taught a more structured course, invited more people to join, and started doing talks in the local developer community.

While this project was wildly successful in my opinion it failed in one key way: I'm still the only Haskell developer at our company. Interest and attendance in my Haskell learning group has dwindled and died out. I'm in the process of ensuring it is well-documented in the case where I'll be asked to port it/rewrite it in another language.

@Sandy Maguire mentioned that we need to get founders and first engineers to choose Haskell. In my experience so far it is quite difficult to convince an existing software team to choose Haskell. Network effects and switching costs being what they are I think it's quite rare for a company to move to a new language and ecosystem and they tend to stick with what they know. I agree that we need companies to choose Haskell from the beginning.

Tools and developer experience are great but the reason why many language ecosystems have better ones than Haskell is because companies like Microsoft, Oracle, and Google can spend hundreds of millions of dollars employing teams of experienced, full-time developers to build the best DX. For them it's a platform game. We can and do provide a rather decent set of tools: the language itself is really damn good and while learning it was hard I'm convinced it's the best language and ecosystem I've experienced in a long time.

But I don't think Haskell jobs are going to start appearing unless we start Haskell companies and hire developers and teach them Haskell.

The other approach is the killer app approach... but I don't think you can plan for that one. Rails is what made Ruby popular over night. However it wasn't because Rails was special: there were numerous such frameworks in more popular languages at the time. There is some amount of luck involved: early adopters that are socially influential, features in the framework that make it attractive in the context of competition, people just being tired of the same old and wanting to try something novel and new. You can't really start a project and say, "Okay this is going to be our killer app that will break Haskell into the industry!" They didn't start Rails that way.

Otherwise you need a war chest. Metric tonnes of cash to market and seduce developers into choosing Haskell. This is what Oracle did in the mid-90s. 500M or so? It was unheard of. But it was everywhere. Spend enough money and you can make Haskell appear like the next big thing.

The cheapest option, I think, is to start a company. Choose to use Haskell. Write about it. Talk about it. And if enough companies choose Haskell and someone makes it and gets big then we'll start to see bumps in adoption, more jobs, and more engineers trying to convince their teams to adopt it.

James King

Growing a Community is definitely something I think we do well on. I've been trying to do my part by talking about Haskell to an audience of mostly non-Haskell developers, I write about Haskell where I can, I teach as often as I can, etc.

gilmi

Thank you for sharing your story! It makes a lot of sense to me.

gilmi

It does seem to me like the Haskell learning user experience affected your ability to adopt Haskell in these scenarios though. If getting started with and learning Haskell was easier, you might not have needed to invest as much in training others, and might make it easier to convince skeptics.

I think that if "hire a new competent developer, buy them a book about Haskell, give them a couple of weeks and expect them to be able to get into and start maintaining a moderately sized somewhat well documented project" story doesn't sound like a realistic scenario, we have a problem.

James King

If there is a blessed path it might help. In my experience both learning and teaching I think most developers will need more than two weeks and a good book to get ready to maintain a production-ready Haskell application on their own.

I think if you have an established project with an experienced lead it is straight forward to incorporate less-experienced developers new to Haskell. A code style guide, hlint, continuous integration, and code review go a long way to keeping the code base safe and healthy.

Sandy Maguire

i have found teams can get new people up to speed _very quickly_ if you have a strong lead who has time to teach

Sandy Maguire

a big chunk of why learning hs is hard is that there aren't a lot of great options for quickly asking "i'm stuck on this super small problem, help"

Vance Palacio

I have a couple of "learning article" types of things on Haskell/purescript in a gasp private repo on gitlab. Private cuz I'm not sure if they're really good enough to see the light of day lol.

I can share them here and see what you guys think and if yall think it's worth the effort of writing more. I wrote them with the focus of being very succinct and pragmatic

Vance Palacio

I also wrote them from the perspective of a beginner. Hopefully I'm avoiding the curse of knowledge via the fact that I'm pretty beginner level

Sandy Maguire

nothing should have to suffer in a dingy private repo!!

Vance Palacio

Haha kk cool I'll open it up and post a link

Vance Palacio

Alright here it is: https://gitlab.com/vanceism7/learnbyexample

These little articles are in a bit of a rough-draft form, but im open to comments/suggestions/fixes. I've also blurred the lines a little bit between haskell and purescript - ill try to clean up these issues as I have time

A set of reference guides aiming to teach concepts quickly through terse descriptions with lots of examples
Samuel Glogger

@Hazem just wanted to touch on something that you said in the first post
I think people that are not that confident in the language feel a lot more comfortable going into an online meeting than into an actual meetup
For me it was the case, and I think that welcoming new people through online "events" or meetings takes a lot of the anxieties away as one might have discomfort engaging a, to them completely, unknown group. And of course the detachment from location makes it a lot easier for everyone to engage with the community

Hazem

Serokell recently posted a great article relevant to this discussion:
https://serokell.io/blog/10-reasons-to-use-haskell

Haskell is a blend of cutting edge research and well-tested, time-proven technology. Here are 10 reasons why you should use it for your next project.
Bolt

I really really liked this post!

Sridhar Ratnakumar

Strange beliefs like this hinder Haskell's progress?

The reason why Ocaml and Haskell are relatively verbose [compared to Go] is that in order to achieve maximum performance one must write code in a decidedly unidiomatic style. https://hackerweb.app/#/item/23039980

Sridhar Ratnakumar

I never once thought Haskell to be 'verbose' (compared to the languages I've used -- C, Python, Go, Clojure, Elixir, ..) - so coming across an outside evaluation like this feels strange.

TheMatten

:joy: - language ideal for building DSLs considered verbose - did that person actually ever written anything in Haskell?

Sridhar Ratnakumar

It makes me think that there are two kinds (not just one) of things hindering Haskell's adoption:

  • "Boring Haskell" / lack of materials/ etc.
  • Misconceptions of Haskell in general.

The later is probably more influencing (someone once said to me "I'll learn Haskell when Im ready to accept god back into my life").

Fintan Halpenny

Praise the Lord Curry :raised_hands:

Hazem

Seems relevant:
https://conf.researchr.org/details/icse-2020/icse-2020-papers/61/Here-We-Go-Again-Why-Is-It-Difficult-for-Developers-to-Learn-Another-Programming-Lan

(I haven't read it yet)

ICSE is the premier forum for presenting and discussing the most recent and significant technical research contributions in the field of Software Engineering. We invite high quality submissions of technical research papers describing original and unpublished results of software engineering research. We welcome submissions addressing topics across the full spectrum of Software Engineering.
Vance Palacio

Yea, the majority of programmers I know are aware of Haskell and functional programming, they just don't think it's worth the effort to learn

Sridhar Ratnakumar

I was one of them. But then one day I smoked some Elm ... and here I'm.

tristanC

This LambdaConf keynote gives another perspective using economical arguments, starting at 51' the author gives tips to demonstrate FP: YouTube - Michael Snoyman- Economic Argument for Functional Programming- λC 20 Global Edition

Sridhar Ratnakumar

Haskell and Scala community have been the most hostile communities I have experienced https://news.ycombinator.com/item?id=23362648

lolwut

Sridhar Ratnakumar

some of the most upsetting conversations I’ve had with Haskellers revolved around simple things like exceptions and logging. Issues would consistently turn into a matter of personal intelligence, and proving oneself correct. It is insane.

The more I read messages like this the more I'm getting convinced that whatever animosity being mentioned is not coming from Haskell community.

Sridhar Ratnakumar

I would like to see these criticasters give one real-world example of their observations. I'm pretty sure they can't.

Sridhar Ratnakumar

check out the dude explaining how it's great that new people won't use haskell because they're probably "unskilled". What kind of attitude is this? It's shameful.

Sridhar Ratnakumar

Actually read the comment, and see for yourself.

Sridhar Ratnakumar

My gut feeling tells me that this (blaming the entire community for some bad experiences) is not a reason why people don't use Haskell in large numbers. Speaking personally I stayed away from Haskell all these years for reasons like these (from a HN comment):

It read like a series of math equations, with frequent single letter variable names. It was concise and elegant in it's own way, but hard to follow in some cases due the lack of readable variable names.

(Which was just my own limiting belief)

Sridhar Ratnakumar

The question then becomes how do we address people's limiting beliefs of Haskell?

Hazem

The question then becomes how do we address people's limiting beliefs of Haskell?

I think the solution is to show outsiders how practical things get done in the subset of Haskell required for practical tasks, and avoiding upfront discussions about the not-strictly-necessary fancy stuff in Haskell.

Perhaps in a similar fashion to how the creator of Rails demonstrated it here:
YouTube - Ruby on Rails demo

Rails can be used for many things, but the author showed a simple practical task: creating a basic blog engine in 15 minutes.

Comparing a framework demo (blog engine in Rails) to a language demo (Haskell) is not exactly right, I know. But back when Rails was new, I imagine it was great to have demos like that, so you can quickly point to them if you wanted to convince someone to give Rails a try. I'm also willing to bet a lot of people got into Ruby after learning about Rails, through demos like that.

I'm specifically referring to the aspect of quick demonstration/proof of practical utility. If we have a bunch of 15..30 minute presentations about Haskell, with this goal in mind, it would help a lot.

Personally I'd focus on these 3 goals to help with adoption / addressing limiting beliefs of Haskell:

  1. Making demos / learning material as described above
  2. Improving the docs, especially for commonly used things
  3. Improving the Haskell homepage to emphasize the benefits of Haskell (as discussed before), but only after #1 and #2 are completed, and not before then.
Sridhar Ratnakumar

Totally with you on that. It would also be a lot of fun to focus on these positive, attractive things. If we believe Haskell is great, we should also be able to demonstrate it (via demos, materials, docs, etc.).

Vance Palacio

I posted a question in general (that hasn't seen much love :frown:) about what types of concepts we should give examples of in order that someone could be initially productive in a language. I plan to write out some quick example files demonstrating this stuff in Haskell.

Here's a link to my repo with basic ideas I've had. I'm open to more ideas of things people consider essential!

https://gitlab.com/vanceism7/learnbyexample/-/blob/master/guides/Languages/README.md

A set of reference guides aiming to teach concepts quickly through terse descriptions with lots of examples
Hazem

@Vance Palacio I think the tasks described in this talk are a good start:
YouTube - Compose :: Melbourne 2017 - Andrew McCluskey - Your first Haskell app
See 2:11 in the linked video

Hazem

and this is the repo for the talk: https://github.com/qfpl/parley

Beginner friendly demo of a blog comments app. Contribute to qfpl/parley development by creating an account on GitHub.
Sridhar Ratnakumar

https://ziverge.zoom.us/webinar/register/8415901771076/WN_xCxl4oT_TsKoi7Ygw7uivg

Speaker: Phillip Carter Functional Programming (FP) is an emerging mainstream in the software development world. However, the success of FP has come not from programming languages, but frameworks. React - the dominant framework for building web apps today - emphasizes immutability and composing smaller functional components to build a UI. Spark emphasizes immutable data transformations and treats functions as first-class concepts (e.g., UDFs). In machine learning, research is moving towards higher-order derivatives with functional programming - such as Google JAX - because the defaults for FP are more flexible and expressive. There are many more examples that you have likely encountered in some form. And while this could be seen as cause for celebration, something is off. Haskell, Scala, F#, OCAML, Clojure, and other beloved programming languages are still seen as niche in working environments. You can utilize functional programming concepts in your daily work, but not always in a functional language. There is no shortage of fascinating and useful concepts, libraries, and tools that occupy these languages' ecosystems, but they have all seen little adoption in the broader programming community. This talk will cover the framing that was previously mentioned and offer hypotheses about how FP languages can rise in adoption without abandoning all the things that make them so great. Topics discussed include editor tooling, debuggers, profiling and analysis tools, scripting and visualization, library design, and library ecosystem focus. Every FP language has strengths in some areas over others, but all have objective deficiencies when compared to mainstream programming languages like Java, JavaScript, C++, C#, and so on. But not all is lost! There are some novel concepts, libraries, and tools in FP language ecosystems that could propel the use of FP languages if some deficiencies are addressed. This is the central proposition of this talk.
Sridhar Ratnakumar

Functional programming; if you're new to this, start with Clojure, not one of the less-practical languages. This has made such a huge impact on the way I think about code, write code, and design code that it's possibly the biggest one here for me.

And then Elm, and then Haskell. https://hackerweb.app/#/item/23468193

Sridhar Ratnakumar

(Implying that Haskell is 'less practical' - but maybe that's how we lure them!)

TheMatten

I would say there's a relatively big difference between Lisps and ML-style languages - maybe they could just start with Elm if they should move into Haskell at some point - or something like OCaml/F#?

James King

I'm trying to pull together some content to start streaming some Haskell development. I see people say things that suggest, "Haskell isn't practical for real-world use," and I just want to show them that even a dummy like me can write software with it and not be a an academic researcher with a PhD and a paper to present. </rant>

James King

I'm just trying to get over the shyness of starting a stream doing Haskell programming and the audience that I imagine will tell me how I'm doing it all wrong. :joy:

Bolt

Go for it man! I wish I had a powerful enough setup to do some streaming! :P

TheMatten

That would be cool! There'll always be some /r/iamverysmart people, but I think many would appreciate such content :slight_smile:

James King

Thanks -- it's the kind of content I want to see more of but don't find a lot of. I hope it will inspire people to consider Haskell... and grow the community. :)

Hazem

I'm just trying to get over the shyness of starting a stream doing Haskell programming and the audience that I imagine will tell me how I'm doing it all wrong

I'm planning to do something similar in the future. Partly due to the the issue you mentioned, I plan to avoid the live streaming format. Instead, I'll hopefully follow a format similar to the one in https://www.destroyallsoftware.com/screencasts

I'll probably do what he did: no comment section, no live streams. For feedback, contacting the author directly is the best approach. Comment sections tend to lead to flame wars sometimes (at least in cases where there are multiple ways to do something, which is very common in Haskell)

James King

Those screencasts are great!

Hazem

Those screencasts are great!

Absolutely! The "From Scratch" series is something I'm hoping to emulate in Haskell

James King

The reason I want to go with the live format is because I want to show people the process of working with Haskell and not knowing 100% what you're doing and how to figure it out.:)

James King

I hope showing me fumbling around and working it out will demonstrate that Haskell is useful for industrial users :smiley:

Hazem

The reason I want to go with the live format is because I want to show people the process of working with Haskell and not knowing 100% what you're doing and how to figure it out.:slight_smile:

There is a lot of value in that too!

Hazem

I hope showing me fumbling around and working it out will demonstrate that Haskell is useful for industrial users :smiley:

If I attempted something similar, I think I'll end up pushing people away from Haskell hahaha

James King

Hazem said:

If I attempted something similar, I think I'll end up pushing people away from Haskell hahaha

That's sort of what I'm worried about: will the Haskell marketing squad come out and tell me I'm pushing bad practices and making Haskell look bad? I dunno. Maybe I don't really know what I'm doing and I shouldn't be programming :shrug: and shouldn't be streaming.

James King

But hopefully I will also learn stuff!

James King

You never know until you try. I just have to get a decent development environment setup on Windows because that's what my streaming setup supports the best.

Georgi Lyubenov // googleson78

in the end it's you programming, and not the people in the chat - if they want to do it another way they can fire up an editor and do so :)

Georgi Lyubenov // googleson78

I think the harder part is being active on a stream while also thinking about your problem actively (for me at least) - especially when there is not an active chat to ask stuff

James King

That will definitely be a challenge and a skill I'd like to improve. Being able to think aloud. I'm very much a slow, patient programmer who spends a lot of time writing and humming and hawing. :)

Sridhar Ratnakumar

Related to this topic?

https://commoncog.com/blog/tacit-knowledge-is-a-real-thing/

What tacit knowledge is, and why it is the most interesting topic in the study of expertise today.
gilmi

@James King I'm interested in watching your stream and coincidentally am also working on exactly the same thing. Maybe you'd like to talk and compare notes?

James King

That would be dope. I thought it might be fun to have guests come on and do some pair programming as well at some point. :thinking:

Sandy Maguire

just dive in on the streaming front

Sandy Maguire

you can set it up in 15 minutes

Sridhar Ratnakumar

Orange wisdom:

Maybe developers stop learning because they realize that that to learn how to do the same thing with 167 technologies is not a real development https://hackerweb.app/#/item/23767438

Is Haskell one of those 167 technologies?

James King

I don't think so. I learned it. A bunch of us on here learned it. More people continue to learn it.

James King

There's nothing wrong, in my opinion, with not wanting to learn new things. Learning is an exhausting process and requires a large investment in time and energy.

James King

Which also means that I don't think the Dunning-Kruger effect or "expert beginner" are fair things to measure one's sense of competence and progress by.

James King

Although I do think that the amount of things that programmers are asked to learn about continues to grow and that itself can also be exhausting.

James King

Most lawyers and doctors get paid to go to conferences, take courses, and read papers. That's still fairly rare for programmers.

James King

Doctors and lawyers get to do that as part of their professional obligations. We have to do it on our own time/budget for the most part.

TheMatten

Is Haskell one of those 167 technologies?

Maybe Haskell-language is, but not Haskell-mindset - we may will not program in Haskell at some point in our life anymore, but I'm pretty sure that at least in my case, ideas I've learned there will greatly shape the way I write code

Sridhar Ratnakumar

we may will not program in Haskell at some point in our life anymore

Pray tell me that's not because we will be moving back to Go!

Sridhar Ratnakumar

if I'm ever going "back", it will be because of a combination of other factors: market, life, etc.

Sridhar Ratnakumar

I can't imagine what it would be like to go back to writing Python again. But it certainly would be less distressing (not because of Haskell, but because of having psychologically progressed).

James King

Pry it from my cold, dead hands. :stuck_out_tongue_wink:

TheMatten

Pray tell me that's not because we will be moving back to Go!

I was actually imagining some Haskell successor, but who knows :sweat_smile:

James King

Haskell 2 :sweat_smile:

Bolt

Haskell 2020 eheh

Ahmad Abdelwahed

Sridhar Ratnakumar said:

if I'm ever going "back", it will be because of a combination of other factors: market, life, etc.

If you want to consider market as a factor so you shouldn't rule out -ahem- Java

Sridhar Ratnakumar

Is Haskell not for "average programmers"?

Go is a language designed for software engineering in the large. At scale, there are no good or bad programmers, there are only average programmers, by definition.

https://lobste.rs/s/3npaqq/why_go_s_error_handling_is_awesome#c_8rs0iz

Sridhar Ratnakumar

(You gotta expand a downvoted-comment to get to this one)

James King

I wouldn't call myself above average. I program in Haskell. I'm happy with it.

Sridhar Ratnakumar

A sibling comment mentions FizzBuzz and Haskell in the same paragraph :big_smile:

Sridhar Ratnakumar

You know what? I failed once in FizzBuzz (it was an interview question; never heard from them again).

James King

Also, is Rust really a mainstream language? I was under the impression there are about as many Rust jobs as there are Haskell ones. :thinking:

Sridhar Ratnakumar

(IIRC, my first and second code was buggy, had it get it right on third attempt of them pointing it out lol)

Sridhar Ratnakumar

Another sibling comment talks about "class dysphoria or class chauvinism" ... whoa what buddy??

Sridhar Ratnakumar

programminglanguageidentitypolitics.jpg

Sridhar Ratnakumar

I believe Haskell is appropriate for "the unwashed masses", if universities weren't busy unconsciously indoctrinating (using this harsh word only to make a point) them with the imperative mindsets of Java/C++/Python

James King

It's a fine language. That's why I'm kicking the tires on my stream. Just writing Haskell. Building stuff I don't get to build in my day job. Having fun.

Sridhar Ratnakumar

Anyway, I'm referencing comments of this ilk only to illustrate the various attitudes/ beliefs that underlie the master belief that "haskell is difficult/ strange/ academic/ whatever"

Sridhar Ratnakumar

And if we are to 'market' ourselves better (by rewriting haskell.org etc), we should keep these beliefs/ attitudes in mind.

James King

That's what my stream is all about! Just building stuff and trying my best to shrug off this myth that Haskell is a research language or something.

James King

I'm not a researcher. Didn't go to university. I haven't even built a production-quality database from scratch before. But heck, do hard things and learn stuff. Preferably in Haskell.

Sridhar Ratnakumar

I hope that in 20 years from now (asssuming FP becomes wide-spread by then!), we will look at Go like we look at COBOL and Fortran today. :grinning_face_with_smiling_eyes:

James King

There will be Go spinoffs by then.

James King

C will probably still be around.

Will

just wanted to corroborate your comment about universities, @Sridhar Ratnakumar. i'm a relatively recent CS grad (2018) and can tell you that FP in the core curriculum at my school was relegated to just a few weeks of scheme in a "programming paradigms" course and map/filter/reduce in python for a systems programming class. the only FP elective i ever saw offered was only available at the dublin campus and ended up being cancelled anyway :upside_down:

Sridhar Ratnakumar
James King

I agree with that. It's a universal truth: you have to be receptive and willing. Learning is hard, and requires a significant amount of calories to be burned in the effort. You need a reason to motivate you through the effort.