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

Links
#37

If I were to guess the slowdown is caused by the weight of the backlog multiplied by all the new additions that are far more complex than any of those old ones (notably moves towards dependent and linear types).

As recent as GHC 8.10, small integers were represented as platform-sized ones (base-4.14.0.0:GHC.Word#Word8), text was in UTF-16 and writing strict low-level stuff still had to rely on lazy datatypes (UnliftedDatatypes landed in GHC 9.2). You can still be on the “oh man, I wish this feature was there five years ago” train, you just gotta move from the type-level camp into the low-level one.

5 Likes
#38

No, I don’t believe this is the case. I’m just speculating here, but if I had to guess why development is so slow, I’d say it’s because the language is developed by the community as a whole. Lots of people has lots of different input and there are many different concerns we’re trying to address at the same time, in addition to trying to ensure that backwards compatibility isn’t lost.

I think this is a lot different than a language funded by an org and dictated by a few individuals who catered to their own agenda and didn’t care for the concerns of its users. People would probably find an environment like that very off-putting, but it’d probably also see features developed a lot quicker.

This is probably the case for the beginning of a lot of newer languages like rust and go. I heard that rust changed a lot in its beginnings, and people were upset that they broke things so often, and then it became more of a community effort once the core was more complete.

1 Like
#39

@AntC2, it’s really none of your business to say what it is “better” for someone else to do. Can I implore you to please choose your words much more carefully so it is clear you are stating your own opinion and not making assumptions about other people?

EDIT: For example you could say

I would prefer you to put your efforts into some prototyping or deliverables, so I can understand better what I might get excited about.

Then Nick and everyone else is free to choose for themselves how they feel about your prefence.

7 Likes
#40

It’s far from clear to me that work on GHC is slowing in any regard. In fact some of us are exhausted by how fast it moves and wish it would slow a bit! Perhaps there are fewer new type system features of the kind you’re interested in particularly? But when you look at the new features across type system, RTS and various usability improvements, plus the support across architectures, plus the fact that software systems absorb time and energy simply for maintenance I don’t see any reason to think that “Haskell 2023” is less productive than compilers in 2006. Quite the opposite.

2 Likes
#41

If a system has N binary (on/off) inputs, then there are 2N combinations of inputs.

# ghc --show-options | grep '\<XNo' | wc -l
132
# ghci
GHCi, version 9.4.4: https://www.haskell.org/ghc/  :? for help
ghci> 2^132
5444517870735015415413993718908291383296
ghci>

It should already be happening…

2 Likes
#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