Introducing NeoHaskell: A beacon of joy in a greyed tech world

Links
85

IME, Haskell’s strength lies in managing complexity - but this is not something you can easily demonstrate to someone who isn’t familiar with the language already. Most examples of any programming language are of “introductory” nature, and hence, there is not a lot of complexity to them. A fibonacci function, a guess-the-number game, or even a To-Do-List webapp, are not complex enough to drive home where Haskell actually shines, and trying to do so tends to come across as thoroughly underwhelming to anyone who doesn’t already know what’s beyond the immediately visible horizon. “Hello world” in Haskell is simpler than its Java equivalent, but compared to Python, it’s still baroque, so if you judge Haskell based on that, then, well, Haskell is going to lose.

And there, I think, lies a more fundamental problem with making Haskell more attractive to newcomers. Of course there is some accidental complexity with Haskell, of course there are the usual warts and quirks, but I think the real issue runs much deeper. Languages like Python and Go sacrifice the “top end” in favor of the “bottom end”, that is, they give up a lot of advanced sound abstraction features in order to keep the initial learning curve shallow, and avoid overwhelming new learners with a truckload of new abstract concepts to learn. This, however, is inevitable - I don’t think you can have a language that so heavily relies on sound abstractions to boost developer productivity, and at the same time keep “abstract abstractions” to an absolute minimum.

One has to experience that power in the flesh, by working on a nontrivial project over a longer period of time, in order to fully understand the benefits.

What Haskell buys you over Python is not “I can reduce these 12 lines of Python to 9 lines of Haskell”, nor “look, if I pass a string to this 4-line function instead of an integer, I get a compiler error” - it’s rather things like making refactorings in huge codebases while being reasonably sure you’re not breaking anyhing, things like swapping information about the problem domain out from your brain and into the code, and swapping it back in just as easily, things like keeping code workable by having solid, compiler-enforced abstraction and scope boundaries, and of course also the type system reducing the search space for your informal and formal reasoning endeavors to a fraction of a unityped universe. You don’t get to capture these benefits in a 20-line code sample.

9 Likes
86

Sorry, can’t resist, but you can always enable UnicodeSyntax to reduce the amount of ASCII in your code…

5 Likes
87

I hope, and truly believe, that in this forum we can accommodate a diverse range of respectful communication styles whilst pushing back against disrespect, insults and rudeness. As far as I know this forum doesn’t explicitly adhere to the Haskell committee guidelines for respectful communication but I think they can serve as a useful standard for individuals to refer to if they want guidance in their own communication style, and to get a sense of what might be reasonable to expect from others.

People from different backgrounds have differences in communication style. People also differ in the way they receive communication. There is no one perfect way of communicating and I think that, in terms of respect, the intention with which a message is sent is more important than its precise content. I would ask everyone to bear in mind that on the other end of the messages they send is a human being with feelings, and to ensure that their intention is always to respect the feelings of the recipient.

5 Likes
88

As others have stated on this thread, there are a lot of misconceptions and branding issues with Haskell. Old problems and old attitudes still shape widely-held beliefs.

Therefore, the list you write here seems like perfect material to use when suggesting changes to the homepage of Haskell.org. If anything on the list isn’t actually a problem, or can be listed as a strength, then maybe we just need to communicate it better. Maybe Haskell does need a rebranding (a slow, thoughtful one – please don’t start from scratch), and Haskell.org is just sitting there waiting for suggestions. :wink:

10 Likes
89

You don’t get to capture these benefits in a 20-line code sample.

While true, part of my point is that Haskell can abstract far more aggressively due to its functional nature. A barebones web-server in my mind is just a tree that picks an endpoint and some HTTP/2 serialization, that’s two separate libraries and every extra format/encoding/authentication/cookie handler can also be completely separate. Having a batteries-included library where you can strip away layers to get near-infinite customizability would be different enough from the norm to warrant showing off.

3 Likes
91

But when the trying stops, that’s when you become Common Lisp or Smalltalk, a group of highly-skilled users with domain knowledge that has low relevance on the outside and has lost its capability for new research.

It’s a case where the social value of Haskell (a grouping of like-minded individuals with comparable skills and values) has eclipsed its value as a basis for research or production.

Here’s the fundamental problem.

Tooling isn’t going to magically sprout out of no where, and work on GHC requires not only people, but also money.

All of the work on the existing Haskell ecosystem requires labor, often from very talented people, and these very talented people have to be paid or pay by volunteering their time.

If you decide that Haskell is a niche language whose main value is social, i.e, for Haskellers to hang around with others of common interests and values, you’ll face a resource crunch for work on GHC and Cabal, because much of the work is being financed by Haskell Foundation, and Haskell Foundation is paid substantially by production.

What’s worse, a lot of these costs are exponential; i.e, the original typeclass concept was done in a relatively small span of time, while adding ergonomic dependent types to GHC has taken years so far and is still not done.

If pushing into production is no longer emphasized, Haskell Foundation’s donors will gradually deplete (whether they move to new languages, get bought out and pushed off Haskell, or go under), and who will then pay for work on GHC?

And then there’s the fact that other languages are free to copy features from Haskell as they wish; what we saw with Rust was a ML-style type system grafted to immutable-by-default variables in an imperative language.

The gap between Haskell and other languages continuously diminishes and makes it harder for Haskell to be viable in production, until ultimately, what you have is a Smalltalk; all the good ideas have been stripped off and there’s just a community of die-hard devotees. You may say the Haskell community is better for you than any other, but then it’s no longer a living language.

4 Likes
92

About the homepage, it might sound trivial, but I think the pretty landing pages of Rust and other ecosystems helped them a lot.

Would it make sense to outsource design work to build a more modern and thought-out website for Haskell? The websites we have are great and functional, but it shows that they were built by Engineers and less by UX or landing page copywriting experts. It might help a bit with the branding and public image.

5 Likes
93

Yes, I think there is merit to that idea, although I should point out that people have attempted broad rewrites in the past and it was met with a lot of resistance. But thoughtful application of good UX (including understanding who the audience is and what should and should not be highlighted) to incremental changes seems like something that could be successful. It would be worth exploring the idea as a Technical Working Group proposal.

(Well, I’m not sure if that’s the right place to suggest this kind of proposal, but they’ll know where to point you if not.)

1 Like
94

And therein lies the conundrum: as @maxigit noted earlier, if we’re not careful we’ll end up pursuing an target audience which isn’t really there.

1 Like
95

…prehaps most notably being the arrival of type classes in C++! More importantly though, designers of other languages can pick and choose what new innovations have appeared in Haskell. Therefore any advantage granted to Haskell by way of continual innovation also diminishes over time. But the same cannot be said about the cost of innovation.

As I noted eariler, each new language-extending innovation has to exist alongside all prior ones, which leads to an exponential number of language-extension combinations. In the absence of some wondrous advance in managing the ensuing complexity…the cost of continual language innovation will eventually be overwhelming. Any notion of “a balanced approach” to innovation must take that cost into consideration.

For the forseeable future, the only way to manage that cost is to limit the total number of language extensions, by:

  1. consolidation - widely-used extensions are brought into new Haskell standards,

  2. or elimination - the least-used extensions are eventually dropped.

4 Likes
97

You would need more that just separate compilers - all other parts of the Haskell realm would need to be replicated, possibly all the way to websites:

  • www.haskell98.org
  • www.haskell2010.org
  • www.haskell2020.org
  • www.haskell2027.org
  • www.haskell2032.org
  • www.neohaskell.org

…etc. Then the issue of ongoing support arises:

  • should that realm be based on an interpreter rather than a compiler?
  • should it only have CLI-based tools instead of GUI-based ones?
  • when should support for realms stop?

…and on and on and on it goes! It seems to resemble the ongoing development of an open-source operating system (sans the bootloaders and device drivers).

1 Like
98

I believe NeoHaskell might be focusing on the wrong challenges. To bolster Haskell’s adoption, what’s crucial is a thriving ecosystem of libraries tailored for business applications. More importantly, these libraries need consistent maintenance.

The economic dynamics of software development dictate that technology decision-makers often seek a balance between adopting the best technologies and avoiding risky choices that could potentially hinder business objectives. Why the emphasis on business applications? They constitute the bulk of SaaS and enterprise applications. Achieving a significant number of success stories in this realm will naturally lead companies to choose Haskell. Once these companies grow profitable and sizable, they are more likely to give back to the community.

To further underscore my point, I offer two illustrative examples:

  1. ReasonML: NeoHaskell’s objectives resemble those of ReasonML. ReasonML aimed to make OCaml more user-friendly. It boasted a distinct advantage: it could compile to JavaScript and had first-class support for React from the outset. Furthermore, it could tap into the expansive JavaScript ecosystem. But even with these benefits, ReasonML didn’t gain the expected traction. This suggests that neither ease of use nor the learning curve were the real barriers. The developers of ReasonML perhaps missed this insight, as they later rebranded to Rescript, distancing themselves from OCaml, functional programming, and any terminology unfamiliar to the average developer. Even this change didn’t have the desired impact, leading to some core Rescript developers leaving the project.
  2. Rust: Contrasting with the above, Rust, despite not being the simplest language to master, has witnessed significant adoption. This can be attributed to Rust’s early emphasis on showcasing its capability to develop applications across different domains. Initiatives like “are we web yet?” effectively communicated to potential adopters that Rust was a dependable choice. Once the job market for Rust developers increased, developers felt more compelled to learn the language despite its steep learning curve.
12 Likes
99

I had a moderately unpopular post to that effect on Reddit, but what we really need are more and better frameworks for common tasks. In my experience with using Servant and Monomer, often, with the right framework design, you can achieve all the necessary functionality without using any code in IO or some IO code generator (monad transformers, effect systems, free monads, etc) other than the framework itself.

There have been some posts to that effect by others; that there have been no “killer frameworks” in Haskell and that was what was holding it back.

As I’ve said before, the problem with Yesod was that it somehow presupposed knowledge of Haskell, whereas it should be possible to teach the framework first and then only as much Haskell as needed to operate the framework. Some of the publicity for Yesod suggest that Michael Snoyman realized that toward the end, and IHP selling itself as a framework for non-Haskellers was a significant step in that direction.

A framework-centric approach, combined with high-quality frameworks tailored for the target audience, might be what we really need.

The problem with this is that Haskellers don’t seem to like overly opinionated frameworks, but this kind of product is probably what the average programmer wants; no anxiety about choices or wondering about ReaderT vs MTL vs Free Monads vs Three Layer Cake vs Effectful, just follow the path on the HUD.

PS, also, three thoughts come to mind. If Haskell has achieved partially negative brand equity among a sector of tech leaders, the natural idea might be to rebrand, but that’s complex and difficult.

Instead of trying to turn Haskell branding around, sell IHP, sell Yesod, sell Hydra, sell whatever framework you can come up with and only mention it’s Haskell-based at the very end.

The framework-oriented approach also ties into Gabriella Gonzalez’s proposal in How to Market Haskell to the Mainstream Programmer; she identifies Haskell as a language very suited for building eDSLs, and consider the overlap between eDSLs and frameworks.

Lastly, I’m not sure if you’ve seen the comedy skit comment on some thread in Reddit, wherein the new CTO comes to axe the Haskell infrastructure at their firm, upon which the resident Haskell guru informs them that they are using the Monad for Medium to Large Enterprises, causing the new CTO to be enlightened, rainbows and stars showering upon them, and profits rising.

This is also a way to get rid of all the burrito monad tutorials flying around; if the marketing association with monad is now “business framework” (vaguely correct based on the eDSL interpretation), do we really need to correct them?

5 Likes
100

That was probably the biggest time-sink when we adopted Haskell, followed closely by figuring out an error-handling strategy.

1 Like
101

I think the biggest mistake adopting Haskell is trying to come up with standardization for such things right away. Especially when the team’s new.

Now, I get the “we need code consistency globally” argument (I guess). But if you commit to something early and force people to just go along with it, you end up not cultivating learning across your team.

If you’re working on some sort of SaaS-y web service-y thing, you can actually afford to allow people to experiment with error handling and the whole monad thing. You can start by standardizing on a config file format + a type to parse it. And a standard way to hook into main via IO or something.

But it’s fine if you have people working in different ways. Opportunities to unify things and reap dividends can only come after imo.

That’s just my 2c having seen a lot of these codebases grow in line count + engineers over the years. It’s a mistake I’ve seen often, and in the places where there were no standards from the get-go, the outcomes were better.

2 Likes
102

…often, with the right framework design, you can achieve all the necessary functionality without using any code in IO…

Real-world programming isn’t about having things convenient “often enough”, it’s about getting a task like “this endpoint should serve both a POST 200 and a PATCH 204, both with different argument sets” and not having to bend over backwards to fill it in.

servant’s approach, from my experience, is just unwieldy. Things don’t need to be packed into the type-level; the server endpoint either works correctly or it doesn’t, and you should be able to unit test that. I imagine things are even worse with yesod because their minimal app is TemplateHaskell over QuasiQuotes.

…the problem with Yesod was that it somehow presupposed knowledge of Haskell…

This pops up constantly for some reason: why do we care about people who don’t know programming getting all the tools to do programming without actually learning programming? (replace “programming” with “banking”, “art” or whatever the next marketing bubble drags in). More people doesn’t automatically translate to better software, in the short term it probably translates to more bad software. And I don’t know if all that many people would want to stay long without a solid ecosystem to support them.

…only mention it’s Haskell-based at the very end.

If Haskell is the weak link in your system, then why even bother with it? If your goal is winning a popularity contest no matter the cost, a relatively esoteric language isn’t gonna cut it. Especially when the committee clearly has issues coming up with solutions to seemingly mundane things, like record field access.

2 Likes
103

In response to the idea of standardizing early, we’ve extensively experimented—perhaps even over-experimented. Over the past three years in production, we haven’t settled on any particular effect system. We’ve transitioned from Polysemy to fused-effects and are even contemplating a switch to effectful. We’ve also switched our error-handling strategy multiple times. That’s why I highlighted effect systems and error handling.

1 Like
104

None of this is pointed at you, but I’d like to muse about a few of these.

Gate-keeping from what exactly? Being one of the cool kids on reddit? I see this one often from a few people on twitter, but I’ve yet to see a concrete notion of what this even means. It seems to mean something different to everyone I hear it from: “people don’t think my code has enough category theory vibes”, “people don’t seem to like me very much”, “people don’t roll out the red carpet for me”, “people don’t use my libraries”, “people don’t buy my book”, and “i’m not elevated to godhood within this community for the work I do” are the most common.

Many of these takes are unfathomably entitled, but when it comes to category theory in Haskell, I’m really not sure how to address the pedantry short of endless patience (which I do not have) and nodding my head in agreement at every little criticism that exists, and then ignoring the pedants and doing my own thing. The latter I’ve done rather successfully, and people really don’t bother me about it much in any case. I’m saying this as someone who helped contribute to a publication in the ACT field: having guiding principles is one thing, but for the love of god learn some statistics and understand the difference in utility between interpretable and flexible program models!

You’re welcome to just ignore people and create cool stuff and show it to other people who do cool stuff too. You can certainly show it to me! A thing I can run beats navel gazing any day of the week. I find that gatekeeping seems to arise near spaces where knowledge is a proxy for social status, but you’re free to ignore it as you please.

18 Likes
106

I think when people talk about gate-keeping, they’re talking about gate-keeping people, not ideas.

I think all projects gate-keep ideas to some extent (imo it would be pretty chaotic otherwise). An extreme hypothetical would be if someone came in and wanted to add arbitrary side effects to haskell. I imagine that proposal would get shot down pretty quickly.

idk if I would call disagreement over haskell extensions gate-keeping ideas either, I just think it’s just healthy disagreement (:

Also, take this for what you will, but I only hear about haskell’s gate-keeping problem from inside the community. I’m not saying haskell doesn’t have this problem (it very well might), but it might be worth looking into if we’re making the problem seem worse than it actually is.

2 Likes
107

Gatekeeping isn’t always a bad thing. Do you want everyone being able to make random decisions over GHC, core libraries or other parts of the ecosystem? Probably not. That’s why we have committees, processes, the HF to mediate etc.

As much as it can be a nuisance not being able to push all your ideas into every project, there might be reasons.

Open source is distributed. A maintainer of a library has no obligation to collaborate with anyone. You can fork and use their code. Be thankful they give you that permission (they don’t have to).

If you feel GHC SC/HQ, CLC or other major bodies/projects are being uncollaborative, please reach out to the Haskell Foundation. It can often be lack of time, miscommunication or other things.

7 Likes