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

Links
#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
#62

Mz. Pillmore, thank you for your insights on the present situation, but I’d like to bring up a different aspect.

While I agree that this project does not have more than a 50% chance of success (perhaps I’m off by an order of magnitude), it has drawn up a bit of enthusiasm by non-Haskellers; for instance, I think everyone knows by now that Domen Kožar, the founder of Cachix, has offered to organize a hackathon for this.

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?

My attitude toward this has never been one of “this will be able to fulfill all its promises”; I agree with you substantially in assessing the risks the proposal contains. If the product weren’t vaporware, the key would be making sure that the code and effort put into this product would have utility even if NeoHaskell (and we both agree that this is very likely) fails, and for highly-experienced developers such as yourself to try to poke the NeoHaskell team into making the right calls.

But since this is still vaporware, the only thing we can work with is the enthusiasm it’s generated.

The 危机 (the Chinese word for crisis combines characters for danger and opportunity) folkloric is old hat, and this is not a crisis–the worst case scenario is a nothingburger. But there’s obviously an opportunity here for Haskell. How can we exploit this?

3 Likes
#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
#71

I tried to stay away from this thread but I am actually shocked by the number of people (>0) taking this VISION seriously.
We are suprised that the guy took many years to produce what we think is nothing. We are missing the point : NeoHaskell is not meant to be implemented, NeoHaskell is the vision itself.
Nothing will come out of it because it has already been done : the vision that we can read on his website. And that’s it.

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