I suspect (pure guess) that the numerous extensions come in the way because any new feature need to be compatible with all combinations of extension. I am in favour of cleaning up extensions (and the code) so that for example the default in Haskell 2010 and all extensions included in it are removed entirely (I mean there is no need to be able to deactivate them). Alternatively they could be an extension to chose Haskell 98 (as one extension) but there is not need to allow all combinations between 98 and 2010.
1 Like
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
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
@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
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
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
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
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
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
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
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
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
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
Yes, it’s wonderful that it demonstrates such interest in Haskell becoming more accessible.
4 Likes
…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
+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
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.
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
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.
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.)