mb64/generate.sh

## generate.sh
#!/bin/bash

# Source: https://taylor.fausak.me/2021/11/16/haskell-survey-results
wget https://taylor.fausak.me/static/pages/2021-state-of-haskell-survey-results.json.zip
unzip 2021-state-of-haskell-survey-results.json.zip

echo "Question: If you wanted to convince someone to use Haskell, what would you say?" > q1-convince.txt
echo "---" >> q1-convince.txt
jq -r 'map(.s9q0 | .[]?) | join("\n---\n")' < 2021-state-of-haskell-survey-results.json >> q1-convince.txt

echo "Question: If you could change one thing about Haskell, what would it be?" > q2-change.txt
echo "---" >> q2-change.txt
jq -r 'map(.s9q1 | .[]?) | join("\n---\n")' < 2021-state-of-haskell-survey-results.json >> q2-change.txt

## q1-convince.txt
Question: If you wanted to convince someone to use Haskell, what would you say?
---
Functional programming is fun to think about
---
It's great for writing reliable and maintainable software. Web apps, APIs, daemons and DB integration have great tooling.
---
Haskell is a mathematical belief. This is the way of development of abstract thinking. And the question should be "what I want to get from a world?" And if the answer is "to understand a structure of the Universe through the Math not becoming an academic", Category Theory and Lambda Calculus is a right choice.
---
Combining Haskell's the strong type system and functional immutability with Haskell's ability to model domain effects as monadic typeclasses enables the possibly-very-best-in-the-market programming experience for modeling complicated domain logic.
---
So Elegant. When it compiles, it works. Programs are easier to maintain.
---
It's my favourite programming language, but I understand it's not for everyone.
---
Static types are a great help in refactoring.  First class functions are a great help in code reuse / factoring.  A clear distinction between immutable data & shared mutable variables are a great help in concurrent code with communication between threads.
---
Would you rather spend all day debugging side effects in a statement based language or build up meaningful expressions in a statically typed language with a nice interpreter?
---
What if I told you that runtime errors can be a thing of the past?
---
Pattern matching, algebraic datatypes, laziness.
---
Do you like things not-exploding in production?
---
If you want to use a language that is easy to maintain and safe, use Haskell
---
You only live once.
---
Understanding functional programming concepts and thinking up solutions in this way can help you become a better programmer.
---
Even if you have no intention of using it in your day-to-day, Haskell helps you to think differently about your code and code in general. Even if that were the only thing it has going for it (and it's far from the only thing it has going for it), that would still make it a valuable language to learn and experiment with.
---
Haskell will make you confident that your program is correct.
---
It transforms you into a femboy uwu
---
Usually one or more topics in haskell would do the job, which will let someone be interested in it trying to use it in hobby project.
---
It makes me able to confidently move from quick and dirty prototypes to a reliable production code without introducing regressions.
---
If you plan to continue developing your application then Haskell makes maintenance and refactoring a bliss. With Haskell you'll have way less bugs too.
---
It has a fresh syntax, helps you think recursively. Its a fun challenge working without loope
---
It allows you to evaluate the correctness of your code more easily than other languages, because of Haskell's purity and static type system.
---
It gives you the flexibility of a dynamic language while also providing compile time guarantees.
---
If it type-checks, it runs
---
Types
---
refactorings are a bluss
---
It allows you to reliably refactor programs.
---
To code in Haskell is fun!
---
You will love Haskell, it's the main reason to use it :)
---
It will improve your overall software development skills, it's interesting and an almost bottomless pit of things to learn. It's based on mathematical principles and serves as a gateway back to mathematics if you're interested. It's a great way to re-learn or learn a lot of compsci concepts.
---
- static types
- compile time checks
- minimal, quick to write syntax
- nice, integrated buildsystem (cabal)
- interesting new concepts that might find their way into other languages in the future
- learning it is a really useful experience to understand more about programming languages
---
Fearless Refactoring
---
I don't want to.
---
A day of debugging can save seconds of type checking.
---
It's expressive and the type safety is worth more than you might initially realize.
---
- powerful abstractions
- forefront of language research
- lazy
- purity, no `null`, algebraic data types allowing you to make illegal states unrepresentable and a
  culture of writing total functions, which makes writing code with the potential of
  a run time error awkward as you need to either call `error`
  explicitly or write non-exhaustive pattern causing a compiler
  warning. Defining features of Haskell like purity and abstract data
  types sometimes look like a mere consequence of a quest for more
  type-based formal verification. This quest is very noticeable in the
  Haskell community too.
---
Unparalleled maintainability
---
I maintain more than 200KLOC in production by myself in my spare time, and my services have more uptime than my uptime monitor.
---
While it can take a long time to get productive in Haskell, I think it's well worth the effort. The most appealing thing to me is how it makes the building blocks of software much smaller than most languages. This not only allows more abstraction of common patterns, but also makes code easier to maintain and allow you to make the abstractions more precise.
---
I would speak to the elegance of the language. I am a high school student and code recreationally, so I would also talk about how much fun it is to program in.
---
It is programmable, palpable mathematics
---
You only live once.
---
Strong guarantees with the aid of the type system
---
laziness lets you never have to think about iterators again
---
It will flex your brain and change how you write software.
---
It will change the way you think about writing software, for the better
---
Haskell’s type system can often enforce invariants for you. I find that if I’ve written a program, the compiler can usually tell me if it has a bug before I even run it. And a rich set of abstractions make code concise, maintainable, and easy to both read and write.
---
If you've ever had a null-pointer error, "NoneType object does not support ...," "undefined method ... for nil:NilClass," etc. (and somebody really should together a list to go along with this slogan), and that terrible sinking feeling that comes from realizing that, whatever you thought you were dereferencing when you wrote that code, it doesn't (or something clobbered your pointer to it), and you're going to have to figure out not only what you were thinking that was when you wrote it but then break out of that thinking to figure out how you thought wrong? Wouldn't it be better if your compiler saved you from falling into that trap and you could never lose track of what you have and what you can call on it and, if your compiler is already doing that, then also won't let you get access to anything but a valid value of that type? Well, for certain values of "what time of the morning" and "what production system", it sure might
---
- It helps achieve correct and reliable software, especially in complex applications
- It lowers the lifetime cost of large/long-lived software
- "It will make you a better programmer"
- It or something like it will be prevalent in the future

---
Haskell encourages to write no side effect codes.
This enables you to code test easily.
As Haskell’s side effect, your code will become readable when you code in other languages.

---
Functional programming teaches you a very useful POV, and Haskell shows you how much a good type system matters.
---
sequence :: Monad m => t (m a) -> m (t a)
---
adt and equational reasoning
---
Haskell is the perfect blend of these criteria:
* A strict yet expressive type system that prevents runtime errors
* Ecosystem of packages large enough to hit the ground running for general purpose use cases
* Adequate performance and resource usage for most use cases while allowing a very high level of abstraction
---
Nothing. I seem to drive people away when I talk about it, unfortunately.
---
The type system is a great help in constructing software:  it eliminates huge classes of potential errors, and is also extremely helpful (with google) in finding relevant library functionality.

Referential transparency makes it much easier to reason about code and to make it more easily testable.

Lazy evaluation helps one separate concerns in code construction.
---
Haskell is a joy to get things done in a maintainable way. Productivity and sustainability, pick two. We can focus on the meat of the problem, abstracting away the accidental complexity and only deal with the incidental complexity.
---
The static, strong type system is amazing. You never want to go back again.
---
Haskell allows runtime aspects such as side effects to be encoded into the type system.  This allows for the safety of strong typing to extend to this domain.
---
The highly constrained language forces catching a lot of common errors. I cannot easily throw away return codes or edge cases like I can in C/C++, and enforcing function purity means I know exactly when functions are modifying state elsewhere. It requires much more reasoning to code, but it produces a more thorough and well built product.
---
The only bugs you get are with your program's logic
---
Haskell gets out of the way and let’s you write practically declarative code with reasonable behavior and performance by default, unless GC’s are too slow for you or the libraries don’t exist for your application: check first.
---
It’s a lot of fun.
---
Go over the well-known benefits
---
It's the most interesting language to program in.
---
A lot of the time when you write Haskell code that compiles, it runs exactly as you expect. If you want to refactor, all you have to do is change some piece of code, and the compiler will tell you what you need to fix to incorporate your code change
---
I still love Haskell, but in truth I find for performance I'm more likely to use Rust and C++ (as a fall back). And for simple scripting and other smaller tasks, Python or JS are muck more flexible and less hassle to share with others.
---
Easier to reason about (eventually), more maintainable, fewer bugs, more fun to use.
---
It's fun and you learn a lot
---
I recommend the type system and testing frameworks.
---
Let's increase the security/maintainability of your code and decrease your cognitive overhead.
---
Haskell is a beautiful world of category theory real applications
---
Aren't you tired of trying to read runtime stack traces?
---
* You can get help from the powerful type-system.
* Higher-order functional style prevents us from common mistakes.
* Haskell (GHC) has a powerful concurrency support out of the box.
* It helps composable and maintainable softwares.
---
It's one of the most fun and rewarding languages to program in.
---
Code written in Haskell tends to be much shorter, clearer, and more re-usable than similar code written in other languages.
---
It fits a mathematical mindset, lets you represent solutions in an elegant way. It lets you enforce more things in the type system at compile time than most languages can. The language keeps advancing as people come up with more brilliant ways to represent solutions to problems. The community is full of interesting, smart, people who are passionate about the language.
---
connections with foundational mathematics and logic; high capacity for abstraction; excellent static analysis; elegant syntax
---
If the code compiles, it probably does what you want.
---
It teaches you better programming designs due to purity and explicit effects.
---
It's pretty good, but it's no ATS ;)
---
It makes easier to make 1) correct software; 2) well-designed software; 3) maintainable software. It also makes refactoring a nice experience.
---
Best example of a production-ready functional programming language.
---
Haskell has an advanced type system no other mainstream language has, it has great syntax (short and concise), great concurrency support, relatively big community and easy to get help.

On the other hand, it helps to be self driven/motivated (i.e the largest gravity center today for people becoming developers is JavaScript), so it really depends on where the person perceives his/her locus of control to be.
---
keep up the good survey work 💪
---
Pure and statically typed functions that compose well make your code easier to understand
---
If you want to do something without side effects, use Haskell
---
Easiness of refactoring and maintainability are the best features of the language. I'd focus on them.
---
Haskell is the best language to write interpreter
---
it's easier to get correct programs with Haskell.
---
Learning an ML-family language like Haskell will expand the way you think about the world.
---
It's a great way to train yourself to think about whether your programs are correct.
---
Knowing different paradigms greatly help your performance in programming. Do not be scared due to moands, you do not even need it.
---
Maintenance is low and easy, meaning one can focus on adding features fearlessly.
---
Haskell helps you code better, forces you to think before typing.
---
- it'll probably make you a better developer
- it is way easier to maintain
- it can prevent entire classes of errors that other languages struggle with
---
Haskell is the perfect language for application design/prototyping with executable specifications (type-driven development + quickcheck). And if needed it can be refined to real, efficient implementation (for part of backend development). Also perfect for in-house CLI tools.
---
- static typing make you safe
- algebraic datatypes, and the design of the type system more generally, help you express what you need in a clear way
- built-in concurrency primitives make your concurrent code safe and performant
- the community is overall great, smart and helpful
- the few most successful application design patterns are easy to understand
---
I wouldn't. I think you have to want the benefits, and it's got to work with the way you think. I would try and outline the benefits - Easier to reason with, compiler works with you against huge classes of bugs, easier to modify, adapt and grow. I wouldn't hide the fact that a certain investment is needed.
---
The software industry as a whole seems to be gradually coming to the conclusion that functional programming is the way of the future. Haskell (in particular GHC) is, and always always has been, on the cutting edge of functional programming research, is actively developed, and has been successfully used for practical production applications for some 20 years now. It is the among the most performant, safe, and reliable pure functional programming languages in existence, with a large, active, and enthusiastic community of users.
---
Refactoring is finally a breeze.
---
It's a joy to code with Haskell
---
Do you like code re-use? This language is build around relentless composition. Nothing else comes close.
---
- Haskell expands the horizons of what you think is possible
- Haskell is good for maintaining software long term because it makes refactoring fairly easy
---
I'm trying to show how monads are cool, without saying it's monads. Students are usually sold on parser combinators. To fellow/older programmers it's easier to sell the "overloaded semicolon" concept that produces the eDSLs so nicely.
---
That Haskell provides a structured and logical approach to writing code that can protect you from errors and invalid states while being intuitive to reason about.
---
Haskell helps you maximize the amount of code that is free from side effects.  Code free from side effects is:
- easier to test
- easier to debug
- easier to understand
---
Although functional programming is often considered as something 'special', it'll make you a better developer even if you don't use Haskell(or other heavily FP-oriented language), because Haskell forces you to use practices(immutability, divisions of 'pure' code and IO, good types, modularity) that are applicable to the usual OOP and they make your code better. So, even if you don't intend to use Haskell in production, you at least must take a look. And, more importantly, - it's really fun!
---
You write a function, and just go on with your life. The function will never stop working.
---
haskell is the most advanced programming language these days built on top of category theory and lambda calculus, with haskell, you can model a program in a more intuitive way, you can see though the essence structure of a problem and solve it in it's natural way.
---
It is the lingua franca of programming language research and functional programming.
---
That they will get a new perspective on programming that will help them regardless of whether they continue with haskell. But to be honest I would direct them to elm to start with.

---
succinct code guided by correctness through strong typing
---
Haskell is a language which will change the way you think about programming. It is an eye opening experience I recommend to anyone passionate about the craft.
---
Expressivity, simplicity, immutability.
---
When I’m trying to convince people to Haskell, I’m telling about joy it brings, it’s speed in terms of development time and about wonderful type system, which really change once mind, when they model the issue which they work on.
---
“You will learn to think correctly when you code”
---
Sadly, I have no good answers, except "try it, maybe it will be as fun for you as for me"
---
It is really easy to maintain and has very few surprises thanks to static typing.
---
"It broadens your mind"
"Many \"advancements\" in mainstream programming languages came from languages like Haskell, just 20-30 years late"
---
Read my blog post: https://www.foxhound.systems/blog/why-haskell-for-production/
---
Haskell is great, but I dunno, use it if you want to, do your thing
---
Something about effect systems (think polysemy), advantages of pure functions, etc
---
principled abstraction with less runtime programs and greater ease of software maintenance.
---
Has unique abstractions and lends itself to a unique problem solving experience.
---
Each programming language has its strengths. Haskell is a good choice if the software is to represent or recognize mathematical reasoning, for which _purity_, _laziness_ and _strong typing_ are almost essential.
---
It's the language most liberated from the Von Neumann style!
---
It will help to improve your coding skills even if you continue to work with your old language
---
It's not perfect, matter of fact there's a ton of shit missing... but it's the best language you'll ever learn & best of the languages in it's family for pretty much anything from api's & certain categories of CLI's and a very limited subset of UI's and you should go for Rust if you've got hardware/performance needs and Elm is generally better for FE but Haskell + Elm is my favorite combo today. Altho, if Haskell had a nicer compile-to-js story and an elm-ui like library I'd totally switch fulltime.
---
That a Purescript is a better "default version" of Haskell, so if you heard about Haskell, and want to use it, go for Purescript instead.
---
The difficult part is not the Monads but the "space leaks".
---
It will propel you to enjoy programming again.
---
Highly expressive and elegant language with an amazing type system that produces very stable solutions with great performance.
---
Haskell allows you to treat software engineering more as engineering than hacking, it may take some time to learn, but it then provides you the tools to make sure your software does only what you want it to, and performs well. There are few languages which make fearless refactoring so pleasant, you can make drastic changes and be much more sure you have then fixed all the problems that change introduced by the time it compiles again.
---
It makes you think from another perspective
---
don't use it
---
Parse, don't validate. If it compiles, it usually works.
---
It's super easy to maintain.
---
Building concurrent, effectful programs is the norm now. Haskell gives you a language to elegantly and concisely declare your programs and a friendly compiler who is best pair programmer you have ever worked with. Enjoy!
---
That I build a supercomplex API but hardly ever make bugs, due to the type system and the strong compile-time checks.
---
If it compiles it works! Not really, but despite being relatively new to Haskell I feel like I'm writing less bugs due to the rigor of the type system and being forced to reason about state.

The compiler generates fast code. Concurrency is relatively easy and safe.

Monads aren't really scary, they're just an encapsulated representation of state and actions upon it.
---
It's fun and makes programming feel magical again.
---
Haskell is the best language for implementing interpreters and compilers
---
I would say that you have no other options if you want to have *real* type system. Haskell is the only language that gives you really high level of abstraction and good type system and pure functional approach and at the same time being practical and generating efficient binary code. It outlived many languages but there was no language that can really compete with Haskell on the area it is in. There are simply no alternatives.
---
It will fundamentally change how you see programming.
---
Safe to refactor
---
It is fun.
---
I made an investment and it paid off. The hidden cost proved to be, however, that using any other language I have known before is simply a torture to me now.
---
If it compiles, you are N times more likely to be able to clock out earlier.
---
Unfortunately, no one can be told what Haskell is. You have to see it for yourself
---
You know all that time you spend fixing problems in your code after you first write it? Haskell forces you to do that up front, so you spend less time doing it and things usually work first time.
---
To a Javascript programmer:
* You don't have to handle impossible inputs, like null.
* You'll never forget to handle a new case.
* If you like .map(), .filter(), .find(), you'll love Hoogle.
* Errors pinpoint the bad line of code; you don't have to step through the whole execution.

To a C++ programmer:
* Everything is const correct by default; you opt in to mutation only when necessary.
* If you like std algorithms, you'll love Hoogle.
* Errors in templates (polymorphic functions) happen earlier.
---
It's a beatiful, easy to use and realy safe programming language
---
Refactor code with ease
---
when returning to a non-trivial project to make some changes it does not feel like sitting on a house of cards
---
I'd be happy to help you work through some problems/projects if you want to give it a shot
---
Can easily maintain long term projects, but requires serious upfront investment. Sorry, best I could do.
---
equational reasoning
---
You want some fun and feel great doing it?
---
Haskell is worth learning because understanding how to work with Haskell helps unlock how many other languages are implemented under the hood.  I also think that Haskell has an incredible type system that doesn't have to compromise around some of the compromises we see in other languages (e.g. Haskell doesn't have to transpile to JS [like TypeScript], or run on the JVM [like Scala]). The only other one I've seen like it is Rust, but I think Haskell is a bit more fun to write than Rust for web programming.
---
You will be a better programmer then.
---
type safety, memory safety, laziness, and ofc i would show them some cool oneliners
---
It's one of the best languages you have today, and definitely the best FP language. It's highly tailored to writing bug-free code with minimal fuss once you mastered it.
---
Maintainability
---
Immutable and sanely-typed
---
Oh there are so many. My team works on high-performance server software in C++ and a number of small to medium sized utilities written in Python. I don't think Haskell can compete with C++ on the server side (yet), but I would love to see us replace Python with Haskell for scripts and utilities.

Even with Python type annotations, I find myself spending a lot of time debugging runtime errors that would have been compile time errors in Haskell.

The language forcing a strict separation between IO code and pure code encourages more disciplined designs. I want to avoid muddling up the application logic with dependency injection for testing, IO error handling, etc.

Haskell's type system makes it easy to use the right type for something, instead of cramming everything into ints and strings. E.g. "this value can be either A, B, or C, and if it's C it needs to carry some extra data" is trivial in Haskell, but is a pain in other languages.
---
you can likely write the most elegant version of your code in Haskell
---
The type system of Haskell is such a strong advantage, that it removes most runtime and refactoring failures upfront.
---
I would point to the survey results about maintainability from previous years. That really is the killer feature.
---
If you're frustrated trying to reason through complicated, state-changing code, Haskell is the replacement you're looking for. You can write code that's easy to understand. You'll be confident that it does what you want once it compiles. It's a great feeling
---
Haskell's typing system is extremely good, and I love how expressive and safe I can be with it.
---
Hard, but powerful. Really good type system. Concise, elegant.

But I would recommend it only if having a GC is ok for the project (so not if it is real time system), and I would warn them that figuring out best practices can be hard and there are hard edges in general.
---
Rave about how nice the type system is
---
If you want to learn FP from the ground up and really understand its principles, try out Haskell.
---
I have your family.  They are safe for now.  If you want them to stay that way, use Haskell.
---
Category theory
---
You gain confidence that your code is bug free (or atleast drastically reduces the number of bugs). Easier to maintain code in the long run
---
Haskell helps me structure code in a maintainable, testable way. It is much easier to make correct changes or refactorings to a large Haskell code base, compared to any other language I’ve used.
---
Use a language that is 20 years in the future. Most modern languages haven't cached up to Haskell 98. We have async/await, goroutines, null safety, type inference, list comprehension, LINQ, compile to native, compile time code execution, traits, etc, etc, etc.

Most things you find interesting/powerful/unique in other languages Haskell has had them for years, most of the time as libraries instead of language features. The rabbit hole goes very deep.
---
I usually bring up known painpoints in the language they use such as runtime null pointer errors. I also talk about sum types!

Even though other languages solve the above 2, the people I talk to wouldn’t be ready to understand even simple generics, especially when type classes are involved
---
If your problem is best solved with lazy evaluation and pure functions, Haskell is likely a good candidate. If type class semantics help structure your problem in addition to that, it's probably the best one.
---
If you prefer to be a bit removed from what the computer is actually doing and program in a more "formal mathematics" kind of way, Haskell might be right for you!
---
Depends a lot on their background, but mainly that it's 1. fun to explore and 2. can make maintenance and refactoring of projects easier.
---
RUN FAR AWAY UNTIL YOU HAVE A MATH BRAIN
---
Real code reuse enabled by purity and unique abstractions.
The Haskell community is full of smart people who often get things right. Hackage can be a great source of inspiration.
---
Haskell makes you really think through your design. It has a one-of-a-kind elegance. Working with the Haskell type system feels like a conversation that guides you to deeper insights about your design and implementation.
---
I might tell them it's useful to learn because it forces you to find solutions that will benefit you in languages that you can actually get things done with.
---
It's the best language I've used, and I've used many.
Things you wouldn't dare to think of in Scala are easily doable.
Haskell broadens your design repertoire and makes you a better programmer.
---
Refactoring becomes easy, if it compiles it works.
---
It's the easiest language I get to work on as far as getting things right and maintaining things I've written.
---
Robust. Elegant.
---
Do it or don't, I don't care
---
Do you have adhd? Try Haskell! No state or side effects taking up your limited working memory, a type system and compiler which catch 90% of your distracted mistakes, and you can abstract away almost all tedious boilerplate one way or the other.
---
Hey kid, you want some monoids?
---
It makes hard things easy.
---
The core of Haskell has stronger foundations than languages such as Java, Python, and JavaScript. Algebraic datatypes make modeling a domain incredibly straightforward. The use of patterns and abstractions make it very easy to integrate other people's code to suit your needs. You can write high-quality Haskell code without knowing any category theory. You just have to agree as a team what features are going to be out-of-bounds (in the same way C++ teams need to agree on a subset of that language).
---
Great data modeling, and great maintainability.
---
When I write Haskell, there is never this sticky feeling, all too well familiar from other technologies, that I'm probably forgetting something or not handling some special case. When I write Haskell, I'm fully confident in my final product.
---
Fearless refactoring, easy to manage large projects, clear code. Yes, there's a learning curve, but that's an up front cost with high ROI. "It's like a cleaner Rust" :P
---
It improves your coding skills and help you write better code with less bugs.
---
It makes you think in a different way to imperative programming languages. If you use Excel, you already know how to think 'functionally' to solve problems.
---
I like it. It's fun.
---
It may not be the fastest language to develop in the first stages of a project, but it is usually very easy to maintain and refactor, what saves a lot of time later on.
---
This is meta, but I struggle with this, as they are not aware enough of the problems they have to know the need a better solution (ie python programmers who can't see the need for a strict type system checked at compile time)
---
It teaching how us treat, reasoning program differently
---
If you complete a semi-useful pet project in Haskell your view on programming, in general, will change. And changes such as these are important to make you see more
---
It's a little tough to learn, but resources are getting better. Once you've learned how to use it, I don't think you'll ever want to go back.
---
Abstraction capabilities are *chef's kiss*.

Ease of refactoring with types and referential transparency is a pretty good selling point.
---
Haskell is about finding right high-order conception. Some solutions really impress me.
---
It depends on what's important to the person. In general I'd show specific cases when Haskell shines (compilers, scripts, testing suites) and show why: syntax, types, adts/pattern matching, refactoring, speed.
---
I know how to make coding a better experience.
---
You get to stop lying about your data model! No sneaky returning a -1 on error. This involves learning a new kind of infrastructure to keep your code manageable once, but it becomes painless to not lie after you have that down.
---
Haskell is the most fun you can have while still writing useful programs
---
haskell is where math and algorithms actually meet programming. pure functions can be reasoned about, and once you're done with them, you roally aree done.
---
At present, I'd probably empasise that it could give them new ways of thinking about programming, e.g. Haskell can express concepts that few other languages can, such as lenses, and recursion schemes, which are 🤯
---
Executables are fast and super stable. The code is concise. At the same time, it's not for everyone, and the learning curve is steep.
---
The only language that actually delivers on the promise of reusable, maintainable software.
---
I would give examples of difficult problems made simple.
---
if you want to be able to model your problem as you're trying to understand what your problem is and want some sanity checking along way, Haskell is the right choice. you won't have to think about memory, unlike rust, while you're trying to figure out what you want to do in the first place. Once you're done writing your program it will be easy to completely re-factor it after your requirements change.
---
Its de best way to learn functionall programming, and code is strict.
---
Depends who the person is, but something like:

"Are you sick of all these half-thought-through abstraction that lead to runtime bugs? There is a better way, and Haskell tries to approximate it!"
---
Haskell is the most beautiful language I saw.
We can produce elegant solutions, also it's general purpose so we can apply it to many domains.
---
Easy to write secure code without many concurrent considerations about your product, thanks to powerful type system.
---
If you want to spend less time in the future to remember how your application works and to change and maintain it easier and faster having less errors, learn you a Haskell for great good.
---
Once my Haskell program compiles, it generally does what I intended.
---
Learning Haskell is fun. You're going to try to apply its abstractions everywhere when you'll get back to other languages. Enjoy the corruption!
---
It prevents entire classes of errors, and types show you what a function does without needing to look inside.
---
I agree with what has been said around the community recently, it is imperative to not to oversell or lie about Haskell because that will result in resentment. Haskell has issues, both in terms of environment like cabal vs. stack and in terms of language design like strings, and it can be a complicated language to learn. However, there are many, many areas where it is exceptional if not outright the best language available. We should focus on promoting Haskell in the domains where it excels and not obfuscate where it isn't appropriate to use (yet!).

Personally though, Haskell is just so much fun to use and I would try to get that point across too. The brain bending moments you get when first learning, like the first time you see function composition as fmap and realize that polymorphism really means *any* type, those moments are an important part of the language and are something that I think drives many people to continue learning and using Haskell even when it gets difficult.
---
To a non-programmer: Haskell is pretty much the easiest programming language to learn.

To a programmer: Haskell might be hard to learn, but it will change the way you think about programming and open up new worlds of possibilities for how you can solve problems.
---
It is the best programming language out there
---
It's a good bridge between abstract maths and programming.
---
I'd point them towards elm, and once they lrwrn it, purescript. I feel like this is the best way to get into fp. Only issue is, after working with purescript records, haskell is kinda annoying to work with in that regard:(
---
It is a very pleasant language to develop maintainable software.
---
Haskell is a result of an obsession to create the perfect tool to write programs. It doesn’t resign itself to being good or close enough. It’s not a language as it is, but rather how it could and should be.
---
The type system makes it easy to continue to write the programs you do want to write, but much harder to write the programs you don't want to write.
---
The compiler is literal wizardry - it's far too efficient for the abstractions you have available.
---
Extremely easy to maintain code.
---
You will learn something new every day.
---
read this book with the funny elephant on it
---
Haskell allows you to be a better engineer. You have to degrade a good software design less to make it implementable in Haskell than in other languages. Also, since you can get good designs realized in Haskell, you *want* to invest the time to write better code. For me, this translates to more fun. The down-side is that it becomes more frustrating to write in other languages.

On a more practical note, Haskell has a strong, static type system which makes code maintainable and more correct. Therefore it is specifically well-suited for projects which have a long lifetime, are large, or have high requirements on correctness or security. Only the lack of IDE support drags it down.

Haskell does lazy evaluation and thus is very good at abstraction which translates to more code re-use and less boilerplate. If needed, you can fall back to TemplateHaskell, an integrated code generator.

Haskell's type inference and concise syntax make well-written code pleasant to read. Compare this to e.g. Java, where you write way more boilerplate and type signatures, which convey less meaning.
---
You can freely move code around and if it type-checks it is correct 99% of the time (and the remaining 1% is due to shadowed variables).
---
Haskell is very conducive to writing powerful abstractions, which allows elegant solutions for suitable problem domains. Furthermore, the type system allows giving a partial correctness proof of your program.
---
I would try to show them the intuitive constructs Haskell offers and try to transform their fear of runtime errors in their favorite dynamically typed language into appreciation of Haskell's expressive type system.
---
Haskell is the most elegant programming language I ever used
---
If it compiles, you are N times more likely to be able to clock out earlier.
---
You'll save time on tasks that are really painful in other languages, and you'll waste time on things that are easier in other languages. When used correctly, a software foundation in Haskell is sturdy and reliable.
---
Because of the powerful type system, you can do very large refactorings without worrying about breaking your code
---
it will open your mind.. and force you to upgrade your mind to its next version.
---
Almost like C in which it could do.

Could be compiled to binary.

Have better type system.

Package management system.

more stuffs like lambda ...
---
Refactoring
---
The strong typesystem and expressivity of the language allow being extremely productive while writing correct code.
---
IO-seggregation in code is the best tradeoff to keep code maintainable.
---
Learn you some functional programming, for great good!
---
When it compiles, it usually works
---
Great for learning, great for research, great for expanding knowledge of computing. It's great for CS grad students and great for hobby use.

From a senior mgmt leadership perspective: Haskell development and deployment are horrible to manage for production use. Don't trash your management career and reputation on this.
---
* Compiler does a lot of checks so you need less unit tests.
* Almost no boilerplate code and compiler can generate a lot of code for you.
* Can generate very fast code
* Very useful language to learn to get better at programming
---
It reduces classes of error, if you model your types well. And with the effect system, code refractoring is very easy.
---
It can do everything that imperative languages can do, but sometimes it will do it in a single line. If you learn to write Haskell it will open up a different way of programming in any language — another tool in your toolbelt.
---
It's a very fun functional language to use, and writing code in it is mentally stimulating because of having to think functionally. Recommendable as long as you're not the one maintaining the build system.
---
it allows compositionally abstracting up with basically no limit and gives you the tools to generate code based on your data. Many things are first-class members of the language.
---
Code written in Haskell is easy to maintain, you can deliver features faster, Haskell has composable concurrency, you can refactor code fearlessly.
---
Types dude!
---
It's a great general-purpose language, as long as the problems you're trying to solve don't involve strings, structured records or input and output.
---
It is much easier to refactor your code.
It is much easier to become highly productive with a smaller team.
---
It's easy and fast to write correct code.
---
Just try it. ;-)
---
I consider program in other languages a waste of time
---
It will give you new intuition of where bugs can hide in your code, and show you ways to avoid them. It's also a very effective way to learn many different mental frameworks to see easy, airtight ways to do very laborious and error-prone things.
---
* the type system means you find most problems up front
* the type system is at worst a minor burden and doesn't get in your way
* it runs very fast for most purposes
* coding in Haskell is a very pleasant experience. Most people who are familiar with it tend to consider it their favourite language.
---
Learn the type classes. It will change the way you think about programming. Especially if you read up on Haxl or that paper that investigates build systems in terms of Applicatives and Monads.
---
If I knew I would've convinced my coworkers already
---
Pure FP is baked in, powerful type system, mind opening to learn
---
it's the only pure statically typed language on the backends in industry.
---
While OOP is well suited to desktop GUI's, FP is well suited to web services that involves data flows and transformation.  Haskell makes doing FP easy and robustly.
---
It's cool, functions can be polymorphic in "return" values. You can create infinite data sequences easily. You can write nice composable parsers in it. And the type system really guides you through your coding.
---
It's beautiful and wears its underlying mathematical principles on its sleeve. Writing code in Haskell feels like sculpting a beautiful, pre-existing structure by removing the excess of what should not be there to begin with.
---
it's good
---
RankN, HKT, GADTs
---
You will be coding with a peace of mind. Compiler takes care of most of the debugging.
---
Depends on their background: theoretically inclined folks (math or otherwise) might enjoy its type system and reading papers, folks used to dynamic programming might enjoy the ability to easily refactor and use the compiler to drive such refactorings, while OOP folks might like the idea of stronger types or the STM/concurrency libraries we have.
---
I'd say maintenance is the biggest pro in haskell, also some things that are pretty hard in other languages are pretty easy in haskell (like parsing or streaming)
---
Great control of data structures
---
Strongly type language with type system that helps you develop complex applications. Haskell fits the neat spot in language design where you can focus on problem solving. You don't need to focus on low level details and don't need to bother about theorem proving on type level.
---
Depending on their programming and FP experience, one or more of:

- there are no loops
- [demo laziness]
- [show servant]
- [something about session types]
---
It'll change the way you think about programming
---
Firstly, I would make it clear that they should only use it if they do not care about performance. Then I would explain that they type system catches a lot of bugs.
---
It's never been a better time. It's still fundamentally different, and that's still going to take some getting used to, but there are more libraries than ever and they're getting better all the time. And if you're hiring outside of crypto or Facebook, driven smart people will beat a path to your door.
---
i would show code examples to demonstrate how it can lead to more elegant code
---
In Haskell I can express my programs very elegantly. Everything just fits together. It’s strong type system is great to catch a wide range of bugs.
---
if compiler is ok with your code, than it's highly probable that it works ok.
---
Everything you think you love about OOP is done better by functional programming. In general, you can have way less code, but also cleaner, and most importantly easier to understand and reason about. Way less wasted hours debugging, or dealing with boilerplate, or dead code, etc.
---
- Understanding functional programming is an enlightening experience and makes for a better programmer regardless of the language, but Haskell in particular is a good starting point
- Haskell's ability to work as designed once it is compiled is just awesome
- Stack and the Haskell Language Server are just a joy to work with. Especially when compared to some other languages multitude of terribly over-complicated build tools
- You don't actually need to understand monads to begin programming in Haskell, but it helps ;-)
- If you like rigorous math, Haskell will scratch that itch
---
Learn Haskell! Because you will learn concepts that will prove tremendously useful regardless of the language that you normally use for writing code.
---
Haskell is a pretty nice language to write stable program with expected behaviour. By the way, it requires some time to understand how Haskell actually "works"
---
Maybe our clients could hire devs to maintain it and teach them Haskell. Most good devs would be happy to learn it.
---
Please try it 🥺
---
Best language I know
---
I tell them Haskell made me think better as a programmer.
I would show some examples of my code and compare that to imperative programmed versions of those examples.
---
Best language to learn FP paradigm, which will make you a better developer, no matter the language you work with.
---
Programming errors are more expensive the later they are found in the software development lifecycle; would you like to be able to find more of them at compile time?
---
Other programming languages keep adding functional language features and many of those do originate from Haskell. Instead of trying to get to know the better language from another language, why not try to directly approach it and learn it?
---
When writing Matlab (de facto in our field), you spend 90% of time debugging, 10% for writing. You can reverse that ratio with Haskell.
---
Referential transparency and expressive types really do make programming fun again.

## q2-change.txt
Question: If you could change one thing about Haskell, what would it be?
---
more databases stuff
---
Make it easier to do something as opposed to not using Haskell and forgetting it
---
Make it strict.
---
Rename Monad to something less obtuse
---
Fix records
---
More libs.
---
Have solid statistical profiling tools that run on `-O2` code.
---
better library documentation
---
Layering different monads together in a simple, ecosystem-wide way would be truly amazing. The current fragmentation between monads, monad transformers, effect systems, and more complex monadic structures such as monad-layer leave a lot to be desired ecosystem-wise. Solving the problem or understanding the true complexity in solving it it is surely beyond me, but as an end-user of the ecosystem I would love for a lightweight and capable solution that everybody, including the standard library, could rally behind.
---
Better cross-platform compilation for mobile and web, so it's easier to write code once, run anywhere.
---
I don't know what are Haskell's best use cases (web? agents? games?). Simple-y to learn the first 80%, but the long tail is... long.
---
Use MSVC toolchain for Windows.
---
Better debugging tools!
---
Ending the concept of every project / company having their own “version” of Haskell via a cacophony of language extensions; replacing it with a single “One True Haskell” standard which the industry can rely on.
---
Better tools for monitoring performance of long-running processes, starting with `perf` compatible CPU activity profiling.
---
That it would have more commercial / professional use and therefore more open job positions
---
Cabal vs stack is super confusing and I ultimately choose during a project based on my deps and which compiles first.
---
I would like to see a unified, easy to use build ecosystem for Haskell.
---
Better interactive editing a la Idris.
---
I would make memory usage easier to predict.
---
Use Word for container sizes, not Int.
---
unhappy with exceptions bubbling out of IO
---
cabal's usability (friendly error messages)
---
I would like the community to focus more on industry adoption.
---
Not Haskell as a language but Haskell as an ecosystem: more options for game development, particularly 3D games, which is very lacking
---
Rust inspired package manager
---
Faster GHC compilation
---
Introduce a better scheme to maintain libraries.
---
Try to minimize unrelated politics.
---
The community.
---
WASM as a compilation target. I want Haskell in the browser!
---
Better IDE and tooling support
---
Better error messages that help learners proceed instead of mistefy them.
---
I think Haskell still gives a really strong academic vibe. Most of the discussions you see on Twitter/Reddit are about programming language theory, category theory, etc, and to an outsider it looks incomprehensible.

The thing is, people talk about what they want to talk! Here's hoping the Haskell Foundation promotes content for beginners.
---
none.
---
More practical learning guides for syntax and semantics for experts in other languages.
---
Add dependent types.
We're using Haskell at work (finance) because of the strong static garantees.
Dependent types would make our life easiser. Type families make compilation too slow in a large code base and singletons are not nice to use.

---
Types
---
Hash map (text keys) performance / memory usage
---
fix memory safety in monasichlloos
---
Working with records should be easier / less cumbersome. Hopefully the new extensions in GHC-9 will help.
---
I would like a pragma to asset that a compiler optimization should fire, and emit a compiler warning when it doesn't.
---
It would be nice to see an agreeded subset of the language with agreed defaults to get productive faster.

I find it tricky to read some blogs and articles where there's new concepts I don't understand. While I like learning new concept's at some point I want to be productive.

I've made progress with Rio and the concept of Simple Haskell.


---
Mostly syntactic things - imports. But I have no idea how to improve it.

Sometimes I lack ease of OO languages to define shortly and repeatedly named functions/methods belonging to different types. In Haskell we have to bother themselves with qualified imports or prefixes. Qual. imports is a decision, but not so convenient.

Our code often have large proportion of imports - maybe even 1/3 of code, so that we need to use HLS to maintain them automatically. It's very large as compared with C, Swift, C++ :(.
---
Have more resources to gap the intermediate to advanced chasm. Have more jobs that don't require being an expert or that would train intermediate candidates. Remove its relation with cryptocurrencies.
---
The community and their obsession with maths and category theory rather than real-world software engineering principles.
---
More articles/books on advanced Haskell technique
---
There are too many white dudes
---
Create a sane Haskell 2020 standard to avoid sprinkling tons of language extensions all over the files. (Ah, and encourage library authors to add documentation)
---
Make packaging sane.
---
Compile times
---
cabal / ghc integration
---
The builds. Make them caching by default. No more rebuilding libraries via Cabal or Stack or any other community promoted tool.
---
Fixing string/text ecosystem
---
remove OverloadedRecordDot
---
Easier debugging, diagnostics and telemetry
---
Get rid of the mental masturbation in the community.
Make the community focus more on sustainable development instead of abstract algebra.
---
It’s use in industry, and if there could be a golden (opinionated) path for new folks to on-ramp.
---
Use `:` for type annotation instead of the list construction nobody uses anymore. More broadly, get rid of having to maintain syntax level backwards compatibility to the 90s style Haskell that was almost a different language compared to the current one. It's taking over namespace like `map` that you mostly don't want to use compared to the newer `fmap`.
---
Create a cross-platform functional GUI library that can be used with idiomatic Haskell.
---
Record getters and setters syntax - yay GHC9.2 :)
---
Give it a sound definition
---
The difficulty of the different compile and build tools, as well as the lack of good resources on how to use those tools.
---
dependent types
---
Better library documentation regarding beginners.
---
Its popularity would be much higher.
---
it gets too complex if you want to do anything useful with it. as they say, haskell is a language for/of experts? i'm sure when you're fluent it gives you more expressive power but when starting the cognitive load and novelty is too high to not feel overwhelmed
---
make GHC error messages easier to understand and more relevant to the actual error
---
have a good default string type that supports laziness

make it more like Idris
---
Appoint a librarian/curator for the libraries. Too many low quality or overlapping libs.
---
allow c/c++ like floating point matrix arithmetic as part of the language rather than needing ffi
---
A clear demarkation of what is academic vs what is useful/necessary to know.

---
Friendlier people (not fake friendly / cheerful like e.g. Rust)
---
As a Java person who has been learning haskell, I find the IDE support to be lacking.  I've been using Intellij with a 3rd party haskell plugin called Intellij-Haskell by Rik van der Kleij. The plugin defaults to managing projects with stack and allows me to get certain features like 'goto declaration' and code improvement suggestions.  Although it's decent, I think adding strong, commercial grade IDE support would bring developers from Java and .NET into haskell more easily.

I also think it's confusing to have a build tool like stack that wraps cabal.  I'm using haskell to build Cardano smart contract functions.  The team behind Cardano is using cabal and nix-build with tools that support Haskell language server.  For me, stack is my default build tool since I'm running IJ with the plugin I mentioned.  So, I am forced to reconcile things between what Cardano does and what I learn on my own and the tools I use.  It's a pain.

These issues are probably related to my beginner status with Haskell, but these are my first impressions coming from the Java world.
---
Less fragmented package ecosystem
---
row polymorphism, but i'd probably have a better answer if i knew Haskell better

but if you're reading this, Mr. Fausak, then (a) i love your podcast, (b) thanks for
doing this and everything else you do to build up the Haskell community, especially
by making it more welcoming to newcomers and dabblers, and (c) you need to have
Vitaly Bravilevsky on your show to talk about his Haskell in Depth book, which i
found was just spraying Haskell knowledge at me from every page, trying to take you
from beginner and pushing you up some steep parts of the learning curve along
all the many dimensions the haskell landscape unfolds after that, with just really
exquisitely crafted examples to highlight each concept being demonstrated, and
a bit of levity or snark every once in a while to let your coding cortex take a break
while your funny bone is being tickled. i'm not sure what kind of podcast episode
that would make for, and not sure you would even want to after being ambushed
like this in a State of Haskell survey comment, but ... hate for folks to miss out on
knowing about this resource, especially others like me who tune in because you
make it sound like you are on a learning/exploring adventure and are bringing us
along (even if you're really well out in front of us) and who may also find this a
really great travel guide
---
The dogged tribalism, paranoia and politics, especially around FP Complete and its constructive efforts to make Haskell more usable and practical for the mainstream.
---
 laziness
---
Options for build tool such as stack.
---
Make it easier to read code written by others. I have a hard time understanding code written by others in Haskell and I consider myself an intermediate Haskell coder...I've read several books and written tens of thousands of lines. With other languages I have a much easier time reading and understanding public code bases, but with Haskell the code cathedrals everyone builds are difficult to make sense of.
---
I want Dependent Haskell :)
---
simplified tooling
---
Main problem today: very slow compilation time, bad productive tools (Haskell Server) and integration in IDEs, not productive lang standard (with included default extensions) with an official documentation with standard best practices and conventions (required for company integration), basic features missing (ex: Dot syntax not stable)
---
Allow trailing commas,
---
A way to easily, clearly, and persuasively communicate Haskell’s (and FP’s) benefits to mainstream programmers, such as work colleagues or students.

If there is no adoption by programmers closer to the mainstream, Haskell will remain a niche for programming language enthusiasts.
---
Type ascription with a single colon.
---
Make it strict.
---
I would love for base to be a batteries included standard library such as Go's standard library
---
I would like to see more beginner material that introduces more of the ecosystem, rather than laser-focusing on the language.
---
Make Haskell runs fast in browsers (via wasm or GHCJS or otherwise).
---
Everything else than writing code is complicated. Setup of (inter-dependent) projects, maintenance of projects (package dependencies, repeatedly changing cabal-install flags, maintaining 'project.cabal' AND 'stack.yaml' AND 'shell.nix' or 'flake.nix' AND 'hie.yaml', upload to Stack and Hackage), choice of libraries (which ones are well supported core libraries?). I don't like Rust, but we need a better user experience similar to the Rust ecosystem.
---
I think a rework of the type-class hierarchies in base would be very nice, particularly the numeric stuff.
---
GHC compilation times
---
As a beginner, I would like more practical walkthroughs of how to implement common library types and algorithms in my own code. I find myself repeating a lot of code in my projects, and it's difficult to find what tool to use instead when I don't know the vocabulary of Haskell. Something like a guide which takes an application by a beginner of functional programming and identifies what code to replace with standard library tools, and what design principles to use, would be extremely helpful.
---
A firm standard library that can be the foundation of the package ecosystem
---
Add dependent types support with simple syntax
---
Easier circular imports
---
Template Haskell not being part of the core language: if it remains an afterthought when adding new language features, it will always be out of sync and buggy.
---
Improve package tooling
---
More non crypto jobs! More french documentation!
---
Turn on ScopedTypeVariables by default. Anyone whose code breaks deserves what they get.
---
Making it easier to compile/cache libraries that work across different versions of ghc.
---
Better record support (similar to PureScript)
---
Integrate lenses, and improve existential support. Those are two features that give a much more natural interface to Haskell, for users coming from "more mainstream" languages like Kotlin or TypeScript.
---
I find the Haskell community unwelcoming, at least when compared to something like Rust's, less so C++. Not a huge problem for me personally, but it means I'm much less likely to recommend it to my students.
---
Better onboarding/practical guides for beginners
---
Add dependent types. Currently, attempting to encode logic in types is very clunky (compared to e.g. Agda).
---
Replace kinds of with universes. Or lets just say make Haskell like Agda but keep the toolchain/exosystem.
---
I'm on the CLC ^.^ i realllllllllly want to make base/Prelude as-good-as or better than alternatives like Relude or mono-traversable.
---
More attention given to Literate Programming, interleaving : code, comments and results of evaluations à la org-mode.
Eg. up until GHC 9.2 `HasCallStack` was still buggy with `RebindableSyntax` https://gitlab.haskell.org/ghc/ghc/-/issues/19918 .
Now the Eval plugin of HLS https://hackage.haskell.org/package/hls-eval-plugin still does not capture stdout/stderr thus forcing to use the `error` trick. Also emacs' `lsp-lens-mode` is still buggy (sometimes it messes lines or does not refresh without my knowing why) and does not provide a function to refresh all code lenses in a single command.
---
2 things immediately come to mind, the speed of the compiler. It's still rather slow for medium to large codebases compared to a similarly sized codebase in OCaml.

Second, in an industrial setting I would favour a slower pace of new language features being introduced  vs compiler stability/speed/tooling/maintenance. For example the work on Arm64 NCG (or cabal improvements or LSP) is more important to me than say Linear Types or Record Dot Syntax. Academically those type features are very interesting but I couldn't responsibly use them at work.
---
record syntax
---
More libraries, more algorithms, more applications
---
We need a consistent approach for strictness annotations that doesn't feel like "advanced" haskell. I don't know if that means compiler changes or just articles about NFData, but laziness-by-default would be an easier sell if even beginners could feel more confident that something they intended to be strict was actually fully strict, and not just WHNF.
---
Make builds faster
---
use single colon for type
---
Integrates row polymorphism and extensible records.
---
Make cross-compiling more ergonomic.  That means either re-designing Template Haskell, or replacing all of its uses with other mechanisms like Generic.  Also, make GHC re-targetable via flags (the way Rust works), so I don't need to compile my own cross-compiler for my specific hardware/abi combination.

---
Add dependent types
---
We need row types like in Elm or OCaml.
---
developer ecosystem, e.g. package management, build tools etc.
---
Documentation, tutorials. Notice how rust programming language has books for teaching people.
---
Make it a bit more pragmatic and accessible to an average developer, and clean up the language. For example, there are way too many string types — makes it confusing for a newcomer. Similarly, operations involving mutation of state could use a bit of syntactic sugar. Haskell could use some inspiration from OCaml or F#.
---
Tooling suitable for tracing and profiling code in production.
---
Easier setup for new projects so that it's easier to start: picking build tools, setting up linter, formatter, a CI file, and providing a good architecture template.
---
performance
---
Please fix cabal.

I want
cabal install username/package
cabal remove username/package
---
More streamlined tooling and ways of deploying it as a cloud-first application
---
Dependent types :)
---
Stable language standard with periodic revisions like other languages do so I can write some code against standard version Haskell20XX, and not worry about breakage when I upgrade GHC as long as I compile with --std=Haskell20XX.
---
Reduce the GHC extension footprint and just add an easy way to enable everything safe and useful, where the community has achieved consensus on.
---
records in general!
---
I'd get rid of stack. It served its purpose, and now it's holding us back from things like backpack and it's inflicting all kinds of horrible yaml tooling on the ecosystem.
---
See more examples of real world applications, and their design/architecture.
---
I would like a standard library that is pure wherever possible. An experienced person can pull in an alternate one but that doesn't help those new to the language.
---
 multiple modules in a file and internal (nested) modules.
---
The RTS :)
---
The library documentation seems to be geared at being an aide memoire for those already familiar with it, but makes it very hard for a new user of a given library to understand how it is used.
---
I would change the `Num` typeclass to a hierarchy such as Semiring, Ring, Field

and also remove the partial functions like `head` from Prelude
---
Establish Nix build infrastructure dominant for Haskell. So that it becomes the standard across developers including as newcomers. It requires writing some tutorials but will unite developers and eliminates a whole class of problems. Because Haskell does not live in a vacuum but in integration with other environment which (integrations) Nix handles best (best in class).
Windows is supported through WSL+Nix and I don't believe other ways viable nor worth the efforts.
---
I would like the number of companies using Haskell to be higher. More companies using Haskell for their products would lead to more users in the community and, more and better-tested libraries and so.
---
Can't limit it to one thing, sorry:
- faster compilation times
- better performance analysis tools / documentation
---
Documentation!
---
I think there is unnecessary fragmentation, especially between PureScript and Haksell (and to a lesser extent Idris and Haskell). With so much shared DNA, the projects wind up reimplementing the same things with minor variations. All things considered, this winds up being a colossal investment of effort for relatively modestgains. It would be awesome I'd the Haskell Foundation could work actively with these projects to bring them under the same umbrella as much as possible.
---
I would like there to be more non-cryptocurrency employers
---
Though it will never happen, swapping : and :: around.
---
Record field names that relies on type to distinguish between alternatives to eliminate name clashes.
---
I think the "boring haskell" and "simple haskell" people are onto something. Unfortunately, I just don't have time to keep up with all the innovations (free monads, dependent types, etc.) and I end up feeling like there's not much place for me as a work-a-day Haskell developer. In addition, Rust has a lot of the things I am sure I need (ADTs, Result vs Exceptions, newtypes, etc.) but it's also much more of a practical language with an emphasis on pragmatic, approachable code and language-development.

I think Haskell will never be a _practical_ language, but I kind of don't want it to be. I want it to keep innovating, but I don't think I'll be using it at work as a result. Now, when I write HAskell, I have this kind of frozen-in-place feeling of: should I be using more type-level programming? I tend to feel like, "ah, maybe I'll just write this in rust."

The other interesting thing about Rust, is that while I have learned a ton from Haskell's focus on purity and side effects, it really hasn't meant much to me that Rust is impure. In practice, impurity is more convenient and less likely to prevent me from making some serious mistakes than I had imagined it would be.
---
Names, like Functor, Monad, Category, etc. They are quite esoteric in that the names are devised by mathematicians. Also gives the illusion that you need to learn category theory to be fluent in haskell, which tbh does not help much in practice. I'd prefer more "layman-like" sounding terms, even though it could be lame. (E.g. Chainable for Monad)
---
Unify Stack and Cabal
---
Haskell feels confused about its identity as people use it extensively in academia but also now in industry and we can't seem to agree on a unified approach to building software with Haskell. This is something Rust is doing better than Haskell, it is really unified behind being a pragmatic, industrial language.

I like Haskell's academic roots as the academic rigor has made this language what it is, so I don't want that to go away but it would be nice if the community and language at least chose which audience to focus itself on (my vote is for pragmatism and industry).

For instance, I feel like PureScript has retained its academic rigor while being really unified around the language's identity and intended audience...
---
make lots of changes to base and Prelude to incorporate what we've learned in the past 20-30 years
---
Totally break base, fix all the bad things, standardise more libraries in it
---
I feel very strongly that the Haskell language needs a better solution for namespace management, such as the proposed LocalModules extension. This is a daily source of pain working in Haskell.
---
ghcjs incompatible with stack
---
Provide more things in base library to actually build applications: bytestring, text, witch, containers, maps,  tools for logging, etc.
---
a modern prelude by default
---
- less group identity activism, which can be very noisy at times
- less focus on smart findings for the sake of publishing in academic journals and more focus on performant libraries and documentation on how to perform reliable performance analysis on code
- clear standards for documenting and displaying the documentation on libraries
---
Dependent types.
---
syntactic sugar for lens. the language should have a built-in facility for modifying one part of a very large data type
---
A cleanup and modernisation of the base libraries.
---
I would really like to see more effort put into Haskell for GUI application programming and games. There are a few good options right now: the Reflex Platform, Keera Hails, the Integrated Haskell Platform. But I don't see a lot of enthusiasm for any of these products in the community. A nice showcase of well-maintained example programs built on these platforms would probably help, along with more reading material, podcasts, and vlogs about getting started using these GUI platforms.
---
Partial functions.
---
Records and data accessing. Lens is okay, but a big dependency and I never remember all the operators. I'd like something a little simpler and built in.
---
Have support for newer versions of ghcjs
---
Globbing of modules in cabal files comes to mind, it's just needles friction and the compiler throws extra sand in your eyes by telling you exactly what to change.
If it just modified the cabal file for you instead or something. I don't know.
---
Better tooling/IDE support
---
To have a second, mildly incompatible but smaller compiler. I hope to have some variant of RTS-less haskell one day.
---
Not one but I think there are a few bad decisions in the prelude and basic syntax:
 - partial functions in the prelude e.g. head :: [a] -> a was a mistake and not in the spirit of Haskell, should only have a head :: [a] -> Maybe a
  - record dot syntax has been added very late in the day, it should be part of the standard.
  - String should not have been alias for [Char] and should have been compact utf8 text.
---
Make it harder to shoot yourself in the foot (partial functions, bottom, "problem functions" that the experienced folks know to avoid etc.)  Maybe this is just asking for a "blessed" alternative prelude, and simpler process to use it?
---
Use Text everywhere and forget about String.
---
performance
---
Record system
---
The IDE and debugger.
---
Improve compilation speed
---
I would make the arrows for contexts in class declarations point the right way, so that they can be read as implications. e.g.
class Applicative m <= Monad m
---
Saner defaults, default ghc options for:
    -fwarn-name-shadowing
    -fwarn-incomplete-uni-patterns
    -fwarn-incomplete-patterns
    -fwarn-overlapping-patterns
    -fwarn-incomplete-record-updates
    -fdefer-type-errors
    -fwarn-orphans
    -Werror
---
A minimal subset of GHC extensions recommended for “simple” or “boring” Haskell and documents to support that language standard.
---
better syntax formatters, more advanced topics in literature, an updated real world haskell book, performance improvements for effect systems other than fused-effects, faster compilation times.
---
Single colons for type annotations à la ML is preferrable to double colons.
---
Code golfing.
---
Dependent types, better tooling, (compiler) performance.
---
Inscrutable syntax used over common sense names. I don’t like needing to memorize a million magical sequences of punctuation to be productive
---
IDE
---
Extensible records.
---
Get rid of CPP
---
Unifying the build tools and and making them "just work" with minimal configuration (like cargo for rust).
---
Not Haskell specific, but making GHC core more hackable: a Core REPL, an explicit Core compiler, an extension allowing embedded Core etc... It's actually quite a nice, simple and powerful "kernel" language, possibly not just for Haskell but for other, waiting to be implemented high level functional languages too.
---
More focus on beginner-friendly library documentation with practical usage examples
---
Haskell is easy to learn, hard to master(?); it would be nice if both were as easy
---
Add row polymorphism ala purescript
---
Simplify the extension ecosystem.  It's wonderful as a way to keep research and experimentation going, but it would be nice if extensions were rarely necessary in production code
---
Nothing specific, but I know Scala FP with ZIO and find usage of abstractions there much easier than in Haskell. What ZIO uses to greater advantages is stronger Scala modules, variance/covariance annotation, effect rotation, far fewer type classes exposed to users (none). In ZIO, there is no need to know monad stacks, transformers, alternatives, arrows, etc; the libraries present you with much simpler interfaces and DSLs to use.
---
The domain specific meanings and understanding... it's borrows names and concepts from category theory and the mathematical realm, but even knowing those does not help you understand how to think about Haskell coding.
---
Typeclasses should be specialized by default instead of being passed around as runtime dictionaries.
---
Better incremental compilation, better integration with HLS, and better culture around avoiding update churn/fatigue.
---
Adoption in the industry
---
Nothing specific, as Haskell & GHC are pretty malleable, and progress is quick.
---
Better tooling. Nix helps, but too often haskell.nix rebuilds the world.
---
Rename Monad to Burrito </crappy-joke>
---
No more partial functions please.
---
Debugging is poorly supported
---
Tough to say, because asking to fix the warts means building barriers to entry if not entire walls segregating entire sections of industry from being able to use Haskell. But due to it's principled foundations & broad applicability to so many use cases it's tough to say that "Haskell with more cohesion" would be a better Haskell.
---
Fork the language and restart it as Haskell 2, with better defaults, getting rid of lazy evaluation (all it does is: it makes infinite lists easy, such a great feature that we all use all the time am I right? /s), linear types (have a borrow checker a la Rust), get rid of significant whitespace (vim-style users can easily manipulate blocks of code, but we can't do that in these stupid whitespace based languages), delete the GC (with linear types you don't need this garbage that collects garbage), and finally, put better support for dependent types (Haskell is shouted as this modern language, but to me it looks like a 1990s language, no more modern than C++).
---
Better tools for debugging, addressing, preventing space leaks. Laziness is great, but its so easy to get bitten by it.
---
I wish the community and GHC developers took the user experience of Haskell more seriously. It's a great language hidden behind bad UX.

1. GHC error messages are often impenetrable for new users. Even sometimes to experienced users. Messages should be written in simple language.

2. The documentation is very bad. The design of Hackage makes it seem as if autogenerated docs are documentation. They aren't. Libraries need to have tutorials, howtos, etc. See for example servant vs lens.

3. The mechanisms for libraries to provide custom error messages and guidance are totally inadequate.

4. The community keeps breaking code needlessly. For example, now there's a desire to modify Eq and the exports of Data.List. This churn adds so much overhead that I've often migrated packages away from Haskell. Cosmetic changes should be disallowed. Core devs are vastly underestimating the pain inflicted on users by such changes.
---
Safe Haskell by default.
---
strings
---
Use a more modern prelude and have the most useful extensions on by default.
---
the recent idea that it must succeed: fail at all costs is the right approach.
---
Ditch lens, fix records.
---
I would improve the tools for browsing documentation and comparing packages.
---
I'm am a pragmatic, industrial programmer. More than anything I wish we had a consistent and consolidated story for tooling. Imagine a single tool like Rust's Cargo for managing the compiler and packages, then building, documenting and packaging our build artefacts ready for shipment. Designed for programmers that work on multiple projects simultaneously on the same machine.
---
Make it stricter, the lazy evaluation has bitten me more than once, so I enable Strict for all my projects and I'd be slightly happer with having strict WHNF evaluation by default with the option to do it lazily, instead of the other way around as it is now.
---
Better haskell debugger integrated into the code editor

Simplify writing performant code (for example no linked list as standard container structure) and make performance more predictable

More ergonomic use of unboxed types
---
Please, we need Haskell, not GHC and dozens of random extensions. Practical language usage shouldn't be tied to one compiler. Each project written in Haskell shouldn't have its own dialect.
---
Better type checking error messages.
---
Add support for anonymous records
---
I would get rid of partial functions from the standard library and make it more complicated to create partial functions. “head” is the first candidate.
---
Better tooling - it's getting there which is great to see!

As of my last attempt earlier this year it's hard to deploy somewhere like AWS, which for better or worse is really common in industry.

Likewise GHCJS isn't really usable at the moment and I'd advise anyone in the frontend web space to look at PureScript or Elm instead, but long-term I'd like to see Haskell competing there.
---
Add anonymous extensible records, they don’t have to be a replacement for the current records.
---
Add a proper module system (not ML modules, just nested/local modules).
---
Purge 'String'.
---
GHC or whatever alternative compiler needs major upgrades.
There are lots of optimizations that already exist for e.g. more efficient memory layouts that are implemented often in entirely new languages because the compilers' IRs are so unintelligible. That leads to Haskell lacking behind in possible features and performance being way worse than it should be.
---
Exception control is messy and difficult. The IO monad is inelegant.
---
Continued investment in simplifying build tooling, making project builds easier to reason about. Nix, while technically sound, lacks the ease of use that tools like Stack do today.

Otherwise, love what's been happening in the last year re: Haskell Foundation.
---
I don't have much experience to answer this question
---
Make the syntax more C-like
---
more libraries for integrating with services
---
Technical: I wish Haskell had PS-style records (row polymorphism), alas...we're getting better at least though

Community: more authoritative "official" positions on best practices--especially wrt larger architectural patterns--in industrial contexts, to be somewhat hand-wavey about it. This also implies better reference documentation, tutorials & guides, etc. around these topics.
---
Find some way to make performance analysis easier to do without having to run the code first
---
Reduce syntax. I'd like to keep all "advanced" features, and yet reduce the ways of doing things by as much as possible while retaining or improving ergonomics. For example, there should not be like 3+ ways of doing a pattern match on a function argument (case statements, function bindings, \case, pattern guards, etc)
---
for myself: better GUI toolkit options
---
Better ide support. The comfort of java in intellij is huge. It makes everything so discoverable.
---
more windows support, magically heal the rift between stack and cabal users
---
Some reliable and straight forward way to just target another architecture, e.g.
Host x86 -> Target ARM
---
Better tools that work for enterprise.  I know that's an evergreen ask but it'd be awesome if we had something similar to Cargo or even (gulp) Go (I think gopaths and shit suck but Go generally has a really good tooling story in that they Just Work ™ once you've gotten everything configured in an opinionated way).
---
Documentation and Ecosystem, it's pretty impossible to find simple answers to anything to start (and I come from Javascript so I'm not a maniac of well documented or straightforward ecosystems).

I think it's this lack of beginner friendly content that slows down haskell adoption.
---
records
---
Can't think of anything. It works for me and my work (maybe I'd like tooling - especially in the IDE department to b better - but I don't believe it is "thing about Haskell", or crucial)
---
Move "standard Haskell" towards "practical Haskell". As a teacher, I keep teaching "standard Haskell". It's all I have time for in my course, which focuses on theoretical aspects of functional programming. Many resources on (learning) Haskell, too, start with and focus on "standard Haskell". Unfortunately, knowing "standard Haskell" does not seem enough to actually start writing practical software in Haskell.
---
Make it easy to find (or maybe start?) an open-source project to contribute to, for free or paid.
---
One of the biggest hurdles to convincing my team to try Haskell is the learning curve before you can do useful work. For us the best use of Haskell would be replacing utilities written in Python, but Python is just so *easy*: an experienced programmer can learn a useful subset of Python or Ruby in a day. I don't feel like that's true for Haskell.

The kinds of "utility program" tasks I'm thinking about are:
    - get json data from an https endpoint
    - write a table of data out to a csv
    - make a nice looking png plot of our results
    - call the `netstat` program and parse the results to find what port our server is listening on

I like the "Real World Haskell" book, but it is focused on teaching from the ground up rather than getting to useful programs as fast as possible. E.g. the chapter on CSV parsing teaches you to write a CSV parser, rather than "use the CSV library can call CSV.parseCSVFromFile".
---
Introduce semantically hashed per-function code management like unison and fragnix.
---
faster compiler with a larger standard library that promotes best practice across the ecosystem. In both cases Go is a great example here.
---
Fixing string/text ecosystem
---
The IDE tooling is some of the worst I've ever encountered in my life, and the compile times are atrocious with non-obvious rules about how to structure projects and modules that make significant impact.

When the tooling works, it's great.

HIE/HLS in small projects has been neat. In very large projects, I have issues getting it to consistently work without segfaulting and/or very high resource usage.

Cabal has at times managed to fail non-reproducibly for me. With errors that nobody on the internet writing the language for years had ever encountered.

I don't really even know the language. I spent more time trying to get a proper IDE + dev environment set up than I did learning how to write Haskell.

Eventually I just gave up and said "I will wait until it has tooling that works reliably like languages such as Go, Rust, Java, C#, etc, until trying to write it."

Please work on the IDE + build tooling and the compiler faster. It takes like half an hour to compile my company's project from scratch, which is just absurd.

---
Please delete `return` and make tab indentation enabled by default.
---
The community and the documentation practices. Haskell is not a beginner-friendly language.
---
Better out-of-the-box IDE support, less tooling fragmentation, less VIM-ism, and more IDE mentality.
---
More begginer friendly learning resources
---
Better Prelude
---
I would push out more plug and play web things like a CMS that is built on yesod and web commerce libraries.
---
Get rid of all the left-over landmines like partial functions, String, non-strict folds, etc.
---
Sometimes performance drops off a cliff due to minor changes that cause the compiler to radically alter its strategy, which I never run into with Go or Rust (my primary languages). Generally both of those languages are a little less safe and sometimes a little harder to write, but have much more stable performance envelopes and are generally much easier to diagnose bottlenecks.

I would like to either be given more control over Haskell's performance characteristics, or more warning that something I'm doing is prone to worst-case performance, or even a good way to debug what's causing the slowdown to occur.
---
Documentation. All together it is still too hard for a beginner to get up and going.

What I believe we need is:
1. Good getting started guide.
2. Good book to take you further, that people agree on and that is focused on the practical side of things.
3. Standard set of best practices that are well documented and described. Since Haskell leaves many things (error handling, effect system, ...) open to handle as you like, it is important to have a recommended solution for each of those that people can pick up and become productive.
---
Fix the numeric system, replicate modern algebra.
---
High quality tools for performance analysis.
---
Make it easier to debug. I want it to just as easy as debugging python, just click to set a breakpoint and the view content of all variables.
---
Make editor integration better, to get closer to other amazing dev and tooling experiences like Clojure or Typescript.
---
No Rails-level killer app.
---
Category theory
---
Better ecosystem. Everything is good but often times it doesn't "Just Work". Dealing with getting up and going with any new type of lib is often painful, especially for newcomers
---
Easier on-ramp for new devs
---
Only one would be records. They're pretty weak compared to the rest of the language.

Another thing would be long compile times.
---
Make errors more beginner friendly by default. So if im putting a string where an int should be, I want to be told that instead of “no instance for Num arising…”

Companies should contribute more to open source. It feels like they create local libs to solve their ecosystem, but don’t publish them!
---
Lazy IO
---
Just like you can inline Assembly in C, it would be nice to be able to inline Go in Haskell.
---
Fewer traps (e.g. partial functions, Foldable (a,b)) in base and common libraries.
---
Easily build statically compiled executables for deployment.
---
All the various infix operators (removal of most of them).
---
($)
---
Stupid boomer Haskell conflicts from 6 years ago
---
Develop great machine learning & data analysis libraries
---
Haskell should provide means to generate efficient code. (Could be a library)
---
I would love to see some of the efforts towards "better" core libraries meet with widespread community adoption (eg Z.Haskell). Basically Haskell shines for exploration and academic usage but the assumptions of the most core packages (eg base, text, bytestring, http-client, etc) really do not play well in production when it comes to performance or configuration, best practices etc. As it stands it takes a lot to go from baseline functionality to production ready, and this is something where other established but less interesting languages (eg Go, Java) tend to shine.
---
Something about the (async) exception story, it means that for concurrent code that does IO I find Haskell code harder to reason about than e.g. Go code -- the types don't help.
---
Trailing commas
---
Faster compilation, precompiled binaries for libraries, quicker availability of libs after compiler update (see also: Scala Community Build - https://github.com/scala/community-build).
---
Over-use of overly (research) high level concepts, cut down on redundant operators to make it easier to write good Haskell (eg, somehow remove ++ for lists in favour of <>)
---
Refactor & do a great update of the Cabal.
---
Debugger usable in real world environment
---
Better tooling / compiler / stack for front-end web development. Current options are not satisfying in my view (generated code to bloated, performance problems, complicated tool stack, etc.).
---
More a cultural thing than anything, and it comes from academia mostly, but I wish people would put more effort into stripping Haskell of its mystical veil and treat it as a practical programming language like any other. Too often it's the ready-made abstractions which are led with, not the things being abstracted over, so it appears as if you have to be a genius to come up with these things, instead of the reality which is that you spot patterns and abstract over them! And to make matters worse, students are often prematurely discouraged by being told 'Haskell is really hard' (by lecturers!), when it's not any fundamentally harder than other languages and in many ways it's much simpler. All it takes to demonstrate this is to watch students try to write a linked list in C vs. a linked list in Haskell. I could go on forever about this, but in summary: the ivory tower still needs dismantling.
---
I wish we were willing to make more breaking changes in GHC.
---
Reduce compile times of libraries.
---
If it were more popular, it would just be easier to use, which is circular. It makes hard things easy, but easy things hard. It would be nice if the easy things stayed easy.
---
I would like the tooling to improve. One of the biggest areas where Rust is more enjoyable than Haskell for me is that their LSP implementation mostly works and continues to improve rapidly. In Haskell, I find that the "jump to definition" and other functions don't always work, which forces me to fall back to things like searching for "function ::". We had a bunch of Java engineers brought on to work on a Haskell codebase and they were frustrated with the absence of what Intellij gives them in Java.
---
I wish GHC code quality was higher and it wasn't so dominated by poor historical design decisions and its insane monstrosity of a build system. (Actually it has two build systems, because that's totally a good idea.)
---
Improve the typeclass hierarchy in base, e.g., by adding Edward Kmett's Apply in between Functor and Applicative
---
Enble record dot syntax by default
---
Proper records!!!
---
Fix the Prelude! Having to tell people "Step 1: disable the standard lib" doesn't start on the right foot
---
Reduce binary size, by using tree shaking to remove dead and unused code from the final binary.
---
Prelude partial functions
---
Some libraries tend to be Unix-like operating system centric; I would try to make Windows a 'first-class' citizen.
---
System.Random's Stateful part of the library. What the hell, why is the extra 'g' argument needed in these functions.
---
Make it more popular.
---
Do the Record Dot notation since the beginning, so that we could handle records as in Elm for example.
---
Reachable to low spec computational device user,like termux on android app or IoT application.
---
I just want to click command + click on a function from a library and see its source code
---
A better toolchain. Learning a build tool takes almost as much time as learning the language itself, and there are several different build tools to choose from.
---
Faster compiler performance, no doubt about it.
---
Replace records with anonymous, row-polymorphic records.
---
nbr of people actively using it in production
---
Make Text a default string type
---
Build tooling
---
Tooling as easy as Purescript
---
Improve the IDE support (HLS / IntelliJ) to not require manual restarts, become ready faster, consume less memory. (In that order.)
---
Garbage collection pauses should be shorter — the low latency collector did not fix things for us
---
GHC would use GCC for codegen by default.
---
At the moment, I probably think more documentation around Haskell build/deployment setups. I've got this whole issue with targetting alpine on a stack build. And in general, I think using haskell in industry can be a little harder than it needs to be, not because anythings impossible, but because it's harder to figure out boring "build/deployment" tasks than it might be in some other languages.
---
We need more informative, simple tools to speed up the process of identifying what changes need to be made to boost performance. Tuning performance currently feels like a dark art to me.

Last year I benchmarked my Haskell implementation of a sequence of 2D convolution-like transformations on arrays of integral values against a C++ implementation (it's an important operation in the game that I'm developing). My initial C++ implementation, which I wrote in one evening, took an average of 0.0088ms to perform one transformation, but my initial Haskell implementation took 2.2ms. It took me 3.5 weeks of constant work to figure out how to reduce the runtime of my Haskell implementation by 3 orders of magnitude. In the first 2 weeks, I only managed to reduce the transformation time to 1.6ms. I eventually figured out how to get it down to 0.0070ms through a combination of:

- using mutable unboxed Vectors or Arrays;
- using unsafe Vector/Array functions;
- using bang patterns;
- using {-# UNPACK #-} ;
- using -fllvm ;
- avoiding Ratio Int (because of its slow (*) operator);
- accidentally discovering the performance benefits of defining tail-recursive worker loops as where-clause functions, rather than top-level functions.

I tried using GHC's profiler to identify the bottlenecks, but in this case it didn't provide enough insight into what was going on for me to be able to see that I needed all of the above optimisations. I was only able to work out these optimisations by reading blog posts and then going through a long process of trial and error. I considered learning to generate and interpret Core, but if that's the least inefficient way to solve performance issues like this, then that proves my point about the need for simple tools that are more informative.

Inexperience was part of the reason why it took so long to figure all of this out, but there's a limit to the amount of time I'm willing and able to devote to optimising Haskell code, especially in cases like this where I can write a fast C++ implementation with little effort.
---
I wish Haskell had not chosen the dot (.) for function composition and had instead left it for record access. Maybe a pipe (|) or an ampersand (&) would have worked?
---
1. Maybe we should focus a bit more on the look and feel of the Haskell related websites. The UI/UX aspect. The Rust community seems to understand the importance of this a bit better. It may not be a priority, but I think it does have an impact on how the language and ecosystem is perceived.

2. Stronger emphasis on some ground truth first-choice libraries. Maybe have a curated comparison between various libraries, for some core categories? Database DSLs, streaming libraries, network, APIs, testing etc. Architecture articles from AOSA (e.g: https://github.com/snoyberg/posa-chapter/blob/master/warp.md, https://www.aosabook.org/en/ghc.html) are great for this kind of thing.

3. Stronger visual tools. DrRacket arrow comes to mind.

4. A really strong and popular Haskell project that the outside world can mention immediately. The dreaded "what are some Haskell projects?" is still prevalent on forums. And no, Cardano is not it.
---
If I could change one thing about Haskell, I would make it a highly popular and highly adopted language! What's missing is a killer app that everybody knows (pandoc is not close to that, it's not e.g. firefox).
---
I wish it was attractive to high-paying tech companies so there's a chance I could use it at work. (There are jobs at small companies and startups but they don't pay nearly enough)
---
More compiling targets, I'd love to write critical code that must be correct in Haskell and compile to elixir or Erlang
---
I wish most libraries would use backpack instead of picking one of the many string types. Converting between lazy/strict ByteString/Text/String is not only verbose, it makes reasoning about memory usage harder than it already is.
---
Move away from blockchain spaces
---
My strong wish that there would be a focus to create and document a new standard with a cleaned up prelude. I believe it does not need to be a standard that has to be perfect. GHC has accumulated so many extensions and there are so many alternative preludes and re-developments, that I think it would be very helpful to get to a consensus, which ones should become standard and define them. For people like me, who have to pick up Haskell programming from time to time, or are newcomers, it is so difficult to chase the latest best practice, the set of extensions (just look at the list of extensions in this survey - it is intimidating and makes me feel completely helpless despite >10 years of Haskell), some prelude that is better than some other. It would be good to have good modern and blessed defaults, on which people like me could lean on. It does not prevent from continuing research or to redefine the standard a few years later. But nowadays, even the question "do you know Haskell?" does not make sense, even if you know the basic language. The weight of extensions in real life make me to practically not know Haskell. Other than this, I am very happy and love the language and the community! Keep up the good work!
---
A real good IDE, that supports coding with syntax highligt a "Visual Studio IDE" but for Haskell.
---
Make GHC compilation very fast and efficient. Everyone apologises for it but it is unacceptable. This is making us think seriously about the viability of Haskell due to costs and compile times. Fix it! Somehow fix this. Not more caching not turning off all optimisations just legitimately increasing the performance of ghc.
---
Add row types and extensible records
---
Dependent types
---
Compilation time,
tooling for projects (better practices than wild NIX config files)
---
Standard support for effect system (or other structure to handle multiple procedures)
---
An all-inclusive OFFICIAL tool, as part of the GHC setup, to install, remove, upgrade dependencies, to do linting, code formatting, testing, and IDE autocomplete.
---
Built-in dependent types.
---
Dependent types. Add them.
---
It would be nice to reason about performance more easily, not sure how that'd be implemented though.
HLS still needs a bit of work to perform well on large projects :)
---
There is a paradox: Haskell is the greatest language in the world for text processing, compiler and interpreter writing, computational linguistics, and so on, but at the same time we have the String problem. If I could change one thing about Haskell it would be to just bite the bullet and reform the String type, breaking whatever needs to be broken in the process. The longer we wait the worse it will be when it finally happens. Adding new type level features is great, and I am very excited about all of the amazing things coming down the pipeline for the language, but my biggest wish isn't for full dependent types, its for String to be addressed.

This would also go a long way towards my actual answer to the question, which is swapping '::' and ':'. Out of all of the mistakes made early on in Haskell's life ':' not being 'has type' is probably the worst and I dream every day of a world where we can fix it.
---
More libraries and more stable libraries
---
Enable OverloadedStrings by default.
---
Get rid of the ability to catch exceptions. (Talking about the genuine exceptions provided by the runtime, not the "exceptions" modeled by things like `Either`.
---
Reduce degrees of freedom in formatting.
---
Fast runtime in typical common programs, apps, libs, etc.
---
Version numbering of libraries
---
When the code causes an exception (e.g. *** Exception: Negative exponent) that GHCi or whatever would also output a trace so one can determine what function is causing the problem.  And/or change the function to use types that won't cause exceptions.
---
Enable the best language extensions. Burn the rest.
---
Row poly based records, better standard prelude, less extensions, explicit laziness
---
Much better library ecosystem.
---
It would be great if the Haskell Language Server would be further enhanced, e.g. with refactoring tools.
---
Better tooling - HLS is great, but sometimes crashes my system by eating too much RAM. Better tooling needed for debugging an perf analysis. Hard to judge (for me) where space leaks hide.
---
Dependent types
---
I would make it easier for beginners to use Data.Map, Data.Set, Data.Text, other very basic functionality that doesn't live in base, without having to learn Cabal/stack
---
A better Prelude, fix the namespace problem for record fields, faster compilation times, a streamlined standarized build tool to reduce choices
---
Nix vs. Stack vs. Cabal split (and difficulty installing these tools). If there was something akin to Rust's Cargo, for Haskell, this would be ideal!
---
Follow Rust more, especially in regards to correctness. It's ridiculous that we claim to care about correctness but never fix historical mistakes in `base` and other core libraries. https://twitter.com/grhmc/status/1432137513410433026
---
Easier "blessed-path" for tooling, easier to reason about laziness.
---
We really need more ergonomic singletons.
---
Community evangelism. We are the butt of every joke in programming forums, we should do less talking, less abstraction, less of that, more showing off programs (games, utilities, etc.) done *in* Haskell. Doesn't help that some Haskell communities (e.g. /r/reddit, HN) actively promote the former.
---
I would not hesitate to undo past bad decisions. I see no replacement for Haskell on the horizon, it is best if the community accepts breaking changes now for a better future. Witness AMP. Recent example: remove (/=) from Eq. All redundant library functions should go away (e.g., return).

The biggest elephant in the room: the numeric hierarchy. Would love to see this redone. That would be a true act of courage on the part of the community!

---
Compilation times ...
---
Rename bind to andThen.
Delete Data.String.

---
That it would have more commercial / professional use and therefore more open job positions
---
At the moment, the biggest issue is not with the language itself, but with a severe lack of refactoring support. From my personal, professional experience with large code bases, I can say that support for the semantically correct renaming of variables is not a "nice to have" feature, but a necessity. Code changes over time and names have to reflect that. Otherwise, new team members (and future me) will be lost in the existing code.

The next step after that would be moving variables between modules.
---
Haskells performance is okay, but once you know what is possible it feels too slow. So my one change would be to implement Perceus [1] for Haskell (even though that probably means sacrificing laziness).

[1]: https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v4.pdf
---
Support for catching existential exceptions
---
Easier to reason about performance with respect to lazy operations/data structures.
---
Remove all of Haskell's involvement in Cryptocurrencies.
---
- Change from `type String = [Char]` to `type String = Text`
- Remove `[a]` type constructor and replace it with `List a`
- Replace `:` cons operator with `::` type annotation operator and vice versa
---
Exception control is messy and difficult. The IO monad is inelegant.
---
I would change a lot. I could not pick one.

Cabal is confusing junk. Stack provides significantly better experience and UX, but the community is unable to navigate unifying and improving the Haskell developer's quality of life.

GHC devs don't understand how to provide a graceful experience.

GHC devs seem to believe their success is based on how much theory is encoded into GHC, and don't seem to care much about the real-world developer experience with GHC when used in anger.

Haskellers have a love-affair with Dependent Types, but can't seem to figure out how to create decent tutorials for newbs or how to unify their tools and work together.

The community politics are shameful. We don't care about things we should, and care too much about things we shouldn't. We allow toxic behavior and reward suppression of dissent. We continue to enable a cabal of zealots, despite their mismanagement of the community and our tools.

We have harsh divisions in the community and tooling rather than a warm and productive ecosystem.

The community is full of academics who lack practical experience using Haskell (or software) in anger and to solve real-world problems at scale.

We have massive gaps in libraries, and ignore how hard it is to build software with poor documentation.

We learn so much Haskell theory, we're unable to understand a newb's thought process and fail to teach them with reasonable results.

We lose more Haskellers in their first few days/months/years than keep.

We don't care about losing people to this experience.
---
Better, faster IDEs
---
Add first-class extensible records
---
Nothing in the language per se.. may be a bit more readability(but thats nitpicking)
What i would like is.. that it reaches more people. There has to be a push for it to be used in the industry. Tooling, ides, libraries for everything, best practises, more case studies, more content on the internet about different ways people using it, and some benchmark comparisons between languages.
We are not showcasing the power of haskell to the world.
---
Strictness by default, optional laziness instead
---
More job postings* :-).

* Without having anything to do with blockchain.
---
Remove some of the "academic"-ness of the community.
---
Standard prelude like RIO
---
Fork Haskell into a research platform and a real-world product, each optimized for its target, and rename the real-world product to avoid confusion and the bad reputation.
---
Faster compile times and hackage user experience to encourage more documentation
---
Have a opt-in cleaned up version of prelude/base without the years of accumulated cruft and some not as optimal design decisions.
---
- Agreed upon standards
- Better practice documentation, guided by the "practical application architecture"
- Better documentation bar for the libraries
---
Num should be split into several typeclasses.
---
Reduce aggregated complexity around the language. Every language extension is a potential community splitter.
Try to elect winners and reduce diversity of choices regarding the tooling, the communication channels, the library to uses, the best practices. Support record structure algebraic operations (similar to row polymorphism).
---
This is more of a GHC than a Haskell request, but the main thing would be to make it easier (trivial) to generate static binaries.
---
This is probably impossible to change, but the experience of working with Haskell modules is absolutely awful compared to working with Rust ones: since only one version of a given package can be in the entire dependency tree at once, it results in substantial pain while upgrading things. It's the same issue as Python. This is in addition to bugs in both compiler (in our case, perf regression fixed in 8.10.6) and packages that can often fall out on upgrades.
---
:: should be :
---
Slow GHC compilation speed. This can be a major killer of productivity.
---
Faster compile times.
---
Switch the whole thing from being built on text files to being built on IPLD merkle trees.

So that the compiler cache isn’t so brittle and more importantly so that dependency management isn’t brutal.

I shouldn’t have to worry about lua libraries to convert html to markdown with pandoc.
---
Community. I want people to care more about other people and show more empathy and not attack others for doing Haskell differently or breaking things for the sake of the elegancy of some idealistic language from the future.
---
Issue a new Report.

---
Make data strict by default.
---
If I had a wish granted, it'd be that we have a second compiler without the historical weight of GHC. I don't even really have a clear picture of what that would include, but it would be nice to have a place to experiment more aggressively with things like type class hierarchies and runtime machinery for effect systems, or a place to write Haskell Prime without an endless pile of LANGUAGE pragmas.

Other than that, compile times could use work, but I also write Scala which is its own nightmare on that front, so I'm not complaining that hard.
---
Rust is doing a lot of things right that i feel Haskell should be doing: it's fast, has great documentation, a friendly community, it's a pleasure to use. We can learn a lot from Rust.
---
Appoint a librarian/curator for the libraries. Too many low quality or overlapping libs.
---
More emphasis on end users than fancy types
---
I'd really rather change the perception of Haskell as a fringe esoteric language and make it more mainstream to make it easier to get a job working in it.
---
Strictness by default with optional lazyness
---
Records (that's slowly getting addressed, though).
---
Remove 'bottom' from every type - make it optional?
---
It's not about Haskell itself, it's more about GHC: please, increase the speed of compilation.
---
More elbow grease in haskell.nix
---
Unify strings.
---
Fix up legacy mistakes in stdlib, e.g. `head` being `:: [a] -> a` instead of `:: [a] -> Maybe a` (or `uncons :: [a] -> (a, Maybe [a])`), `map`/`fmap` distinction
---
There's a stupefying amount of drama around the build tooling, and how new users should get haskell installed.
---
Add a language option so that optics are generated for all algebraic data types instead of field accessors.
---
Tooling feels underwhelming, especially after using Rust or Go. Go for how quickly it can spit out a static binary, and Rust for its package management.
---
Make it more transparent that it's possible to do "real world stuff" (production software, web apps, tools, etc) in Haskell, not only programming language research and category theory things
---
Value system. Even establishing Haskell Foundation didn't help here. People are still dividing the community by some hidden, personal criteria based on onw myths and delusions. There are still no social lifts for contributors like me who does a lot (books, talks etc), people on the top don't consider it worthy because the opinions I state differ so much with the current Haskell dogmas. Haskell has no meritocracy, it shows clannishness instead of a fair approach to people with another value of systems.

P.S.Please consider including questions about Haskell Foundation next time.
---
formal proofs
---
an erlang like otp infrastructure.
---
Improve package management and build times.
---
to have better online documentation
---
The experience with development tools, while *greatly* improved with the introduction of HLS, is still subpar and sometimes can be frustrating. This is not yet on a level with the development tools for a lot of other languages like Java or Python.
---
More emphasis on namespacing. E.g., sane imports (Python/Rust), dot access on records, dot access for most used functions (e.g., someHashmap.insert)
---
The compiler's error messages. Haskell IS AN IVORY TOWER. The word "arising" should not appear in regular parlance ever. Just point me to what to change and provide a link to the error code, like Rust does.
---
make "return" something else
---
More entry level materials to get more people into Haskell.
---
Standardize on a sensible string-like type instead of putting up with the distracting noise of having to choose between String and Text. This probably starts with a cleanup in the standard library.
---
Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times. Faster compile times.
---
Merge all the build tool options into one tool.
---
I really don't like records but that will hopefully be changed with the RecordDotSyntax proposal, also I don't really like current ORMs, but I think I'll implement one if I have some time for it.
---
Managing dependencies
---
If you're a beginner creating toy programs with numbers, Haskell is great. If you're an expert using libraries you know and love, Haskell is great. It feels like a well worn, perfectly fitting glove. When you're in the middle, Haskell can be a disaster. Documentation is incredibly sparse. Choosing libraries is difficult, if any exists at all. JSON parsing means you might have to learn about quite advanced concepts. Sum types with named records are very confusing. How does all of this come together? What's the well-lit path for your average real-world code base that has simple but firm requirements?

Document this in one place, keep it up to date, and improve some of the warts in these common use cases. That, in my mind, is the path to success.
---
Having a more industry focused subset of the Haskell ecosystem that is less bleeding edge than academia with more stability, batteries included, clear best practices, and recommended libraries. That way it can be adopted by companies without needing previous expertise in the Haskell ecosystem. It would also complement the high maintainability benefits that the Haskell language provides by design.
---
Either more cohesive language design, or easier control over performance
---
Modules
---
PartialEq and PartialOrd as superclasses of Eq and Ord.
---
Performance: quality of compiler result, tooling and predictability.
---
The educational content. We lack content to draw imperative programmers towards fully functional languages by showing them real-world applications
---
Performance
---
That it doesn't yet have dependent type, but instead has a bunch of ad hoc language extentions.
---
A good recommendation for newbies that isn't "buy haskellbook.com and work slowly through the whole thing" - which works, but only for a certain kind of person.
---
simpler tooling/error messages for beginners, as i feel that can be a large barrier to entry for the language
---
Debugging capabilities. Right now I know only of print-debugging in Haskell which isn’t as effective as debuggers in some other languages.
---
Freely available, high quality beginner level and intermediate level tutorials.
---
I would add enterprise support, like DB2, Oracle, SOAP, WSDL etc.
---
That school started teaching Haskell not as something exotic once you reach Programming Languages courses, but from the very start if possible. How awesome it would be if we started first class by looking at haskell ways (possibly in parallel with imperative ways)...

Now on the technical side, not much. My company uses a bunch of Java and a custom build system for it, so using Haskell, or even slowly transitioning to it is kinda impossible :C
---
More friendly documentation with EXAMPLES (!).
---
It would be awesome if the compile process could be sped up. While stack can build multiple libraries in parallel, building a single project happens serially and this can take a fair amount of time, even for small projects. Building e.g. the modules inside a single project in parallel would be a very welcome improvement to the developer experience, as the speed of the edit-compile-test cycle is critical to a good development process.
---
Improve compiler: More predictable performance that doesn't regress with newer ghc releases.
---
Records could be improved and data constructors should be scoped (as in e.g. Rust)
---
Bigger community
---
Dependent types!
---
More verbose, less cryptic operators.
---
Better documentation with usage examples  in the docs. Type annotations are not always enough.
---
ScopedTypeVariables on by default.
---
Resolve the tension between development workflows and CI tools in which development tools favor a god stanza (HLS and ghci work more smoothly that way) but it's better for the CI to split up your project into multiple packages (better reuse of compiled artifacts, especially for Nix).
---
I wish for a better and decent IDE.
---
better Template Haskell, maybe something like macro in rust idk
---
I would not know where to start... honestly.
---
Library authors writing documentation assuming no prior knowledge, rather than assuming Math Phds
---
Easier to parse / generate source, for tooling and source-to-source transforms.
---
No abbreviations and acronyms, explicit names for everything
---
Memory management! Why? I have been going back and forth between building programs that are dependent on performance in haskell and I feel very bad for not being able to do so without risking the loss of performance.

I know this is one thing.. but another one is, Artificial Intelligence. For the sake of haskell, it's closer to math than the other languages.. why not use it in an AI research environment??
---
It would be great if I could have a smaller but faster and stabler GHC with much less language features. I use only rudimentary language features (probably  "RankNTypes" is the most advanced) but compile time seems to take longer and longer as the GHC version number increases.
---
Slowly and carefully remove historic baggage.
---
More supported platforms by compilers, and tooling.
---
Tooling experience needs to improve. Pour  resources and energy into HLS. The stack/cabal storyline is a mixed weird one as well
	#!/bin/bash

	# Source: https://taylor.fausak.me/2021/11/16/haskell-survey-results
	wget https://taylor.fausak.me/static/pages/2021-state-of-haskell-survey-results.json.zip
	unzip 2021-state-of-haskell-survey-results.json.zip

	echo "Question: If you wanted to convince someone to use Haskell, what would you say?" > q1-convince.txt
	echo "---" >> q1-convince.txt
	jq -r 'map(.s9q0 \| .[]?) \| join("\n---\n")' < 2021-state-of-haskell-survey-results.json >> q1-convince.txt

	echo "Question: If you could change one thing about Haskell, what would it be?" > q2-change.txt
	echo "---" >> q2-change.txt
	jq -r 'map(.s9q1 \| .[]?) \| join("\n---\n")' < 2021-state-of-haskell-survey-results.json >> q2-change.txt