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

[BurningWitness]

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

[shinzui]

@Ambrose

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.

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.

[emilypi]

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

@jameshaydon

snobby gate-keeping by current Haskell community

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.

[nemo]

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.

[hasufell]

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.

[emilypi]

I’m astonished you have no awareness.

I’m astonished that you seem to have stopped at precisely the first line and failed to read the rest. How were you gate kept and from what exactly? John was extremely respectful in answering all of your queries. He has a point of view, too. It seems to me that if you felt “gatekept”, then you felt gatekept because you met up with a worldview that didn’t match your own and that was frustrating. But I see nothing in here which could be construed as insulting, or gatekeeping other than the insertion of jargon, which you already knew! How then are you being gatekept? This is the sort of entitlement that I’m talking about above: you are neither entitled to everyone’s agreement, nor are you entitled to have everyone speak to you in the manner in which you want to be spoken to.

The world just doesn’t work like that. If you want people who think, feel, speak, and write in the same manner that you do, find an echochamber, write a diary, or train a chatgpt bot on your posts. Otherwise, you are insulting everyone in that thread who took the time to engage you in collegial debate.

[vanceism7]

I ended up going on a rant, so I’m just gonna put a little summary here at the top…

TLDR: We need more people championing and working on the “smaller” issues like duplicate record fields/namespaces,cabal add <package>, and better documentation/business focused packages.

Rant following below.

---

I do have one (maybe unpopular) thought to offer here thats in agreement with @AntC2. He made a comment here saying:

DH has sucked all of the air out of the room
…
I want it to take the language as at 2016 (Pattern Synonyms) and continue all the half-finished other stuff – like FunDeps with Overlapping, a records system, Datatype contexts done

It’s not that I dislike dependent haskell; on the contrary I think it’s really cool and I look forward to finally seeing it arrive. But I think there were issues more important to work on than DH, atleast as far as helping haskell become more mainstream is concerned.

Haskell is a powerful language, but it has some very annoying quirks, like the duplicate record fields issue, or having to dive into a cabal file to add dependencies instead of just calling a command like cabal add <package>.

I recognize that these issues are not “major” problems and can be side stepped atleast relatively easily, but they are annoying. Annoying is the evil twin brother of convenience, and if I’ve learned anything from Google (anecdotally confirmed by my own experience with my colleagues), convenience is far more pursuasive than power. In my own job, I’ve recommended powerful tools over and over again, only to have them bypassed for an inferior tool that was way more convenient to use.

If our community put as much effort towards fixing the annoying issues as it has towards the large milestone issues, we’d probably already be atleast heading towards greater growth.

---

For example:

John Ericson is currently advocating for the pattern signature proposal here. I don’t mean to be dismissive of his efforts, but I don’t believe newcomers would care much for this. I surely don’t understand it too well and I’ve been using haskell for a good while now.

Richard gave up on the Local Modules Proposal because “there are other battles to fight!”

Perhaps this is why people say we’re more focused on academics than on being practical? I assume fixing issues like record dot syntax (fixed already), local Modules, and improved tooling like cabal add <package>; are low hanging fruit compared to something like DH, or improving the architecture and organization of ghc. But we’ve put all our efforts on the huge things and neglected the little ones.

I didn’t even consider haskell viable for serious use until HLS and RecordDotSyntax came into the world, but haskell has obviously been viable for a long time now. I also think D is a really cool language, but it’s language server is very buggy so I dismissed it. Zig is a cool language, but they have no package manager, so I dismissed it. I don’t mean to be this way but I can’t help who I am, maybe it’s because I’m immature. But I think this is what we’re up against when other programmers in the greater community look at haskell and see annoying issues that arent fixed. They’re quick to dismiss.

Sorry for the rant! I hope my thoughts have come through clearly

[tomjaguarpaw]

If you think there are features that need to be added to the Haskell ecosystem then the only thing to do is to continually advocate for them, and advocate in an effective way, such as making connections with the maintainers of the corresponding tooling and entering a dialogue with them.

[vanceism7]

I agree, we all have to do our part. That’s why I’m working to finish up the Local Modules Proposal. I just hope we can get more of the community rallied around fixing up some of the smaller issues. (Atleast I hope they’re smaller, I know sometimes things that seem small are actually a bigger deal than they appear)

[AntC2]

@emilypi

John was extremely respectful in answering all of your queries.

Thanks Emily, yes let me say straight away John has been entirely respectful and patient in his responses. There are other comments though.

(To go back to your earlier remark:)

@emilypi

It seems to mean something different to everyone I hear it from …

In particular, ‘gatekeeping’ is a matter of perceptions. Those long-experienced and ‘inside’ Haskell might not perceive the Haskell community in the same way as newbies who drop in for a ‘taster’ but leave fairly quickly.

Anyhoo, my comment has been disappeared, so I’ll stop.

[tomjaguarpaw]

@vanceism7

That’s why I’m working to finish up the Local Modules Proposal

That would be amazing!

I just hope we can get more of the community rallied around fixing up some of the smaller issues.

Totally agreed.

[atravers]

@vanceism7

Haskell is a powerful language, but it has some very annoying quirks, like the [absence of a records system the majority of Haskellers can be less unhappy about, …]

@tomjaguarpaw

If you think there are features that need to be added to the Haskell ecosystem then the only thing to do is to continually advocate for them […]

…are we records yet?

Here is an early non-strict language implementation:

https://github.com/haskell-implementations/hbc/tree/master

It implemented a simple form of records/named fields:

binding:  funs				{ $$ = mkpbind($1); } |
	  TYPE typename EQ LBRACE comps RBRACE { $$ = buildrecord($2, nrev(&$5)); } |
	  TYPE typename EQ constrs	{ $$ = mktbind($2, $4, mkinone()); adderrinfo(gtypeid($2)); } |
          TYPE typename EQ EQ type      { $$ = mkebind($2, $5); } |
          id DCOLON type		{ $$ = mksbind(lsing($1), $3); } |
	  CONCTYPE typename EQ cconstrs { $$ = mkgbind($2, $4); } | /*conctype*/
	  binding AND binding		{ $$ = mkabind($1, $3); } |
	  REC binding			{ $$ = mkrbind($2); } |
	  LPAR binding RPAR		{ $$ = $2; } |
	  LOCAL binding IN binding END	{ $$ = mklbind($2, $4); }
	  ;

hbc/src/syntax/lml.y

…are there any volunteers for making this work in Haskell?

[AntC2]

@hasufell

Do you want everyone being able to make random decisions over GHC, core libraries or other parts of the ecosystem?

No I don’t. In particular I don’t want to threaten type safety, and I’m well aware I’m not expert enough to tell if a proposal might do that, so I defer to those guarding overall integrity of the ecosystem.

The particular decision at hand (and here is not the place to discuss it) is partly something GHC is already supporting (with enough flag settings), partly something it supported in 2006, so it can’t be threatening type safety.

[AntC2]

@atravers

are there any volunteers for making this work in Haskell

A version (of a non-strict ML-style records/named fields) has been got working by a volunteer in a Haskell.

Heh heh I tried searching for the fake link in that post, first GHit was ‘Is Haskell a dead language’/5 dead programming languages we should never forget.

[atravers]

@AntC2

A version (of a non-strict ML-style records/named fields) has been got working by a volunteer in a Haskell.

…and you of all people should know that these days, if it ain’t in GHC, it ain’t anywhere. That’s one reason why dependent types aren’t being implemented in Hugs ;-)

[BurningWitness]

…are we records yet?

With how rare I need proper records I feel like this issue could just be solved with an extension that allows deriving clauses that run Template Haskell without weird splice restrictions. It would solve all the “too expensive to do this everywhere” concerns at the very least.

[atravers]

@emilypi

[Gate-keeping] 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”,
• “I’m not elevated to godhood within this community for the work I do”

…are the most common.

…or in other words: there’s no such thing as The Average User^TM. But there is a thing called Haskell and like most things, it could be better in various ways. So to all the people who bounced off Haskell “way back in the day” (or more recently): Haskell hasn’t been “staying still” regarding tooling, so grab a copy of the sources that interest (or annoy!) you the most, and join in!

Open source software isn’t just “a spectator sport”…

[bradrn]

I completely agree with this comment. Haskell is a great language, but it’s not convenient by any means.

I have a lot more to say, but it’s long, so I decided to split it off into a separate thread:

Convenience in the Haskell ecosystem

I read this comment in the NeoHaskell thread, on convenience in the Haskell ecosystem: As it happens, I got a taste of some of these issues just yesterday. I thought I’d write up my experiences here, in the hope of spurring some discussion on these points. My motivation yesterday was wanting to do a spot of data analysis. Nothing complicated: essentially, I just needed to plot some fields from a JSON file. I first tried to do this in Haskell. The steps involved were, as I recall: cabal in…

[nexio55]

@tdammers

And there, I think, lies a more fundamental problem with making Haskell more attractive to newcomers. … 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.

This is really relevant. Commenting here in general, not specifically to the author. Two thoughts:

1. Suppose Haskell intentionally avoids those mainstream developers, that huge middle of the curve, those regular folks who don’t care about deep abstraction. If we ignore them, then we’ve sacrificed the largest pool of potential contributors and advocates, and our community remains minuscule.

   Compare that scenario with Python: There’s an enormous wealth of large, active packages (graphics, web stacks, databases, pandas, numpy, essentially all of AI, etc.) And we’ve sacrificed the great wealth of a large community, like the rich trove of stackoverflow answers and tutorial blogs with live code samples. Python won because it attracted thousands of talented people.

   If Haskell wants to be a narrow niche for the top end, then we should be absolutely clear about it, so that people can rationally choose. Broadly, we shouldn’t waste anyone’s time because that’s the ethical thing to do, and because we avoid creating more anti-Haskell sentiment.

2. On the inability of a language to satisfy both worlds, we should actively question that assumption. This is a worthwhile topic for the research community. Simple Haskell, NeoHaskell, and related initiatives proves there’s passion and demand for extending the bottom end.

   People working in the top end benefit too, if only because the big mainstream now needs and appreciates their expertise! Think of all those career-boosting up-votes!

So if Haskell did satisfy both ends, and if all those mainstream people came here and grew the Haskell ecosystem, isn’t that a win?

[atravers]

https://stackoverflow.blog/2023/07/21/what-its-like-to-be-on-the-python-steering-council-ep-592 (transcript)

…is there a “Haskell [language] Steering Council” (or approximate equivalent thereof)?