My views on NeoHaskell
haskellforall.com
haskellforall.com
I even felt something like that about Yesod, so Gabriella's mention of Stack seemed apropos. In Yesod's case, the author (Michael Snoyman, also author of Stack) was at least an extremely knowledgeable and productive Haskeller, even if some of the decisions in Yesod came across as dubious for purists. Neohaskell has far less substance behind it.
Why are we putting everything in a data silo controlled by a company with pretty draconian policies? There's so many open discussion platforms available - why use the worst one?
Because functionality wise, it's the best one. And the most popular one. Even among programmers people who will sacrifice that for idealogical purity are a minority.
The machine I use is fairly recent btw. I get distracted and frustrated by slow programs. If you run enough of them, you get compounding issues. It’s not fun!
Aside from that, I do agree with GP 50%. However I absolutely use and promote proprietary software when it’s good quality.
Yea man, that's a you problem. Discords popularity speaks to how little of a problem any of that is for other people.
Anecdotal I've never thought of Discord as slow or "complicated".
I also enjoy using discord for programming, it has awesome support for code blocks and all kinds of stuff.
At work we use slack, I'd take discord over slack any time.
That's not to say I think it makes sense for a programming language or library to use discord servers instead of documentation. Documentation is a minimum requirement in my book. But if they also have a discord server, I might consider visiting it.
And you sow the seeds of it happening again when you think of opposition to Discord as an ideological stance, rather than one that promotes a practical structure which guards against a company deciding to screw you over.
People saying Unity was not a good choice because it's closed source and controlled by one private company were laughed off as ideologues. Then what they warned about happened.
Now the same kind of people are getting the same kind of response. Maybe that "ideology" is based on practical considerations after all?
I kinda feel like including what Unity pulled recently in your "private company threat model" is a bit overkill - I'm generally comfortable assuming that private companies aren't going to do something quite that self destructive and braindead.
Based on prior behaviour I wouldn't trust anything google develops to not get canned within a year or two, I'm very weary of anyone trying to monetize open source projects, and building a business on top of someone else's saas product seems pretty risky.
But commercially licensed development tooling that I'm using to produce my own binaries is pretty low on my list of concerns - most companies aren't as bugfuck insane as Unity's current management seems to be.
And just using some closed source product for which the switching cost is effectively zero (for me - see other comment in this thread about chat being ephemeral) seems like a no brainer.
I guess most people don´t care that much about participating in forums that are, for all practical purposes, essentially ephemeral. Not only is the search abysmally bad, we all know the data will vanish eventually.
I genuinely think this is how people roll. The willingness to do something that can remain useful 20 years from now is relatively rare. Sometimes speaking about this topic to others, it's like they don't even acknowledge there's a problem to begin with.
For me at least, chat in general is ephemeral - I don't care about history past the last couple hours - the same way as I don't record regular conversations with people and listen to them later.
For this reason I'm much less concerned about vendor lockin with a chat solution than I would be with email or more forum type stuff - if Discord starts sucking I don't lose anything by moving to something new (assuming it sucks enough for the communities I'm in to move too).
Extremely poorly.
I am on 2 or 3 instances, and I cordially loathe it.
Compared to mailing lists, it's a grotesquely over-complicated mess.
To make a comparison with text editors:
Discourse for a mailing list user is like telling a skilled expert in Vim or Emacs...
"Now, to join our community, all you have to do is install a Windows 11 VM and use MS Word 365 for all your editing! Some new users prefer the toolbar. It does all the stuff you're used to and like, but it has a cool new UI! It's great! We all love it and we are sure you will too! We looked at your old system and we have made sure we've included all the old functionality! You can move the cursor left, right, up and down, but now, you can also use an animated GIF or PNG as your cursor and have a choice of colours!"
> Try it and you'll get a bunch of people complaining that inline images are bloat and who needed an auth system anyway and why can't I use my IRC client from 1996 and your client wasn't supposed to use my RAM, I'm saving that for guests.
If and when those open discussion platforms manage to match the UX of Discord, I'm sure people will be happy to switch. But I'm not sure it'll ever happen.
In one hand neohaskell is not that dumb, but on the other hand it's not much better either. I believe that if you are going to make a claim that ambitious you need to post more than a website and a discord, you need an actual PoC.
Personally, I use ClassyPrelude and only a handful of extensions.
That's something I'm looking into doing myself. It would be great to help improve tools like cabal and the haskell-language-server.
I think that will go a long way towards making Haskell more beginner-friendly, and easier to use in production.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16...
- "A history of Haskell: being lazy with class", from 2007, by Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler.
https://www.microsoft.com/en-us/research/publication/wearing...
Some people on the other hand want to say that the research part is 'done' and that Haskell should move on and become just another language suitable for use in industry and production. And some of those people think that laziness should be relaxed.
tldr; laziness enables a lot of optimizations for high-level languages that are good for performance. Laziness/strictness aren't direct causes for performance but impact it in different ways. There are a lot of myths around thunks and memory usage. There are still fertile areas for improvement.
Haskell is suitable for industrial use and production. Most of the research being done these days is around maintaining an industrial-grade compiler pipeline while supporting new, interesting features [1]. And it has been that way for quite a long time now.
[0] https://www.youtube.com/watch?v=fSqE-HSh_NU
[1] https://www.researchgate.net/publication/334751646_Dependent...
This would essentially make 'data' types strict by default and 'codata' types lazy by default, but with easy syntax to add laziness or strictness after the fact. And some types (tuples, functions) would exist in both 'data' (strict by default) and 'codata' (lazy by default) flavors.
Coq has been doing exactly this for over a decade...
Perl same story. And Ruby may be that language that was cut out of Perl.
Haskell has a problem like that as well, and (while not a general purpose language) Elm is a neat, concise small language that's cut out of Haskell. As the author of this NeoHaskell commentary explains, I also do not see how NeoHaskell fits in here (epecially since it tries to be Haskell compatible).
-----
I also see the opposite, Java and Go for instance have a small feature set and miss ergonomics (and an std lib designed based on those ergonomics). Java recently got Kotlin, which seems to me a great "Java 2.0". Go may also benefit from a language that builds on top and provides great interop with the Go std lib and ecosystem.
Not saying Kotlin is perfect (it certainly shared some JVM problems like statics not being mockable, therefor needed DI everywhere in a testable codebase), but it sure did improve a the DX lot.
An event sourcing framework
I'm out.That's probably not a good thing.
It's got lots of development activity, and a huge package library, not to mention interop with JavaScript as well.
My guess is that Haskell already takes all the air out of the (albeit small) FP room.
Having used it in production for a while, tooling was poor, particularly IDE support, and anonymous records are in practice less of an obvious win than I expected. Plus I like laziness.
Also, in my experience, Haskell's user experience isn't all that bad. It seems to me that the author is worked up and dense for some reason, and is hoping that a custom base library will somehow help. All the advertised features on the website (https://neohaskell.org/) are already in Haskell's base library or an import away. The "coming soon" "Pre-thought architecture" isn't, but I'm doubtful that there exists a single architecture that fits every problem.
Scientifically, it's cool of course, dependent linear types yaay.
Socially though, incompatible rewrite in Scheme should've been a separate project IMO; but since it's called "Idris 2", community attention faded away from the Haskell implementation "Idris 1". Which caused bad maintenance, neglect, stagnation, of a thing I tried and liked.
FOSS has enough issues with people who were merely anointed dictators.
The reality is much more complex. If bdfl can work for open source it technically can work for the real thing as well. The keyword here is "can".
If your open source dictator sucks, you can use different project, or fork it, or start your own.
If your real life dictator sucks, you can move your family for half your life savings and hope your next dictator is better, or try to protest and get killed.
Democracy is also a bit of an illusion. How often has a protest changed things? why is there huge wealth inequality and power concentrated among the few? Democracy Looks like much of the bad things associated with "dictatorships" with useless freedoms like voting and protesting as an outlet.
Of course it's not a hostile takeover, he'll try to build something that convinces people that he's on the right track, and I wish him the best of luck with that. There's a small chance that the project succeeds and essentially becomes the successor language to Haskell, and there's a large chance that the project fizzles out, and both of those outcomes are fine. The worst possible outcome is that it succeeds well enough to fragment the ecosystem, but not enough to really take over.
From the pov of the Haskell community and the way it has been shaped by its academic origins, and by the work and organizational choices of SPJ on GHC, there is little chance the community doesn't see this as a hostile takeover.
It's better to think of yourself as a shepherd, visionary, leader, etc. Mentally framing yourself as dictator affects your thinking. In short, BDFLs can more easily become assholes.
Frankly, it is the clearest thing about the project, how it will be run. One vision from a personality whose thought style comes through in Spades. That is refreshing.
Anyone who joins the project knows exactly who they are signing up to help.
Swing for the fences Nick Seagull!
I'm not so sure of that. The Neohaskell site seems designed to attract the naive. If someone isn't already using Haskell, how can they know what they are getting into with Neohaskell? Someone like Gabriella can see the substance (or lack of it) behind the claims, but to a non-Haskeller, there is nothing to go by except the sales pitch. Not good.
Any project needs good leadership, of course, and at the start that leadership is going to be concentrated amongst a tiny number of people, maybe even just one.
It's going to be hard to encourage contribution if, right off the bat, you say "I'm BDFL. End of discussion." So the author of the project might find themselves in a position where they have actively reduced buy-in.
I can agree with this. However, it's odd to start communicating the way he did this early in the project, when none of these ideas have been thought out.
I don't get why Gabriela is so against this project, it might just be vaporware. But invoking the fact that this person is not already established in the community is detraction for detraction's sake (or gatekeeping).
Funny enough, I've also been very slowly chipping away at some base(/prelude) Haskell library replacement, because I find it beyond embarrassing that in 2023 with a default Haskell installation one cannot make a HTTPS GET request.
Haskell comes with half depleted batteries inside the box. And I cheer for anyone that tries to fix the base experience. If this one's vaporware, I'll just wait for the next person that gets too frustrated with the library experience.
Sounds interesting! Do you have anything you can link us to?
If you're interested in terms of approach, it builds on what I consider saner exports/re-exports of all the other packages that are part of a default installation (base, containers, text, bytestring, etc), and avoids reinventing where industry standards exists (no tls/http client stack from scratch but curl C bindings). There are a few other abstractions I've written in there, but those feel rather flimsy and might remove them.