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

Links
63

Might you or others have any ideas as to how to harness the energy created by this project to help develop the Haskell brand, boost Haskell adoption, or further develop the Haskell ecosystem?

Herein lies the particular rub I have with this project: I have tried. I was in the Discord earlier today, and had a comment removed when I told Nick that the “one-size fits all” narrative to CLI tooling, in particular the neo tool that would be a centralization of the build infrastructure, compiler selection, linter, and general user interface to the project, was a naive approach to a complicated problem. As someone who has worked with every one of the tools involved as either a contributor, user, or maintainer, it was extremely concerning to have this comment, which was very mild as far as criticism goes, denied as “not constructive”. I immediately washed my hands of the discord and the project.

In order to effect change, one must be able to meet criticism with a good argument and justify one’s motivations in clear and simple detail so that others will be convinced of it. Otherwise, it results in a fracturing of the community into believers and non-believers in the approach, and it just creates tension where there was not before.

Basically, I’m not sold on any of this in its current incarnation. Is the idea solid? Well, broadly, yes, I think a dialect of Haskell is probably the correct approach to the “Simple Haskell” that people are looking for. But people have been saying this for years and no one has offered a solution that we could capitalize on without serious funding from industry. What would that funding look like? Say, $5 million, 3-4 years, a team of 5 devs, and some key consultancies like Obsidian with John Ericson and Ben thoroughly funded and diverted to lead that team. And that would still be a stretch. If anyone wants to talk about that and is truly interested, let’s chat.

15 Likes
64

Nick, apparently, has received a bevy of critical and positively toxic comments by people he thought he were his friends after he announced his project, and the first substantial discussion I had with him was regarding his negative experiences.

I think Nick’s primary responsibility at this point in time is not to listen to criticism, not to respond to anything, but to provide an MVP, however flawed, so we know that this is not a nothingburger, and there’s something that can be discussed, criticized, amended, and improved upon.

If Nick continues to show unreasonable intransigence afterwards, this will be an issue (some people think that character flaws in founders was what crippled Elm), but…

I think we are both looking at Nick and NeoHaskell as investors might, and you are accurately pointing out problems with both the project and its staff. The difference here, is that I’m trying to constantly create and exploit hedges; as in, if the project fails at any particular stage, our insurance policies pay off.

At this point, since there is no product, the insurance is on the enthusiasm. How do we cash in on this?

1 Like
65

At best this will be yet more focus grouping for what people want out of a UX/DX, and proposals can be made to the HF for funding specific, scoped and sufficiently detailed ideas. This process already exists and is ready to catch anything that pops up as a significant ask.

1 Like
66

This seems a bit conservative, and I think there are already members of the Haskell community sitting in Nick’s Discord. I try to ask questions to people of why they’re disappointed with existing tooling, and I’ve copied a log of parts of conversation on why Haskell’s tooling is perceived as inferior to the #hackage IRC.

If you or others come up with other ideas on how to exploit the enthusiasm Nick’s generated, I don’t need to know about it, but I hope that there might be more ways to derive benefit from the situation.

One thing I’ve suggested and not been able to finalize is for someone to organize a Hackathon around existing Haskell projects for Nick’s audience, because NeoHaskell is html5Zombo.com right now (If you remember that website). The idea would be to demonstrate Haskeller skills to outsiders and provide an idea of what the existing development experience in Haskell is like. If someone else would like to handle it, and has interesting ideas, that’d be great.

67

Should enthusiasm be celebrated for enthusiasm’s sake though? Especially when there isn’t much else along with it?

Personally, I have equally enthusiastic and future-minded goals around Haskell game development. Deploy to all platforms a la Unity! Get GHC targeting consoles! Build dev tools a la carte! Algebra-driven game design! Blah blah blah. I don’t deserve any praise for having lofty goals. That’s the easy part.

These are hard-ass problems. No matter how skilled or enthusiastic you are, there’s no way to summon them by some miracle.

So I’m not sold on a project just because some person got some other people hopped up on aspirational rhetoric. I was actually initially interested because of the teaser with the iPhone. I was disappointed there wasn’t even a written document outlining how that was done and how it was better than using Nix or GHCJS like the iPhone screen claimed. But then the announcement came and it seems to primarily be about a technical and cultural soft Haskell fork? Based mostly on Feels (“ooh the Haskell community’s attitude is holding itself back”).

Sorry for my grumpiness here, but I’ve followed Haskell for a while and loved to see people solve real problems and make real progress on the cutting edge. It’s a beautiful union of engineering and theory. I was disappointed to find neither with this announcement :confused:

6 Likes
68

To be honest, the value that Nick has demonstrated so far is his ability to generate enthusiasm and interest. Consider that all NeoHaskell amounts to right now is a website with nebulous aims and promises, yet we’re all talking about it. We’d all like him to provide something more substantial soon, but the enthusiasm is something we can work with.

I think, how about this?

I originally pitched SparkPool.IO for the hackathon, named after Simon Marlow’s lazy parallelism model. That is to say, parts of the open source ecosystem in Haskell are low on labor (if we can do anything for Maerwald, please do so!). SparkPool.IO would aim to connect open source projects seeking help with people looking for open source development work; remember that at least of 4 years ago, FOSS on your resume was a way to get an interview.

A big advantage of this is that since existing Haskell frameworks still use HTML, CSS, and Javascript, we could use the rubberneckers, well-wishers, and enthusiasts without Haskell skills to help build the frontend.

We could do this with the three primary Haskell web frameworks, IHP, Yesod, and Servant, to offer a selection of Haskell possibilities.

The idea would be to rush through the initial website to see how fast we can get a prototype up in the Haskell web frameworks, but afterwards, we are likely to be able to identify flaws in the existing frameworks.

Then, we can pivot onto addressing one or more of these flaws, providing lasting value to the Haskell ecosystem.

The worst possible thing NeoHaskell can do is to scare people that attempts at “demotic Haskell” or “accessible Haskell” are all going to be vaporware, making it harder for future attempts in this direction to succeed. A Hackathon oriented around providing a visible, tangible product can show that:

  • Haskellers can be very pragmatic people who make things.
  • Haskell is suitable for the fast prototyping of products, from conception to product.
  • That Haskell can be learned in a hands-on project, with the appropriate guidance.
  • That even if NeoHaskell might be a nothingburger, Haskellers can still grasp opportunity and turn it into a productive venue for educating people on Haskell.
  • That Haskellers can and will fix problems with their ecosystem, and that Haskell is not stagnant.

But of course, when I was asking around, everyone was busy with their own work, so maybe there’s better or more interesting ideas for exploiting the opportunity we’ve been given?

69

So while that all does sound like fun, and the SparkPool idea itself is a cool one (I have a similar idea in my journals somewhere)…I feel like the perceptions here are a little disconnected from reality?

Making such a website isn’t a new frontier for Haskell. It’s pretty bog standard stuff nowadays. Maybe 10y ago, there wasn’t enough “proof” of that domain. But by now there’s plenty. (Even 10y ago Haskell was pretty mature on the web app front.)

The other things don’t feel like they need proving either?

  • Haskellers can be very pragmatic people who make things.

Plenty of examples of this to go around!

  • Haskell is suitable for the fast prototyping of products, from conception to product.

Ditto!

  • That Haskell can be learned in a hands-on project, with the appropriate guidance.

This is harder to illustrate, but many Haskellers got their start with a project. I know I did!

  • That even if NeoHaskell might be a nothingburger, Haskellers can still grasp opportunity and turn it into a productive venue for educating people on Haskell.

Don’t Haskellers love teaching people Haskell more than writing Haskell itself already :laughing:

  • That Haskellers can and will fix problems with their ecosystem, and that Haskell is not stagnant.

There’s a huge amount of proof of this and it’s more than ever nowadays. I just went to ICFP and this was my main takeaway!

Is the issue that MAINSTREAM_DEVELOPER has these wrong preconceptions of Haskell? Maybe we can focus on spotlighting the great work people are already doing. Work that is already very much in-line with NeoHaskell’s stated goals (except the work is actually upstreamed and playing nice with the greater community.)

4 Likes
70

Might you have any other suggestions?

I can add two other things in favor of the website idea. First, SparkPool.io or a similar site could potentially become a famous project, not just a famous Haskell project, and one substantially more visible than Meta’s Sigma.

The other part is, I think I already know what the “real” and non-demonstrative part of the project is. GHCJS backend and WASM backend in Haskell is new, and we should put in support libraries for this into the Servant ecosystem, as Servant is preferred by most experienced Haskellers.

The Sparkpool.io part can just be a demonstration project for the onlookers, as well as a teaching, branding, and marketing opportunity. The real thing we care about is building provisions for GHCJS and WASM for Servant.

Remember, we’re just fast prototyping, we don’t need to retain the outsider / newbie JS code. The point of the fast prototyping is to demonstrate, to people who are probably mostly unfamiliar with Haskell, that it can be done, and to dispel common misconceptions of the language.

The real meat would be GHCJS / WASM, and I’m running off from that part because it’s beyond my skill level.

I guess, the real response is, all your points are valid, but the average outsider / mainstream developer doesn’t know, and a Hackathon is a way to let them know. And advertising HaskellNow is way more productive than poking holes in what seems to be vaporware.

1 Like
72

Someone was talking GHCJS / WASM (21it) on Matrix yesterday, so that part was their idea. Someone else wants to do it if it’s FRP, based on Rhine (not sure how flexible they’d be on choice of library).

So there’s probably 2 takers + me, who’ll be here for the server part and probably a fascinated on-looker for the FRP / WASM part.

73

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.

6 Likes
74

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?

3 Likes
75

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.

76

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:

  • There are no proper radix tree or R-Tree libraries. I’ve spent quite some time figuring both out and I’m still not done.
  • FFI libraries are either ancient and unmaintained, or maintained and too high-level. Part of this is on Cabal for not having FFI libraries as a category, but I wouldn’t blame it all that much.
  • There are only two established commandline parsing libraries, but no dirt simple "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.

2 Likes
78

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:

  1. to see if any parts of your concept have already been attempted, so as to avoid duplicated effort;

  2. 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:

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!

3 Likes
79

Hi, may I mention https://learn-haskell.blog which is a tutorial teaching Haskell with a hands-on project?

10 Likes
80

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):

  • bad tooling
  • complex abstractions
  • no clear guidance on architecture
  • obscure names for things (Monoid, Monad, …)
  • steep learning curve
  • lack of reading material, bad learning material
  • snobby gate-keeping by current Haskell community
  • too many ASCII symbols
  • etc.

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.

14 Likes
81

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.

1 Like
82

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.

13 Likes
83

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 :frowning:

14 Likes
84

…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?

3 Likes