Growing the Haskell Community - Haskell

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!

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.

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?"

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.

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 ...

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.

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.

@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.

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

pandoc is also a good example imo

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

petit à petit, l’oiseau fait son nid

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

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.

^ These things are huge

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

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

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

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

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

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.

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.

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.

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.

Here's a concrete chance to convince a potential Haskeller: https://lobste.rs/s/hf3y19/what_s_best_functional_language_learn

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:

0. Awareness of pain points / bad ideas in mainstream languages/paradigms
1. Awareness of the FP paradigm / Haskell and its benefits
2. Learning FP -> Learning Haskell
3. Using Haskell to build something
4. 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.

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

@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).

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/

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

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.

@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

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

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

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.

@Hazem excellent post, thanks for writing it up

@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:

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.

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.

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.

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

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.

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.

this, i think ^

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

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"

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

yes please

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

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

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

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

@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

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

I really really liked this post!

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

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.

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

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").

Praise the Lord Curry :raised_hands:

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)

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

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

Note to self: relevant discussion from General VideoChat
https://funprog.zulipchat.com/#narrow/stream/234801-VideoChat/topic/General/near/196025960

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

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

lolwut

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.

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

image.png

Discussion on reddit: https://www.reddit.com/r/haskell/comments/gtm3w0/on_marketing_haskell/

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.

Actually read the comment, and see for yourself.

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)

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

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.

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.).

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

@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

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

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

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

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

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#?

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>

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:

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

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

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. :)

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)

Those screencasts are great!

Those screencasts are great!

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

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.:)

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

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!

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

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.

But hopefully I will also learn stuff!

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.

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 :)

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

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. :)

Related to this topic?

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

@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?

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:

just dive in on the streaming front

you can set it up in 15 minutes

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?

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

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.

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.

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.

One person argues for Cynicism + money: https://news.ycombinator.com/item?id=23770550

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

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.

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

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!

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

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).

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

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:

Haskell 2 :sweat_smile:

Haskell 2020 eheh

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

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

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

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

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

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

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:

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

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

programminglanguageidentitypolitics.jpg

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

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.

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"

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

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.

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.

/me just created a zettel about it https://www.srid.ca/852310bb.html

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:

There will be Go spinoffs by then.

C will probably still be around.

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:

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.

Would be cool to make tutorial videos on Haskell in Hanselman style YouTube - Windows Terminal Feature PREVIEW - Customize your keybindings, color tabs, split panes, and MORE!

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

but not 'wanted'

also 50% dreaded

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

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

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

Somewhat related, and interesting question: https://www.reddit.com/r/haskell/comments/inpxxh/are_haskell_selling_points_being_slowly_but/

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

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

I think you posted to the wrong stream!

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

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: )

well it's the VideoChat stream

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.

This topic was moved here from #VideoChat > Growing the Haskell Community by 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.

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"

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?

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

which all should probably converge to some subjective disagreement

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".

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)

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

image.png

so are you gonna post this in the lobster thread?

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 )

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

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

yeah I heard that one too, ages ago

yeah I heard that one too, ages ago

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

(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)

hey, I also call mine dbg :yum:

very cool!

make it a package and i may use it

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

TheMatten said:

I have lots of little things to complain about

so what are those?

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

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

and I really jsut couldn't comprehend that

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

• 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:

that looks like a pretty solid list

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)

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

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

I meant, fix those things in ghc

Yeah, that absolutely should be done :thumbs_up:

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

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"

I use relude, personally.

I recommend relude

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.

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

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.

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

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

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

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

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.

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

Haskell flips the difficulty of programming on its head: there is a lot more to learn, but actually using it is much less difficult. Other languages are easy to learn, but really hard to use.

- Some Bloke (@JoelMcCracken)

Oh hey, it is by Joel.

Back in full circle hehe

:laughing:

nah, it's just some bloke

That is me, man. Just some bloke

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.

(Thread on CLI detached to here)

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.

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

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

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

generics-based stuff can save you sooooo much boilerplate

(and TH too I guess)

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.

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)

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

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"

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.

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

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

in the "correctness" department

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

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

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>

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

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

https://hackage.haskell.org/package/aeson-deriving

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

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

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]]

(I haven't actually type-checked this)

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

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

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

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.

well technically you can also write

  deriving ToJSON via Foo
  deriving FromJSON via Bar

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

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.

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

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:

lol

https://twitter.com/lexi_lambda/status/1325533536896643078

https://twitter.com/lexi_lambda/status/1325533536896643078/photo/1

- Alexis King (@lexi_lambda)

[citation needed]
(Where is it from?)

2020-11-08-224717_447x199_scrot.png

Wow

Oh I can write quick and dirty Haskell. Just watch my stream.

Orange site: Haskell is a Bad Programming Language (2020)

https://hackerweb.app/#/item/25699574

I wonder what people get out of spreading FUD about non-mainstream programming languages ^^

Functors are basically an Object with a internal state changing method in typical OOP terms.
Haskell doesn’t suck because it does not have enough libraries, it sucks because working with other languages is a horrifying experience given that so many tricks are needed to make GHCJS
Abstractions with types is a bad type of abstraction because it ignores the basic fact that programs deal with data, and data has no types.

100% agree

I find the "data has no types" argument hilarious

I can make the same argument in favour of using turing machines for real programming and Strings as the only data structure

I'll show you my internal state changing method

I guess Bertrand Russell et al. were all wrong about set theory and propositions as types

No. 1 in lobste.rs. Here's your opportunity to advertise Haskell:

https://lobste.rs/s/yiwg7l/reflections_on_using_haskell_for_my

@Sridhar Ratnakumar great article

Sridhar Ratnakumar said:

No. 1 in lobste.rs. Here's your opportunity to advertise Haskell:

https://lobste.rs/s/yiwg7l/reflections_on_using_haskell_for_my

Hi :wave: I'm the author of the article.

I thought I might respond to some of the comments, but seems you need to be invited to lobste.rs?

Would someone mind inviting me? afburrowes AT the google email service you know the one ;)

Georgi Lyubenov // googleson78 said:

I can make the same argument in favour of using turing machines for real programming and Strings as the only data structure

That is basically bash.

I'm showing Haskell to my coworkers in my company to raise interest in the language. However I don't know how to address some concerns coming from the lack of mainstream usage of Haskell, do you know if there is an efficient answer ?
Someone told me that Haskell is a research language and isn't production ready. Another colleague told me that being purely functional is way too extrem and that it's better to have the "best of the 2 worlds" and mixing functional and imperative traits.

So far I didn't show them functor or monad so they may not yet see how things can scale but I'm not sure what kind of answer can I bring.

I mean being research langage or production ready is a bit subjective in my opinion

Haskell is being used at GitHub and Facebook, not sure how much more "production ready" someone needs.

Someone told me that Haskell is a research language and isn't production ready.

People use it in production, I use it in production, so I guess it's production ready - we should not pretend though that it can solve any problem easily just bi virtue of being a good language. You need to make sure that it has libraries and tools you need for your domain - if it's server-side web dev, or compilers, or CLI tools etc., then it should work fairly well, but if you want to work with some specific complex API of some service, or write web apps, then you may find less production-ready tools and more "research" stuff

in my case it's rather for CLI tools

purely functional is way too extrem and that it's better to have the "best of the 2 worlds"

Honestly, that's like saying that we don't use IO in Haskell - purity doesn't mean that you don't have imperative tools, it's that you build them from first principles instead of working with implicit context in every part of your application - and surprisingly, that's a very practical concern, once you start working with stuff like concurrency

currently we have python tool, but sometimes it break because of typo. Plus people are not always confortable modifying the code

CLI tools work well - see e.g. Aura package manager for Arch Linux

do we know how it's used in Facebook/github ?

https://github.com/github/semantic

thank you !

I have seen a Facebook guy mention Haskell on a talk on YT, but that was years ago and I don't have the link anymore.

And Facebook has some spam-battling system that uses it - I think they mentioned that it let's them do quick, regular updates with confidence

They actually have system that can dynamically reload updated parts of it

thank you !

TheMatten said:

And Facebook has some spam-battling system that uses it - I think they mentioned that it let's them do quick, regular updates with confidence

Yes, this is what was being discussed on that talk.

Vincent L said:

in my case it's rather for CLI tools

pandoc and neuron are CLI tools written in haskell.

Vincent L said:

Another colleague told me that being purely functional is way too extrem and that it's better to have the "best of the 2 worlds" and mixing functional and imperative traits.

to me, this is one of those "doesn't even make sense" arguments. you don't get a lot of benefits of being purely functional if you don't use it everywhere you possibly can. haskell is an excellent imperative language -- side-effecting actions are first-class, it's easy to use concurrency correctly and compiled performance is totally reasonable.

in the past, I've had success steering the conversation around Haskell away from random myths my coworkers read on Hacker News 5 years ago towards "what are the strengths and weaknesses compared to our other options, and what are our requirements for our language / platform?" e.g. "Purely functional is 'way too extreme'" "Interesting -- what makes you say that? Too extreme for what purpose?"

I often find the myths fall apart pretty fast if I ask genuine questions to understand where someone's opinion on the language comes from

Vincent L said:

do we know how it's used in Facebook/github ?

Perhaps this YouTube - 06 Fighting spam with haskell at Facebook will be of help :)

Some of my colleague said they don't think they would be able to maintain Haskell code. Is there a "success story" of people having learnt Haskell faster like, let's say Python or C++ ?

Hmm, that sounds like two different concerns to me - I don't think that it's harder to maintain normal HS codebase given you understand the language, but there may be smaller amount of good learning resources and they're less coherent

“Pure” functional programming along with OO is theological in nature, faith driven, derives its elitism from childish notions of “purity” and has no evidence for all its claims.

https://lobste.rs/s/tahway/no_one_gives_shit_what_programming#c_mdekgg

this take is so rotten I don't want to go near it

About the top comment in that thread.

Go is the new Java.

oh yeah for sure, i mean golang is basically just java with some features removed

Oops I was referring to the top comment in this post https://lobste.rs/s/vnc7u4/language_evangelists_why_should_i_use

Haskell is mentioned further down

The Benefits of Learning Haskell

https://lobste.rs/s/fxc0j9/benefits_learning_haskell

Nix is the dream of an ultimate DevOps toolkit in a similar way as Haskell is the dream of an ultimate programming language. Neither of these dreams seem to be congruous with reality.

https://lobste.rs/s/5gbbp2/nix_is_ultimate_devops_toolkit

Go is the new Java

Or as I like to put it

Java is the COBOL of today. Go is the Java of tomorrow.

Haskell Knowledge base is in the works. Provide your feedback in the Haskell Foundation slack!

https://github.com/tfausak/obsidian-haskell

Re: that now removed comment about neuron

Yes, for editing - obsidian notes work with neuron and vice-versa.

About the publishing part, tfausak who is spearhearding this KB project under the haskell foundation umbrella seems to like Obsidian's publish feature. I tried convincing HF team to deploy it as a static site (after failing in my neuron marketing efforts, which is understandable as neuron doesn't have a way to customize the html template - but that will be addressed by https://github.com/srid/ema ).

My main concern is that Obsidian's publishing is ... a black box, is proprietary and not open source. So it is beyond our control, and doesn't seem worth investing for a long-term KB in an open source project. It also has bad search-ability, https://github.com/tfausak/obsidian-haskell/issues/2

Cool!
I basically feel the same about Obsidian - as cool as it looks like, I would be endlessly worried about company changing mind about functionality / behaviour, without any straightforward migration path as far as output goes (input as fine ATM as you've confirmed above)

Yea, and I would be happy to give free https://www.cerveau.app/ accounts whoever wants to edit the KB if it was hosted on neuron (or even otherwise).

I do see the appeal of Obsidian publishing's graph view & sidebar, something that neuron (and other open source projects) lacks, but perhaps we can organize a group of volunteers and do it all in Haskell (not necessarily in neuron, but using https://github.com/srid/ema which I'm actively developing)

Added motivation for "organize a group of volunteers and do it all in Haskell": to make the upcoming haskell KB SEO-friendly: https://github.com/tfausak/obsidian-haskell/issues/2#issuecomment-822677225

btw, here's the invite to the HF slack: https://join.slack.com/t/haskell-foundation/shared_invite/zt-mjh76fw0-CEjg2NbyVE8rVQDvR~0F4A (taken from Snoyman's blog post)

I use slack at my school and it was fine on phone but on mac it was not the greatest

How can Haskell be marketed better to counter beliefs like this?

I love coding in Go because of the emphasis on simplicity.

Avoiding clever tricks seems counter-intuitive, but after decades of coding, I completely agree. They give me a buzz when I write them (part of my enjoyment of coding is from finding clever solutions to problems, after all), but they always bite me in the arse later.

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

Not sure if that's so off the mark. There's a reason for Simple Haskell

I like fancy tricks as much as the next one, but when doing production code I strive for simplicity

So Simple Haskell definitely is a step towards to resolving that belief (I won't be surprised if some people find even Simple Haskell to be non-simple).

I think Rich Hickey is correct in separating 'simple' from 'easy'. I wonder if the Go code referred to above really is simple, or merely easy.

I loved that presentation by Rich. I still use the word complect even in non-programming contexts (eg: the tendency in psychology to complect affect and cognition).

user1: I would never expect that ["It compiles does not always mean that it works"] of C++! Maybe Haskell or Rust, but not C++.

user2: I am somewhat hesitant to say this about Rust or Haskell

https://lobste.rs/s/3ls4jj/it_compiles_does_not_always_mean_it_works

While this ^ is technically true, there seems to be a casual underestimating of Haskell's advantage here (compared to the likes of Go, C++, ..)

A Rustacean points this out,

Such generalizations are never true in the absolute sense, but there is a noticeable difference in how often and how correct programs are when they compile for the first time in Rust vs less strict languages.

Lately, I've been relying more on HLS, not even the compiler. If HLS is happy, then my program is correct :-P

This (crypto-hate) is not how you grow the Haskell community,

https://www.reddit.com/r/haskell/comments/ncl2fm/can_you_ban_cardano_related_posts_here/

Sridhar Ratnakumar said:

Haskell Knowledge base is in the works. Provide your feedback in the Haskell Foundation slack!

https://github.com/tfausak/obsidian-haskell

This is officially dead now.