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

Links
#42

Yes, exactly, and peoples’ perceptions and beliefs are their reality. If I believe that GM makes the best cars and Ford doesn’t, that’s my reality and I’ll buy GM every time. And if I ran a big commercial fleet, I’d buy thousands of GM cars each year. Now my beliefs are affecting macro-scale properties of the system.

When I’ve tried introducing Haskell to developers, their pre-existing perceptions are awful and it’s a non-starter. It’s easy to understand their thinking, shaped by cultural and intellectual snobbery like A monad is just a monoid in the category of endofunctors, what’s the problem?

No open-source community wants that kind of branding.

4 Likes
#43

While it’s possible some of these people who are turned off by “snobbery” were actually “wronged” - it’s also equally possible the perception is more on them than on this relatively small internet community.

Just because someone feels bad doesn’t inherently mean they have a good point.

Anecdotally, Haskell was equally (or more) “snobby” when I found it around 2013. I just…didn’t care? I still butt heads with people in this community and sometimes it’s due to techno-cultural differences (which I could call “snobbery” if I were being uncharitable). That can get me a little huffed lol… but I don’t flip the table and call an entire decentralized & highly diverse programming community snobs. If I did, I’d be the problem.

8 Likes
#44

I have posted ideas and requests for feedback a number of times. A couple of times I have seen my and others’ posts be bombarded with aggressively-toned and disrespectful messages.

Suggesting someone’s work reads as AI-generated is not a cultural or background difference, it’s dismissing a person’s work. I think not doing so transcends culture.

This thread has been sidetracked by a minority of unnecessarily combative messages.

Such threads are a large part of why I don’t participate any more. And it seems clear that the NeoHaskell developer is also not going to be part of this community either, for similar reasons.

In my opinion it’s not good enough, and something should be done to fix this problem of hemorrhaging excited devs.

7 Likes
#45

Does anyone know where I can find the source code to this language?

Their github seems empty and I don’t have nor want to join discord.

1 Like
#46

Read author’s note.

Tl;DR

This is a declaration of intentions. The author wants to create sort of a “dialect” of Haskell in a certain way which helps beginners to grasp the language easier (from author’s POV). At the moment there is no (public) code, but there are design ideas in the repo an web page.

Sure a honorable attempt, in my opinion, too much of a challenge. I’d be glad if author proofs me wrong though

6 Likes
#47

Oh my bad, the present tense used on their website made it seem like they already had a working project with certain features already built into it.

Wouldn’t it make more sense to have something more than just ideas down before marketing it though?

1 Like
#48

It’s pretty standard start-up land practices, i.e, sell vaporware, hopefully deliver the product before you get sued for fraud.

The more impressive thing is the immense amount of interest this vaporware has generated; i.e, even if NeoHaskell doesn’t turn out to be a thing, someone is going to try to do a project like this, because there is a market for a dialect of Haskell that provides substantial onboarding advantages over straight Haskell and is more suitable for the average programmer.

I think, if you are interested in the product, it’s a good idea to kibitz around, trade notes, keep the discussion alive, and if the product dies or quickly becomes a disaster, look for like-minded people to try again, except with the lessons learned from NeoHaskell blowing up.

4 Likes
#49

Yes, it’s wonderful that it demonstrates such interest in Haskell becoming more accessible.

4 Likes
#50

…provided it isn’t at the cost of “trading away” basic features which make Haskell, well Haskell - the features which probably helped to bring Haskell to the attention of those new and excited people to begin with.

2 Likes
#51

+1 to this. There are inherent reasons Haskell is not as beginner friendly as Go or Python.

In fact, I’d argue that beginner-friendliness is not free! There are improvements to be made to tooling and the language, sure. But it’s not inherently bad for a language to have a much harder learning curve than the mainstream.

It’s actually a benefit from my perspective. I chose Haskell precisely because its ceiling was so high. I knew I was gonna be building software for a long time, so I intentionally avoided beginner-friendliness in favor of ceiling.

I generally have a distaste for “product-ized” software, and product-ized PLs even more so. Thank god for avoid (success at all costs). That mantra is truly A Beacon of Joy in a Greyed Tech World.

7 Likes
#52

That’s sort of the point of having a dialect or a sibling language, no? As long as you can get back the basic features that make Haskell Haskell via importing a Haskell module, what is the problem?

The more worrisome thing is how some core features of Haskell come from the removal of features, including the lack of ergonomic and performant mutation.

These are things wherein you can’t simply “fix the brain damage via imports” because they cannot be remedied by addition, only absence.

In a sense, absence of features is probably the most important feature of a modern language these days. If being able to add features was all it took to become a great language, C++ would still be a fully dominant language, and Lisp would have taken over the world.

In that sense, an opinionated language like Haskell that wishes to force a particular idiom has advantages over more multi-paradigm languages by being able to tell you what you can’t do, or can’t do ergonomically.

#53

132 is a lot of nobs for configuring a compiler. As a user, it’s also overwhelming when there is too much choice.

2 Likes
#54

Seems like the author wants to create a fork similar to Neovim and Vim (hence the name) and the fact that he says “NeoHaskell is not Haskell, it’s a parallel universe built on top of it.”, the issue arises when the fact the structure of both projects are nothing alike with Haskell being democratic with a non-profit behind it while Vim was(is?) the opposite therefore a fork made sense.
As a non-Haskell expert, I do agree that language extensions are intimidating but trying to make a public fork is not the way to go in my opinion.

#55

It’s not as bad as 2^132: some extensions imply other extensions.

Specifically, Haskell started as a research language (I’m not sure if it still calls itself that). Some extensions were at first ‘experimental’ and/or unstable and/or likely to change in future releases, so you wouldn’t want to introduce those into production code. A few extensions change the meaning of existing code – rather than enabling extra syntax with extra functionality; so you wouldn’t want those switched on by default/without giving the programmer the chance to review.

And some extensions really represent different approaches to arriving at the same objective (FunDeps cp TypeFamilies), so they’re down to a choice of style. (There’s an argument to say that for stable features, all should be enabled á la GHC2021, with a system of warnings: hey this code is using FunDeps but you’re usually a TypeFamily dude.)

#56

I’m not enthusiastic about this project because the author has not specified anything about how that work will be done, nor even concretely what will be delivered. Remember: any call to action for open source work means that one must inevitably accept volunteers to work on the project. This raises many questions. For example:

  1. How will these volunteers be protected so that they don’t burn out?
  2. How will these volunteers be compensated (if at all?)
  3. Who is guiding the project direction?
  4. Who owns what and what’s the licensing schema if they do volunteer?
  5. What are the concrete deliverables?
  6. What kind of volunteer is desired? Who will be considered as SME’s as projects are built?

Surely the author doesn’t believe that people will join on hopes and dreams, and to succeed one needs to attract people who can move the needle in a meaningful sense in the direction of this manifesto. As someone who has maintained libraries ranging from 5k stars on github down to small projects like clearing the way for Andrew to do the text-2.0 work, every one of those projects involved a discussion of contributor standards and most importantly an execution of those standards according to the ethos of the project. This is why I have a CONTRIBUTING.md in every one of my projects in which I accept volunteers and a code of conduct in all fora and repositories that are going to have more diverse stake in contributing shoulder-to-shoulder without my direct involvement.

If this work has not been done, and the author has not thought about how their community will be structured, it represents an abuse of the idealism and positivity inherent in the manifesto: it exposes everyone working on the project to unnecessary risk.

Contrary to popular belief, I do in fact, sympathize with the Simple Haskell and Production Haskell movements - I think they’re necessary for moving Haskell forward and sustaining the exponential growth curve we need to survive (this is, fwiw, why i focus on low-level and mundane utilities that benefit everyone, and save the research for my personal work). However, for every manifesto, I’ve yet to see an actionable structure that can really make an impact. This is why Haskell Foundation was built; to move the needle as best we can with a funding structure that could have the real impact we want, without (ideally) inflicting the worst of what volunteer martyrdom does to this community.

Good luck to everyone working on the project, but I can’t see it succeeding. The work just doesn’t seem to be there, and the onus is on far too many undefined variables to make it succeed in my view.

18 Likes
#57

I got to say, from the web site, the author seems to have a very good idea about the goals. I think the project lacks concrete implementations. Once, I plotted a dramatization of haskell’s learning curve, and I think such a learning curver isn’t avoidable. No matter how easy you make tooling, libraries, frameworks, etc…, at the end of the day thinking purely functional is very dificult. So any attempt to make haskell “easy to beginners” ends up facing with reality: haskell is as difficult as learning programming is, and you must re-learn programming to learn haskell. I wish someone proof me wrong, but within my limited experience introducing Haskell, this isn’t the case.

PD: The author says that if this isn’t succesfull, at least it’ll be fun. 100% agree with this. As long as you get fun, it is alright, and you shouldn’t give up whatever bad comments are by random internet users, because it is you own fun at the end of the da. :slight_smile:

5 Likes
#58

I didn’t mean to come off that way with my comments, my apologies.

1 Like
#59

Heh heh. I think I hiked up to the ‘plateau of confidence’, picked up enough about monads to use them without really understanding all the theory, and sat down on the gently sloping uplands with my thermos of tea.

One data point: I learnt programming with procedural languages (BASIC, Fortran, COBOL, … a little LISP at college but noting the distaste for gotos and assignment); then went into packages and systems implementation, so I was programming-adjacent but missed out on the whole OOP craze. I wonder if a OOP mindset makes more programming that you have to unlearn before re-learning for Haskell?

Most languages (since ALGOL) have supported ‘pure’ functions and recursion as well as iteration. I guess they don’t do much to stop/warn you using side-effects. Monad syntax is deliberately designed to look like procedural. I guess OOP is deliberately structured to hide the large-scale flow of control – and parcel it out into local-scale events.

So what are the bits of languages you previously learned that you need to un-learn/re-learn?

#60

Of course…if NeoHaskell is going to be an alternative language. But not if NeoHaskell is intended to be the “next Haskell” (version, standard, et al ) - as you so memorably noted:

These are things wherein you can’t simply “fix [fundamental choices] via imports” because they cannot be remedied by addition […]

…and when someone probably smarter than all of us combined (yes, that includes me!) discovers at least one useful denotational denotative semantics for mutation, I confidently predict mutation will be added to some Haskell implementation within three months, be it GHC or another new implementation.

Until then:

If @Liamzy’s comment is any measure…the most desired one would be the ability to change a binding’s value “when it’s convenient” i.e. ready access to mutation, without having to use ST, IO, STM, various combinations thereof, etc.

Eventually, most who persist will make the transition to programming free of mutation, but that doesn’t make it any less tempting: “if only I could change just that particular binding right here…”

#61

Note that this is only arguably desirable. It also makes code confusing. Or worse, it causes horrific bugs. I remember one bug where one bit of code called a setter on a in-memory cached value in Java. The setter was to do logic (immutable update would’ve worked as well). It caused us to order a server rack with a EU plug to a US data center -.- My coworker spent days tracking that bug down.

1 Like