Growing the Haskell Community - Haskell

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.

Sridhar Ratnakumar

haskell 50% not bad https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved

Nearly 65,000 took this comprehensive, annual survey of people who code. Demographics. Most loved, dreaded and wanted technologies. Salary and careers.
Vance Palacio

Haha cuz the 50% who want it already have it :stuck_out_tongue_closed_eyes:

TheMatten

I wonder how many of those in "dreaded" category are students that had bad experience learning it at uni

Sridhar Ratnakumar

Go, once again!

map/filter and sum types are not about "fun", they're about correctness and expressiveness.
map/filter and their equivalent loops are both perfectly readable, but the latter involves more boilerplate.

https://news.ycombinator.com/item?id=24296402

Sridhar Ratnakumar

that approximately no one is more productive in Haskell than Go seems easy to conclude from looking at what’s produced by each community.

LOL https://lobste.rs/s/zgwjpg/go_vs_rust_for_back_end_development#c_bbfccs

Sridhar Ratnakumar

Here's your opportunity to grow the Haskell community, by dispelling twisted beliefs and myths.

Torsten Schmits

I think you posted to the wrong stream!

Torsten Schmits

and do you really think it is effective to engage with such statements?

TheMatten

Torsten Schmits said:

I think you posted to the wrong stream!

I would say trying to tackle strange preconceptions about HS counts as growing it's community

Torsten Schmits said:

and do you really think it is effective to engage with such statements?

Well, that's a good question - that specific person to which Srid or someone else could respond is probably not going to change opinion, but maybe it could be useful to other people trying to get some image about language from online discussion (not saying that's a good way to get an idea though :big_smile: )

Torsten Schmits

well it's the VideoChat stream

Torsten Schmits

TheMatten said:

strange preconceptions about HS

is that really a preconception? it seems more like a logical error to me. the Go community is probably much larger.

Notification Bot

This topic was moved here from #VideoChat > Growing the Haskell Community by Sridhar Ratnakumar

Sridhar Ratnakumar

is that really a preconception? it seems more like a logical error to me

I use the word "[false] belief". Basically conceptions that are not factual. And they are very common in the wild out there, about Haskell. My stance is that as long as these false beliefs remain widespread, Haskell will remain a niche.

Torsten Schmits

then it seems to me that in order to elucidate this false belief, you would have to prove the numbers of projects in relation to the magnitudes of the communities, given that they are talking about "productivity"

tristanC

I wonder how do you approximate productivity by looking at what is produced. Is there some existing resources that look at how things are produced instead, for example by studying change histories or the issue trackers?

Torsten Schmits

and then probably some qualitative measure due to the presence of abstraction in haskell

Torsten Schmits

which all should probably converge to some subjective disagreement

Sridhar Ratnakumar

You can't prove without doing carefully controlled doing studies. We can only argue based on subjective experiences. The comment that person was responding to was mine, where I detailed my progression through all these languages -- thereby having an unique experience in this matter -- before concluding that Haskell does make me more productive, in the end.

The retort was "Maybe you’re an exception". I'd think that this disbelief arises from that person's false belief about Haskell's worth/usefulness; they don't say it upfront, and instead tries to buttress their disbelief by going on a tangent about programming language popularity (nevermind that popularity is nothing to do with productivity), via their somewhat-affective allusion to "looking at what’s produced by each community" - but this is a different "production" which is more a factor of popularity than language producvity (the latter is what my comment, as well as the parent comment, was talking about).

You can't compare a community with 1000 Go programmers, and another community with 30 Haskell programmers, and then conclude that the former is more "productive".

Sridhar Ratnakumar

And when measuring productivity, you must do that at all stages of the project. Not just initial "monkey coding" phase of churning out cool features. But also during middle phase of adding features or changes without breaking the then significantly grown existing code, as well as the later maintenance phase. I wouldn't be surprised if the likes of Go do well in the initial phases, but not as much in later phases. (Python would be even worse)

Sridhar Ratnakumar

Some Haskell companies -- like Obsidian in this screenshot -- openly claim that Haskell is an essential ingredient in their productivity (compared to competitors).

image.png

Torsten Schmits

so are you gonna post this in the lobster thread?

Sridhar Ratnakumar

Probably not, I'm very likely to offend the commenter :-P I might get to posting it to my website notes, though (where I generally collect instances like this, eg: https://www.srid.ca/852310bb.html )

Joel McCracken

well there ARE some beliefs out there about haskell that are actually trivially proven to be non-factual

Joel McCracken

For example I rememer hearing someone say on a podcast that in Haskell you can't log anything without changing your types even something "real quick" for development/debugging your code, which is clearly wrong, the person who said it must have never seen Debug.Trace and never asked an experienced haskeller about it

Torsten Schmits

yeah I heard that one too, ages ago

Torsten Schmits

yeah I heard that one too, ages ago

Torsten Schmits

I guess that's something that should be taught pretty early. maybe in general, how to debug stuff with unsafePerformIO

TheMatten

(I will shamelessly shove these custom tracing functions in here in style of compiler messages with code location - they've proven super useful to me for quick debugging)

Torsten Schmits

hey, I also call mine dbg :yum:

Joel McCracken

make it a package and i may use it

TheMatten

What makes me upset about state of affairs is that I have lots of little things to complain about when it comes to Haskell after using it for few years and in production, but they don't tend to match up with these arguments I see e.g. on :orange:-site - it just further makes me think that these people have no idea what they're talking about, but arguing with them once again just goes into this infinite spiral of heated misunderstandings

Torsten Schmits

TheMatten said:

I have lots of little things to complain about

so what are those?

Joel McCracken

its interesting, most of the things I compliaiend about w/ haskell before I had experience with it were actually legitimate, but ultimately mistaken in some way

Joel McCracken

like, my complaint that you could have a very minor requirement change require a massive refactor is really made less of an issue because hasekll is so, so much easier to refactor

Joel McCracken

and I really jsut couldn't comprehend that

Torsten Schmits

at some point you just realize that the compiler is your friend

TheMatten
  • lots of partial functions in base
  • string types craziness
  • problems with common string encoding functions
  • lazy IO in base (funny in simple examples, but unusable for anything serious)
  • terrible TH interface
  • underdocumented base libraries (I usually just switch to source when reaching for their less used functionality)
  • weak GUI libraries
  • underdocumented and sometimes quirky build tools (Stack is slightly better, Cabal docs need a lot of love) - but they were getting better recently, that's true
  • default IO functionality (files and stuff) seems to not have that much thought put into it's design
  • lots of (often undocumented) exceptions in base 's IO stuff
  • exceptions system itself that still doesn't have backtraces by default

and probably some other things I can't think of right now :smile:

Torsten Schmits

that looks like a pretty solid list

TheMatten

Oh,

  • IO stuff in base should use MonadIO so that we don't have to liftIO everything (PureScript does that and they're doing fine)
Torsten Schmits

at least most of those are pretty easy to fix in principle :grinning_face_with_smiling_eyes:

TheMatten

Yeah - you could technically solve bunch of these by switching to alternative prelude (which is usually more that just Prelude module)
Really, PureScript is often "Haskell done right", though not all interesting HS functionality is ported here

Torsten Schmits

I meant, fix those things in ghc

TheMatten

Yeah, that absolutely should be done :thumbs_up:

TheMatten

It's just that we don't have to "wait" (maybe that's why we're still waiting... :joy: )

Sridhar Ratnakumar

TheMatten said:

  • lots of partial functions in base
  • string types craziness
  • problems with common string encoding functions
  • lazy IO in base (funny in simple examples, but unusable for anything serious)
  • terrible TH interface
  • underdocumented base libraries (I usually just switch to source when reaching for their less used functionality)
  • weak GUI libraries
  • underdocumented and sometimes quirky build tools (Stack is slightly better, Cabal docs need a lot of love) - but they were getting better recently, that's true
  • default IO functionality (files and stuff) seems to not have that much thought put into it's design
  • lots of (often undocumented) exceptions in base 's IO stuff
  • exceptions system itself that still doesn't have backtraces by default

and probably some other things I can't think of right now :smile:

Looks like an idea for a blog post of yours? :-D Title: "Dear non-Haskeller, Haskell has problems but they are not what you think they are"

Sridhar Ratnakumar

I use relude, personally.

Alex Chapman

relude is nice. I used it in a project, but recently went back to the standard prelude. I had a few reasons for doing this:

  1. I can paste code for others and not have to explain that it's using relude,
  2. I can pull out a section of code and make it into a standalone library that doesn't depend on relude,
  3. I can keep my intuition for which things I need to import for certain functions. This is useful for when I work on projects that don't use relude, or when I read others' code.

Basically it comes down to standardisation. Often its better to do things the best way (e.g. use relude), but there are drawbacks if the best way isn't the standard way. As Haskellers I think we are inclined to do things the best way rather than the standard way (otherwise we would be javascripters), but if we spend all our time reinventing the best possible wheel then we may never get that car built.

Steven Shaw

Those are valid reasons, @Alex Chapman . Hopefully, relude will emerge as the premier "Haskell standard library".

Alex Chapman

Yes, but how will that happen if people like me won't use it because it isn't the de facto already? It needs an abrupt transition, but that requires buy-in from enough people or you get curmudgeons who just stick with the old way. I think the better way to do it is to try to gradually change the standard prelude into something more like relude, by making sensible fixes one at a time, deprecating things you want removed, but not removing them straight away.

Alex Chapman

This is why it's more fun to make new programming languages :P

Steven Shaw

One answer may be to think about it in terms of “Crossing the Chasm". See this talk:

YouTube - Gabriel Gonzalez – How to market Haskell to a mainstream programmer

Steven Shaw

I'm happy to adopt relude even if others aren't.

Steven Shaw

It looks like this talk hasn't been mentioned in this thread. It's quite relevant. Certainly one way of thinking about it.

codygman

We can't assume everyone cares about crossing the chasm though. Even if they do, there is a possibility everyone might not think a relude prelude helps cross it. I personally do, but wanted to call this out as a point of discussion.

Sridhar Ratnakumar

https://twitter.com/JoelMcCracken/status/1307005268358823937

Torsten Schmits

nah, it's just some bloke

Joel McCracken

That is me, man. Just some bloke

hackeryarn

I feel like a lot of inaccessibility boils down to communication. A lot of the Haskell community is really enthusiastic about the language and that actually scares beginners.

The few people I've helped learn Haskell often have simple questions, but most of the answers they come across don't answer them simply. For example, I really struggled to just use the do notation because every time I read into it, the topic quickly jumped into how to desugar it and the implications of that. Then I finally worked with it enough to realize that the desugarring rarely matters, and mostly I shouldn't worry too much about it . I should just use it.

I found this a repeating pattern. I struggled with it, and a couple friends that ventured to learn Haskell ran into the same problem on various topics. Most people give up if they feel like they have to understand the language that deeply, and I don't think they need to.

Take JavaScript and the weird this semantics as an example. It can have really bad implications, but most of the JS devs I worked with don't bother to understand it because it only comes up a couple times a year, and they can google for a straight forward solution. I think a lot of the Haskell nitty gritty details fall in the same category. Now you might argue that this lack of understanding is a bad thing, but I would argue that being able to get work done without the deep understanding is what makes a language accessible.

Sridhar Ratnakumar

(Thread on CLI detached to here)

Sridhar Ratnakumar

I think I see another reason why Haskell is not popular for app development. Though it is obvious in retrospect. With Go or JavaScript, programmers can get something working quickly ("monkey coding", to be honest). Not true for haskell. There is an unusual amount of investment ahead. However, once you are past the learning stage - monkey coding will splash mud water in the face. Bugs! Maintenance overhead! With Haskell, that is easy-peasy.

Another factor is the ecosystem. Cooler libraries and frameworks existing in the Go / JavaScript land.

Sridhar Ratnakumar

(There is even more painful when you enter the FRP sub-universe of Haskell)

Sridhar Ratnakumar

FRP is perfect for local reasoning, but there are costs (lack of rich ecosystem, and learning curve)

Georgi Lyubenov // googleson78

tbh I think initial setup is pretty fast with hs too, once you're familiar with the ecosystem

Georgi Lyubenov // googleson78

generics-based stuff can save you sooooo much boilerplate

Mats Rauhala

TBH, I avoid TH like the plague. I even avoid Generics to some extent. It's a bit more boilerplate, but being able to see the code explicitly helps understanding the code later. For some reason being able to read the code helps with reading the code.

Georgi Lyubenov // googleson78

to me this seems like an upfront cognitive cost vs over time continuous cost (you can spend the time to learn what the generics-based aeson instances are and not write ones yourself, or you can write them immediately, but then have to support/read them in the future)

Georgi Lyubenov // googleson78

do you avoid generic-lens (and mkLenses also I guess), aeson's Generic, optparse-generic?

Georgi Lyubenov // googleson78

actually there's also cases when it's a matter of "correctness", e.g. when using persistent or elm-street if you use the TH/Generic machinery you don't have to worry about screwing an implementation up, because then it becomes not just a matter of boilerplate, but also "getting it right"

Mats Rauhala

Hmm...

  • do you avoid generic-lens
    • yes and no. I use generic-lenses in some implementations, but I hide them behind another interface. It's a black box at that point
  • and mkLenses
    • Yes. Definitely. I won't use them. I won't let code reviews pass that use them.
  • aesons Generic
    • yes and no. I default to using the generic instances, but as soon as the default generics don't do what I want, I write the instances manually. This might include aeson-casing and generics still though. I do try to write the tripping tests + golden tests for each to make sure the instances are backwards compatible
  • optparse-generic
    • yes and no. I like this library, I use it. But as soon as you start to be out of the happy path, I'm willing to rewrite it to basic optparse-applicative

matter of "correctness"

yes. I try to not trust generics on this, unless you're on the happy path and the defaults work out of the box. As soon as you for example require modifying the field names in aeson, the "correctness" provided by generics is thrown out of the window.
I try to write even more boilerplate by writing tests for each and every aeson instance for example.

Mats Rauhala

I'm much more apprehensive of template haskell as it's too opaque.

  • it can create new functions, classes and types from nothing. It's terrible for discoverability
  • Using th/qq is difficult, as the types are usually opaque. Types are usually something like Name -> DecsQ
Georgi Lyubenov // googleson78

I was referring more to the fact that elm-street gives you types that correspond to your haskell ones and their aeson (de)serializers
and also that persistent gives you db RW access that is consistent in regards to the schema that it can also generate

whereas writing these yourself is more error-prone

Georgi Lyubenov // googleson78

I agree that initial TH experience suck, especially when there are a lot of generated names for functions/types

Georgi Lyubenov // googleson78

at least Generics solutions seem to be much more adaptable than TH when you're not "on the happy path", in my experience, especially with DerivingVia

Mats Rauhala

DerivingVia is something I'm on the fence about. It's cool. But I'm having trouble seeing why it's any better than defining your genericParseJSON <modifier>

TheMatten

@Mats Rauhala it has advantage of being able to do compile-time computation without TH using types

Mats Rauhala

Yes, of course that, but what is the benefit in that? How is you being able to say DropSuffix '_' better than dropSuffix '_'?

Mats Rauhala

Not trying argue, I just feel like I'm missing a link

TheMatten

I'm not saying aeson-deriving is necessarily better for using DerivingVia - just that there may be some legitimate use-cases
I guess one may like that specific example because it can be written as part of deriving clause in datatype definition

Georgi Lyubenov // googleson78

it's more code:

data X = X {inner :: Int}
  deriving stock Generic
  deriving (ToJSON, FromJSON) via (SingleFieldObject "outer" (GenericEncoded X))

-- vs

data X = X {inner :: Int}
  deriving stock Generic

-- so we don't accidentally mix up the field name in ToJSON vs FromJSON
outerFieldName :: String
outerFieldName = "outer"

instance FromJSON X where
  parseJSON = withObject "obj" \o -> X <$> o .: outerFieldName

instance ToJSON X where
  toJSON (X i) = object  [outerFieldName, object ["inner", toJSON i]]
Georgi Lyubenov // googleson78

(I haven't actually type-checked this)

Georgi Lyubenov // googleson78

also the instances I wrote are already written almost verbatim inside SingleFieldObject's instances
so it's just a matter of reusing already written code

Georgi Lyubenov // googleson78

I would feel much safer with the first one, whereas I would have doubts about the second one

especially if this isn't a toy example with one field and only one modification I want to make

Georgi Lyubenov // googleson78

the first one also took me ~10 seconds to write, even though this is the first time I've actually used aeson-deriving, while for the second one I had too look up some aeson docs, even though I've used it before
it's also much easier to read/reason about:

  • in the first one you immediately know FromJSON and ToJSON match, since they share an "encoding"
  • in general writing a manual instance can do whatever, so you first have to do the cognitive overhead of understanding what the implementation of the instances is, whereas using SingleObjectField hides that behind an ""abstraction"", and it can't do arbitrary things
Mats Rauhala

FromJSON and ToJSON match, since they share an encoding

Now this is a great point I can accept. One could have a similar helper function for the singlefieldobject, but you would still need to apply it to both instances separately.

Georgi Lyubenov // googleson78

well technically you can also write

  deriving ToJSON via Foo
  deriving FromJSON via Bar
Georgi Lyubenov // googleson78

but for me personally the deriving variant is harder to mess up

Mats Rauhala

But you can't write

instance (ToJSON, FromJSON) (x) where...

so, yes, while deriving via allows you to split it up, it also allows you to combine them, which is cool.

Mats Rauhala

Now I just wish I had a compiler that supported DerivingVia :shrug:

IC Rainbow

Sridhar Ratnakumar said:

I think I see another reason why Haskell is not popular for app development. Though it is obvious in retrospect. With Go or JavaScript, programmers can get something working quickly ("monkey coding", to be honest). Not true for haskell.

I see that as an issue of sprawling ecosystem. With proper libraries you can monkey-code as you please. Case in point - hackathons and jams.

Haskell ~forbids~ makes difficult only really gross things like stringly-typing everything and going at cross-course to yourself wrt. data structures. You have mutable arrays, what else do you need to splash mud? :smiley: