There is more stuff on their Discord — which I don’t use, but there is — so this seems snarky and factually wrong.
Yes I would like to see something on a repository too. There is no harm in waiting. What I took at heart from the message above is:
If this experiment manages to get people using and enjoying FP ideas, it will be a great boon to us and to the whole programming world.
enthusiasm is something we can work with
Enthusiasm on its own isn’t a sign of anything. Ideas, no matter how great and no matter how seemingly realistic, still have to go through myriad reality checks and years of implementation. You don’t get kudos for having a great vision of a future that never arrived.
Haskell is suitable for the fast prototyping of products, from conception to product.
And yet when we talk about showing off all that power we’re inevitably talking about writing a web server, using one of several huge batteries-included libraries. Sure, you can showcase extra type safety and slightly shorter code, but you can’t blow people’s minds, you simply don’t have the ecosystem to do that. To a curious person, unaware of what Haskell is capable of, what is the real difference between it and Python, other than the fact that the latter has a far wider ecosystem and doesn’t need compiling?
So, are you suggesting we just hack together another [Defect Process Defect Process on Steam] in 48 hours? Any ideas on projects that the mainstream developer can appreciate?
The GHCJS/WASM code seems to be something that Haskell users are interested in, and the web product is tangible, whereas backend utilities are less so.
In my mind the project choice does not really matter, the important thing is that when making it you also should create the libraries for other people to use and those libraries should be simple, powerful and have next to no dependencies.
I don’t believe in hacking anything in (24 * n) hours. I’ve been figuring out how to make a videogame correctly from the ground up for years and what I encountered is that:
String -> a -> Either Fail a on each argument " one.There are more tangential issues, like serialization libraries abusing typeclasses, but I imagine for any projects you pick there will be a half a dozen of incredibly basic libraries that just aren’t there and no guidelines for implementing any particular one.
The whole vision doesn’t let room from any compromise. At some point difficult choice would have to be made (Haskell is not hard for the sake of it. There are genuine reasons behind every decision). For example, should NeoHaskell remove operators, typeclass, monad (ala Elm)? Without talking of implementation, we even don’t know Nick’s opinions on anything , let alone the proposed alternative.
The project holds because it is(I quote) “a parallel universe” and contrary goals can co-exists happily, like in quantum universe. Making a decision will be equivalent to wavefunctions collapse.
Like the schrodinger cat, the cat is alive until the box is open, so the box will never be opened.
Nick;
If you’ve managed to get all the way to this message, there’s a bit of Haskell history you should know about:
It introduced the language called ISWIM (“If you See What I Mean” ), which to my current knowledge has two novel characteristics:
It was never actually implemented;
Most, if not all current non-strict functional language have been influenced in some way by its ideas.
You could say a concept had a role in the origin of Haskell :-)
Now that you’ve published your concept, I now recommend that you look at what novel research has already happened:
to see if any parts of your concept have already been attempted, so as to avoid duplicated effort;
and to see if that prior work can be used for its implementation.
A case in point: twenty years ago, the only place you may have found any articles about OSs written in non-strict functional languages would probably have been at the nearest university’s library:
Now at least two of the KAOS (Kent Applicative Operating System) papers are freely available online to read:
The earlier research on such systems is similarly being released e.g:
If you’re now wondering:
yes, there is House and subsequently Lighthouse, both being small OSes involving Haskell.
and yes, there’s other novel work which is largely unrelated to OSs :-D
So go see what’s out there!
Hi, may I mention https://learn-haskell.blog which is a tutorial teaching Haskell with a hands-on project?
No matter what your opinion on the NeoHaskell project, it seems clear to me that many of the people on the discord server represent a very interesting demographic: people who have an interest in Haskell, but who aren’t fully committed to it because reasons. These are quite varied (I’m just reporting what I’ve read here, not agreeing/disagreeing):
Since this demographic represents the ideal target for expanding Haskell’s popularity, I think it would be interesting to ask these users to complete a survey (Google forms style), to try and get feedback as to what all those reasons are, which of them are most important, affect the most users, etc. The result of such a survey would be interesting to both the Haskell community and the NeoHaskell project.
That’s a great idea. I joined the discord and also noticed that a lot of the discussion was by people who were put off for one reason or another. And there also seemed to be plenty of misconceptions about fundamental parts of the Haskell language and ecosystem as well.
Sounds to be fairly dismissive of the work that has happened over the last ~4 years.
With vscode, you pretty much have an all-in-one experience now. There’s still rough edges, but the concept is firm. It figures out your project GHC version, then figures out the latest HLS version that supports it and then installs everything in one go.
The rough edges are not conceptual issues. Those are all low-level issues that don’t need grandiose ideas, but people constantly fixing small things that sound boring to do.
This is sadly very true. We need lots of folks interested in the low level mundane parts of the compiler. Willing to help us do unglamorous work towards better stability. Including making more packages reinstallable, fixing our compiler story on windows (we have people who know how, but simply lack the time to do so, yet would be happy to mentor). Look at the side of built artifacts, why are our binaries (comparatively) so large? There are lots of quality of life improvements to be contributed to stack and cabal. The ability to use Haskell on mobile (natively), while possible is not really trivial. Iserv could be so much better. Helping with CI related topics across the whole ecosystem. I’m sure GHCup would like to see more maintainers too.
It’s not like we have too many people actually implementing these things.
We have a vibrant community with lots of interesting and grandiois ideas (neohaskell included). Getting them to the POC, and later implemented stages is a lot work. Polishing and making them great, is even more. Pareto seems to mostly hold true for most parts 
…and now for today’s dumb question: is the Prolog community having similar difficulties?
To me, Haskell and Prolog have at least one thing in common: the both require programmers from imperative languages to “unlearn” old habits - Haskell with immutability/constancy of expressions and laziness; Prolog with unification, et al. So both languages ought to be having approximately the same problems with regards to adoption and support…are they?
IME, Haskell’s strength lies in managing complexity - but this is not something you can easily demonstrate to someone who isn’t familiar with the language already. Most examples of any programming language are of “introductory” nature, and hence, there is not a lot of complexity to them. A fibonacci function, a guess-the-number game, or even a To-Do-List webapp, are not complex enough to drive home where Haskell actually shines, and trying to do so tends to come across as thoroughly underwhelming to anyone who doesn’t already know what’s beyond the immediately visible horizon. “Hello world” in Haskell is simpler than its Java equivalent, but compared to Python, it’s still baroque, so if you judge Haskell based on that, then, well, Haskell is going to lose.
And there, I think, lies a more fundamental problem with making Haskell more attractive to newcomers. Of course there is some accidental complexity with Haskell, of course there are the usual warts and quirks, but I think the real issue runs much deeper. 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.
One has to experience that power in the flesh, by working on a nontrivial project over a longer period of time, in order to fully understand the benefits.
What Haskell buys you over Python is not “I can reduce these 12 lines of Python to 9 lines of Haskell”, nor “look, if I pass a string to this 4-line function instead of an integer, I get a compiler error” - it’s rather things like making refactorings in huge codebases while being reasonably sure you’re not breaking anyhing, things like swapping information about the problem domain out from your brain and into the code, and swapping it back in just as easily, things like keeping code workable by having solid, compiler-enforced abstraction and scope boundaries, and of course also the type system reducing the search space for your informal and formal reasoning endeavors to a fraction of a unityped universe. You don’t get to capture these benefits in a 20-line code sample.
Sorry, can’t resist, but you can always enable UnicodeSyntax to reduce the amount of ASCII in your code…
I hope, and truly believe, that in this forum we can accommodate a diverse range of respectful communication styles whilst pushing back against disrespect, insults and rudeness. As far as I know this forum doesn’t explicitly adhere to the Haskell committee guidelines for respectful communication but I think they can serve as a useful standard for individuals to refer to if they want guidance in their own communication style, and to get a sense of what might be reasonable to expect from others.
People from different backgrounds have differences in communication style. People also differ in the way they receive communication. There is no one perfect way of communicating and I think that, in terms of respect, the intention with which a message is sent is more important than its precise content. I would ask everyone to bear in mind that on the other end of the messages they send is a human being with feelings, and to ensure that their intention is always to respect the feelings of the recipient.
As others have stated on this thread, there are a lot of misconceptions and branding issues with Haskell. Old problems and old attitudes still shape widely-held beliefs.
Therefore, the list you write here seems like perfect material to use when suggesting changes to the homepage of Haskell.org. If anything on the list isn’t actually a problem, or can be listed as a strength, then maybe we just need to communicate it better. Maybe Haskell does need a rebranding (a slow, thoughtful one – please don’t start from scratch), and Haskell.org is just sitting there waiting for suggestions. 
You don’t get to capture these benefits in a 20-line code sample.
While true, part of my point is that Haskell can abstract far more aggressively due to its functional nature. A barebones web-server in my mind is just a tree that picks an endpoint and some HTTP/2 serialization, that’s two separate libraries and every extra format/encoding/authentication/cookie handler can also be completely separate. Having a batteries-included library where you can strip away layers to get near-infinite customizability would be different enough from the norm to warrant showing off.
Or maybe we just need to realize that Haskell is not the silver bullet we want it to be, it doesn’t suit everybody mindset and there is no point in trying to evangilize. I know (lots of) people which “hate compilers” and will stay away from static typing not matter what.
Maybe we should focus on making the tool/ecosystem work better for us (the Haskell users) than trying to adapt them to an imaginary target audience.
But when the trying stops, that’s when you become Common Lisp or Smalltalk, a group of highly-skilled users with domain knowledge that has low relevance on the outside and has lost its capability for new research.
It’s a case where the social value of Haskell (a grouping of like-minded individuals with comparable skills and values) has eclipsed its value as a basis for research or production.
Here’s the fundamental problem.
Tooling isn’t going to magically sprout out of no where, and work on GHC requires not only people, but also money.
All of the work on the existing Haskell ecosystem requires labor, often from very talented people, and these very talented people have to be paid or pay by volunteering their time.
If you decide that Haskell is a niche language whose main value is social, i.e, for Haskellers to hang around with others of common interests and values, you’ll face a resource crunch for work on GHC and Cabal, because much of the work is being financed by Haskell Foundation, and Haskell Foundation is paid substantially by production.
What’s worse, a lot of these costs are exponential; i.e, the original typeclass concept was done in a relatively small span of time, while adding ergonomic dependent types to GHC has taken years so far and is still not done.
If pushing into production is no longer emphasized, Haskell Foundation’s donors will gradually deplete (whether they move to new languages, get bought out and pushed off Haskell, or go under), and who will then pay for work on GHC?
And then there’s the fact that other languages are free to copy features from Haskell as they wish; what we saw with Rust was a ML-style type system grafted to immutable-by-default variables in an imperative language.
The gap between Haskell and other languages continuously diminishes and makes it harder for Haskell to be viable in production, until ultimately, what you have is a Smalltalk; all the good ideas have been stripped off and there’s just a community of die-hard devotees. You may say the Haskell community is better for you than any other, but then it’s no longer a living language.
About the homepage, it might sound trivial, but I think the pretty landing pages of Rust and other ecosystems helped them a lot.
Would it make sense to outsource design work to build a more modern and thought-out website for Haskell? The websites we have are great and functional, but it shows that they were built by Engineers and less by UX or landing page copywriting experts. It might help a bit with the branding and public image.