Today, I’m proud to announce a (free and open-source) project that I’ve been working on for many years:
NeoHaskell, a dialect of Haskell that prioritizes newcomer-friendliness and productivity.
I embarked on the NeoHaskell project fueled by a diverse array of motivations. I see Haskell as a supremely potent language, leading the frontier of software development due to its inventive and meticulously crafted nature. However, its potential seems overshadowed by intricate details and a community primarily focused on resolving theoretical academic and mathematical challenges, often overlooking pragmatic solutions, which can be overwhelming for newcomers. Based on my experience with incorporating Haskell into production for two years and the subsequent transition to TypeScript due to escalating complexity, I recognized a critical need for a language that could refine software development while preserving the groundbreaking aspects of Haskell. This realization, coupled with the challenges encountered in the software development sector, inspired the creation of NeoHaskell. Through this initiative, I aspire to develop an optimal programming language and ecosystem that eradicates accidental complexity, either in mental form, or in code form.
This is a language for those who have just too many things in their head and they want to release their ideas, but don’t have the time to commit daily to maintain the required context of their projects in their heads. For those who want to play and have fun while producing awesome software, regardless of their experience, background, or interests. And for those teams that, inevitably, are high-rotational (either internally in the company, or externally) but want to be productive and happy while performing their craft.
A language? A dialect? What do you mean?
Depending on who you ask, a programming language can be different things. If you ask the Haskell community, many will tell you that the language is the Haskell specification, and that what currently is being used is not Haskell itself, but an extension of Haskell that is supported by the GHC compiler. Similar to the C language, a programming language would be a specification.
Other people might tell you that a programming language is the result of the supported features of its compiler, like Rust, which keeps evolving with time.
I personally think that a programming language is the result of the agreement of its community on tools, libraries, patterns and practices. I hear folks saying “he didn’t learn Python, he is programming in Java in Python”, which is the affirmation of this.
NeoHaskell exploits this philosophy to establish a parallel universe in the Haskell ecosystem, piggybacking the extremely good tooling and libraries that are already there, and were there for a long time. It establishes completely different patterns, practices, naming, and even approaches to code that would be considered heretic in Haskell.
The solution is not having more hands implementing more features, the solution is to stop. And prioritize as if this was a product.
This is not a priority for the Haskell community, and that’s the point:
NeoHaskell is not Haskell, it’s a parallel universe built on top of it.
What’s the goal?
NeoHaskell’s core mission is to provide a seamless, productive ecosystem for joyful software development. It’s designed to guide developers toward faster, more reliable releases, through a concentrated effort to alleviate cognitive load, by removing unnecessary complexity and decision making.
We welcome developers from diverse backgrounds, including backend and frontend development, data analysis, mobile development, game development, and whatever you can image. While simplification of the development process is a priority, NeoHaskell also emphasizes the importance of improving developer satisfaction by incorporating structured architectures to reduce decision making even more.
NeoHaskell’s vision is to render the development process more user-friendly and enjoyable, enabling users to realize their ideas effortlessly and efficiently. It wants to transform the development experience, making it feel more like “play” rather than “work.”
Why not just documenting Haskell?
If you think in a programming language as the subconscious agreement of its community, the key part is the way of working and approaching programming as a group. In the same way that the Java community is used to work in a way by defining factories, beans, etc… The Haskell community is used to work in their own way too. It is not wrong, or incorrect, they have their own goals.
The issue is, that documenting technology is easy, changing the minds of an entire community is not.
I’m a single person trying to fix the world. I have limited time and energy, and I don’t want to be changing the views of anyone. I’m doing this in my free time, time that I dedicate to be more happy. Convincing people doesn’t make me happy.
I’m building a wagon that is open for everyone who wants to hop on and support it, but I don’t want to deal with people that don’t.
I want to establish a new concept so it is easier for newcomers to find resources and get up and running in the most effective way possible, all while feeling unstoppable because they’re using a tool that they love.
In response to any skepticism from the Haskell community, I understand the seen sufficiency of Haskell in its present state given their context and experience. Most of them are very smart people, and great professionals, and they are completely right to think in that way.
However, when considering individuals with diverse approaches to software development, like those viewing programming languages as tools, or those valuing release speed over perfection, including early-career developers with abundant creative ideas, the priorities noticeably shift.
NeoHaskell is focused on enabling swift and assured releases, valuing user-friendliness and practicality over aspects like precision, code accuracy, and complex type-level code for the sake of perfection. The project recognizes that developers have varied needs, and it commits to catering to those prioritizing efficiency and feasibility in bringing their visions to life.
What are you trying to solve exactly?
There are too many entry points to a simple task as running your code, such as plain GHC, Cabal, Stack, Nix, etc., each presenting its learning curve and absence of a recognized superior option. The environment is further compounded by multiple language extensions and different frameworks handling side effects. These, combined with the daunting mathematical concepts in the language, often discourage newcomers.
Not even mentioning even more niche workflows like mobile apps, web apps, and even game development, that are there, but are hidden deep down under layers of accidental complexity.
NeoHaskell counters these challenges by introducing a unified CLI tool that simplifies everything, from installing the required compiler to managing packages and running tests. It streamlines all the different workflows through official templates, so one can get started right away with the task that they want to do.
We aim to support newcomers by providing analogies to other languages and featuring these in the documentation to facilitate comprehensive learning, while renaming or discarding terms that would be unnecessarily complex for newcomers.
How are you trying to solve it?
NeoHaskell’s development is centered around the principle of catering to its community, the NeoHaskell community, avoiding the trap of chasing unrealistic perfection and ending up with an unused product after years of development.
The main goal is to create many different pieces:
- A remarkable standard library
- An integrated CLI tool with precise error messages
- Templates with planned architectures
- Documentation with a set of recipes
- Mobile app packaging
- Python interoperability
- And many more
These objectives, though ambitious, are attainable by delivering small increments and focusing on fostering one essential element: developer joy.
Rather than promoting the creation of new architectures and the innovative use of advanced features, NeoHaskell favors well-established patterns in the software industry and embraces functional programming where appropriate, allowing for imperative code where it’s more suitable. Comprehensive documentation, a supportive Discord community, and a philosophy of “if it takes more than 15 mins to figure out, it is a bug” are the key points to ensure the success and happiness of its users.
One of the key ideas of NeoHaskell is to reuse as much technology as possible, while staying in the realm of NeoHaskell. This approach opens up many paths, and leads you very far. Our goal is to be happy while coding what makes our project different, not all the bullshit that just gets in the way. If your goal is to make a todo-list mobile application in the most joyful way, using NeoHaskell, you shouldn’t think at all in how the rendering of the view is actually implemented. Even if the mobile app is a React Native renderer of HyperView XML views that are retrieved from a 100% NeoHaskell backend, as shown in this tweet:
// Detect dark theme
var iframe = document.getElementById(‘tweet-1700859705021571543-47’);
if (document.body.className.includes(‘dark-theme’)) {
iframe.src = “https://platform.twitter.com/embed/Tweet.html?id=1700859705021571543&theme=dark”
}
When you approach development like this, by doing concessions, instead of closing doors, you open up the door for innovation and improvement, while maintaining a healthy and productive ecosystem. The other way around, you end up with a wasteland filled of gardeners ensuring that someday, the plants will grow exactly in the perfect way that they want.
How does it piggy-back the Haskell ecosystem?
NeoHaskell preserves 100% compatibility with Haskell, seamlessly integrating existing packages and tools designed for Haskell. However, its goal is not to be backward compatible. It will refine several elements from the Haskell standard library, with functions being renamed, certain operators being concealed and new ones introduced, and type classes being restructured to ensure their practical applicability, if they are applicable.
NeoHaskell will actively utilize compiler plugins to modify the compiler’s behavior to align more with newcomer friendly messages and features. It will maximize the potential of existing libraries, sometimes through encapsulation or re-exportation, as well as the usage of all the plethora of great CLI tooling that exists for Haskell.
How will be the design and priorization process?
I believe that in order for a product to be successful, the design process must be centralized in a single person. This person must listen to the users, the other designers, and in general must have an open mind to always cherry-pick all possible ideas in order to improve the product. I don’t believe that a product should be guided by democracy, and neither it should implement all suggestions by every user. In other words, I’ll be the one in charge of generating and listening to discussions, and prioritizing the features of the project.
I understand that this comes with some risk, but at the same time I believe that all programming tools like Python and Ruby that are very loved by their communities are like that because of the BDFL model.
NeoHaskell’s development will be open and transparent, marked by continuous sharing of progress and regular updates. My biggest priority is to maintain the community informed and aware of my vision, not getting into some kind of spiritual retreat to code while everyone thinks that the project has stalled and I have disappeared.
Anyone interested can contribute by participating in discussions on Discord and GitHub. Contributions go beyond code, the most important part is the design process, and that can only be achieved through communication between the members of the community.
I want to contribute, where is the code?
If you’ve read “the project that I’ve been working on for many years” as “the project that I’ve been coding for many years”, I’m sorry to disappoint you, that is not the case.
I’m glad that it isn’t, because that would have been a complete mistake. Design is a thinking process, is a communication process that goes back and forth. It is about talking to people, listening to every conversation with an open mind. Getting into tasks that you don’t like and doing them for the sake of understanding what’s going on, what are the users doing, and what is this thing that could improve their lives.
I didn’t code NeoHaskell, instead I wrote TypeScript, both for backend, frontend, CLI tools, infra-as-code, and many more things. I worked with enterprise clients whose teams are so big and the team member rotation is so high, that every little code pattern had to be stitched in the exact same way so there were no surprises when team members rotated. I coded plain Java, as well as Python, in the most boring and bland way possible. All of that, taking notes and gathering insights for NeoHaskell. That is the real work. Getting all these puzzle pieces that are spinning in a tornado around you, picking them up, while attempting to stay on the ground and assembling the puzzle.
There’s this thing that people call “Haskell curse”, which is the feeling of disgust for using other, inferior, technologies that aren’t Haskell.
NeoHaskell lifts the curse. Every interaction with technology and users from other ecosystems becomes a blessing, and an opportunity to understand what makes us happy as software craftspeople. Every frustration becomes a leverage point to create the most awesome language, ecosystem, and community ever in the world. So, check out the website, join the Discord, and hop into the project’s GitHub, this is not possible without you (literally).
Afterword
Writing this post was not easy at all. I’m very happy that this project finally sees the light, because I truly believe since the day I discovered Haskell in that old dusty book in my faculty’s library, that it has the power to be the leading language in software industry. You cannot imagine how many different attempts that I’ve tried, how many prototypes I actually wrote, and how many conversations I had with developers who thought that Haskell is just hipster bullshit that is not useful at all.
If you’ve read this far, let me thank you from the deepest part of my heart, even if you don’t believe in this project, or you’re not interested, and if you are, have this huge virtual hug and let’s chat! I’m eager to talk with people that are interested in this idea.
NeoHaskell may evolve as a specialized community or may blossom into something more extensive and mainstream.
My hopes are humble: for it to serve as an invaluable resource enabling the community to experience continual satisfaction, and for it to encourage the Haskell community to emphasize practicality and inclusivity.
Thank you, really,
NickSeagull
