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

[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)?

[vanceism7]

@nexio55

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.

FWIW: I don’t believe having a “high ceiling” and a “low bottom” are mutually exclusive goals. We’ve just focused more on “raising the roof” than “getting down with the boogie”… ahem… I think with more effort we can make the language a lot nicer for newcomers and still happily have crazy advanced features like DH.

I myself happily use Haskell all the time without using anything more than ADTs and monads. I only just recently delved into effects systems. I touched lenses once but I usually don’t need them.

[atravers]

@vanceism7

I think with more effort we can make the language a lot nicer for newcomers and still happily have crazy advanced features like DH.

…like in a programming-language introductory course: start with the basics, leaving the the more advanced features for later (or another course altogether). For example:

(page 7 of 19)

Learning how to do I/O should not be a prerequisite to learn the basics of programming nor to take your first steps into the world of Computer Science.

Functional Video Games in the CS1 Classroom (2010)

So how “newbie-friendly” is I/O in Haskell?

• Olaf Chitil:

  The most difficult construct for students to understand is the monad. I introduce IO without mentioning monads.

  Haskell in education (2006)

• (page 2 of 6)

  In the first iteration, I/O was covered toward the end of the course because it is connected with the advanced topic of monads. […] we [subsequently] moved I/O to an earlier point in the course. We also dropped monads, since the majority [of students] had not grasped them.

  Experience Report: The Next 1100 Haskell Programmers (2014)

• (page 3 of 21)

  The [decision to split off I/O from monads and introduce it earlier] is done in an effort to convince students more quickly that pure functional languages can be practical and deal with side effects.

  Engaging, Large-Scale Functional Programming Education in Physical and Virtual Space (2022)

…perhaps other options for I/O should now be seriously considered.

[Liamzy]

One thing I’ve proposed is that we should stop saying monads, or at least be more clear as to what we’re referring to.

For instance, are we talking about monadic types (or type constructors, more strictly)? Are we talking about a particular monad instance? Are we discussing Monad, the typeclass? Maybe we’re talking about an essentially monadic form of programming, like JS promises? Or, perhaps, we’re actually discussing category theory.

Be specific; if we must talk about a type as a monad, call it the foo monadic type, if we’re talking about the instance, call it the Monad instance for bar, etc…

---

Going further than the suggestion in this link:

IO Monad Considered Harmful

We should simply stop calling foo a monad whenever possible, and refer to it simply as a type when simply calling it by its name won’t do, and call it a monadic type when we are talking about the set of monadic types. This helps build intuition for the fact that there are many monads, and the commonality is their lawful instancing into the Monad typeclass, but are really quite different (unless you understand them as effect providers).

---

The other side effect is if learners get taught calling it a monad is wrong, or out of date, they also get instantly disconnected from the monad tutorial ecosystem, building intuition about monadic types at the same time we tell them to stop reading the freaking monad tutorials.

[vanceism7]

I don’t personally find Monads to be all that scary or difficult of a concept, and (if I may) I don’t consider myself to be particularly smart (im probably quite the opposite). Functors and Monads are just function transformers. I think you can teach the intuition for these concepts pretty easily just using some simple concrete examples like

fmap :: (a -> b) -> f a -> f b

-- concrete
maybeMapper :: (String -> Int) -> Maybe String -> Maybe Int

And so on with some dead simple examples. It’s easy to see the pattern happening here when it’s framed this way.
The only thing that tripped me up when I learned these was that I was so used to OOP, I had this notion of being “inside” of a class, and I couldn’t understand how I could use monad/functor functions without being “inside” of some type of class.

But I believe this difficulty always comes when learning a new concept, it’s no different than learning how to use variables for the first time, or for loops, or functions. I also recall having as difficult of a time (as monads) learning to use functions like foldl.

I have a friend who’s an accomplishment C++ programmer but a bit afraid (or atleast shy) of FP, and when I attempted to teach him monads, his confusion seemed to be more like “that’s it?” I don’t believe he ever internalized the concept but it was only because he felt like there was more to it than I had told him. It was like he was suspicious that I had lied to him and so refused to believe it. Or that it was so simple, it wasn’t worth remembering.

Anyways, my 2¢!

[jhenahan]

I find myself being very careful at work to say “X admits a Monad instance” rather than “X is a Monad” (and so on for other type classes).

[atravers]

@vanceism7

I don’t personally find Monads to be all that scary or difficult of a concept […]

(source)

---

@vanceism7

But I believe this difficulty always comes when learning a new concept, it’s no different than learning how to use variables for the first time, or for loops, or functions.

…yeah, about that:

(page 2 of 17)

Still, today, over 25 years after the introduction of the concept of monads to the world of functional programming, beginning functional programmers struggle to grasp the concept of monads. […] From our own experience we notice that even at university level, bachelor level students often struggle to comprehend monads and consistently score poorly on monad-related exam questions.

Considering that the concept of monads is not likely to disappear from the functional programming landscape any time soon, it is vital that we, as the functional programming community, somehow overcome the problems novices encounter when first studying monads.

Visual Support for Learning Monads (2017)

…failing that, alternatives ought to be considered.