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.
3 Likes
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.
4 Likes
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.
5 Likes
Yes, I think there is merit to that idea, although I should point out that people have attempted broad rewrites in the past and it was met with a lot of resistance. But thoughtful application of good UX (including understanding who the audience is and what should and should not be highlighted) to incremental changes seems like something that could be successful. It would be worth exploring the idea as a Technical Working Group proposal.
(Well, I’m not sure if that’s the right place to suggest this kind of proposal, but they’ll know where to point you if not.)
1 Like
And therein lies the conundrum: as @maxigit noted earlier, if we’re not careful we’ll end up pursuing an target audience which isn’t really there.
1 Like
…prehaps most notably being the arrival of type classes in C++! More importantly though, designers of other languages can pick and choose what new innovations have appeared in Haskell. Therefore any advantage granted to Haskell by way of continual innovation also diminishes over time. But the same cannot be said about the cost of innovation.
As I noted eariler, each new language-extending innovation has to exist alongside all prior ones, which leads to an exponential number of language-extension combinations. In the absence of some wondrous advance in managing the ensuing complexity…the cost of continual language innovation will eventually be overwhelming. Any notion of “a balanced approach” to innovation must take that cost into consideration.
For the forseeable future, the only way to manage that cost is to limit the total number of language extensions, by:
-
consolidation - widely-used extensions are brought into new Haskell standards,
-
or elimination - the least-used extensions are eventually dropped.
4 Likes
There is an answer to that, which is to remove the ability to disable extensions which have been included in the language (Haskell2010, Haskell202?). We are in 2023, there is no need to support Haskell98, especially the permissive ones.
For example, ImportQualifiedPost has been included in GHC2021. It’s harmless, what is the need to be able to disable it ? Why not just say, going forward that is valid haskell. (Ok I could the problem there is Haskell2010 doesn’t really bring anything and GHC2021 is not Haskell2021).
If people really need pure Haskell98 they might revert to an old version of GHC.
By the way, it might actually be easier to keep alive a few diferrent versions of GHC (one for each “language”) rather than dealing with this exponential complexity.
1 Like
You would need more that just separate compilers - all other parts of the Haskell realm would need to be replicated, possibly all the way to websites:
www.haskell98.orgwww.haskell2010.orgwww.haskell2020.orgwww.haskell2027.orgwww.haskell2032.orgwww.neohaskell.org
…etc. Then the issue of ongoing support arises:
- should that realm be based on an interpreter rather than a compiler?
- should it only have CLI-based tools instead of GUI-based ones?
- when should support for realms stop?
…and on and on and on it goes! It seems to resemble the ongoing development of an open-source operating system (sans the bootloaders and device drivers).
1 Like
I believe NeoHaskell might be focusing on the wrong challenges. To bolster Haskell’s adoption, what’s crucial is a thriving ecosystem of libraries tailored for business applications. More importantly, these libraries need consistent maintenance.
The economic dynamics of software development dictate that technology decision-makers often seek a balance between adopting the best technologies and avoiding risky choices that could potentially hinder business objectives. Why the emphasis on business applications? They constitute the bulk of SaaS and enterprise applications. Achieving a significant number of success stories in this realm will naturally lead companies to choose Haskell. Once these companies grow profitable and sizable, they are more likely to give back to the community.
To further underscore my point, I offer two illustrative examples:
- ReasonML: NeoHaskell’s objectives resemble those of ReasonML. ReasonML aimed to make OCaml more user-friendly. It boasted a distinct advantage: it could compile to JavaScript and had first-class support for React from the outset. Furthermore, it could tap into the expansive JavaScript ecosystem. But even with these benefits, ReasonML didn’t gain the expected traction. This suggests that neither ease of use nor the learning curve were the real barriers. The developers of ReasonML perhaps missed this insight, as they later rebranded to Rescript, distancing themselves from OCaml, functional programming, and any terminology unfamiliar to the average developer. Even this change didn’t have the desired impact, leading to some core Rescript developers leaving the project.
- Rust: Contrasting with the above, Rust, despite not being the simplest language to master, has witnessed significant adoption. This can be attributed to Rust’s early emphasis on showcasing its capability to develop applications across different domains. Initiatives like “are we web yet?” effectively communicated to potential adopters that Rust was a dependable choice. Once the job market for Rust developers increased, developers felt more compelled to learn the language despite its steep learning curve.
12 Likes
I had a moderately unpopular post to that effect on Reddit, but what we really need are more and better frameworks for common tasks. In my experience with using Servant and Monomer, often, with the right framework design, you can achieve all the necessary functionality without using any code in IO or some IO code generator (monad transformers, effect systems, free monads, etc) other than the framework itself.
There have been some posts to that effect by others; that there have been no “killer frameworks” in Haskell and that was what was holding it back.
As I’ve said before, the problem with Yesod was that it somehow presupposed knowledge of Haskell, whereas it should be possible to teach the framework first and then only as much Haskell as needed to operate the framework. Some of the publicity for Yesod suggest that Michael Snoyman realized that toward the end, and IHP selling itself as a framework for non-Haskellers was a significant step in that direction.
A framework-centric approach, combined with high-quality frameworks tailored for the target audience, might be what we really need.
The problem with this is that Haskellers don’t seem to like overly opinionated frameworks, but this kind of product is probably what the average programmer wants; no anxiety about choices or wondering about ReaderT vs MTL vs Free Monads vs Three Layer Cake vs Effectful, just follow the path on the HUD.
PS, also, three thoughts come to mind. If Haskell has achieved partially negative brand equity among a sector of tech leaders, the natural idea might be to rebrand, but that’s complex and difficult.
Instead of trying to turn Haskell branding around, sell IHP, sell Yesod, sell Hydra, sell whatever framework you can come up with and only mention it’s Haskell-based at the very end.
The framework-oriented approach also ties into Gabriella Gonzalez’s proposal in How to Market Haskell to the Mainstream Programmer; she identifies Haskell as a language very suited for building eDSLs, and consider the overlap between eDSLs and frameworks.
Lastly, I’m not sure if you’ve seen the comedy skit comment on some thread in Reddit, wherein the new CTO comes to axe the Haskell infrastructure at their firm, upon which the resident Haskell guru informs them that they are using the Monad for Medium to Large Enterprises, causing the new CTO to be enlightened, rainbows and stars showering upon them, and profits rising.
This is also a way to get rid of all the burrito monad tutorials flying around; if the marketing association with monad is now “business framework” (vaguely correct based on the eDSL interpretation), do we really need to correct them?
5 Likes
That was probably the biggest time-sink when we adopted Haskell, followed closely by figuring out an error-handling strategy.
1 Like
I think the biggest mistake adopting Haskell is trying to come up with standardization for such things right away. Especially when the team’s new.
Now, I get the “we need code consistency globally” argument (I guess). But if you commit to something early and force people to just go along with it, you end up not cultivating learning across your team.
If you’re working on some sort of SaaS-y web service-y thing, you can actually afford to allow people to experiment with error handling and the whole monad thing. You can start by standardizing on a config file format + a type to parse it. And a standard way to hook into main via IO or something.
But it’s fine if you have people working in different ways. Opportunities to unify things and reap dividends can only come after imo.
That’s just my 2c having seen a lot of these codebases grow in line count + engineers over the years. It’s a mistake I’ve seen often, and in the places where there were no standards from the get-go, the outcomes were better.
2 Likes
…often, with the right framework design, you can achieve all the necessary functionality without using any code in IO…
Real-world programming isn’t about having things convenient “often enough”, it’s about getting a task like “this endpoint should serve both a POST 200 and a PATCH 204, both with different argument sets” and not having to bend over backwards to fill it in.
servant's approach, from my experience, is just unwieldy. Things don’t need to be packed into the type-level; the server endpoint either works correctly or it doesn’t, and you should be able to unit test that. I imagine things are even worse with yesod because their minimal app is TemplateHaskell over QuasiQuotes.
…the problem with Yesod was that it somehow presupposed knowledge of Haskell…
This pops up constantly for some reason: why do we care about people who don’t know programming getting all the tools to do programming without actually learning programming? (replace “programming” with “banking”, “art” or whatever the next marketing bubble drags in). More people doesn’t automatically translate to better software, in the short term it probably translates to more bad software. And I don’t know if all that many people would want to stay long without a solid ecosystem to support them.
…only mention it’s Haskell-based at the very end.
If Haskell is the weak link in your system, then why even bother with it? If your goal is winning a popularity contest no matter the cost, a relatively esoteric language isn’t gonna cut it. Especially when the committee clearly has issues coming up with solutions to seemingly mundane things, like record field access.
2 Likes
In response to the idea of standardizing early, we’ve extensively experimented—perhaps even over-experimented. Over the past three years in production, we haven’t settled on any particular effect system. We’ve transitioned from Polysemy to fused-effects and are even contemplating a switch to effectful. We’ve also switched our error-handling strategy multiple times. That’s why I highlighted effect systems and error handling.
1 Like
None of this is pointed at you, but I’d like to muse about a few of these.
Gate-keeping from what exactly? Being one of the cool kids on reddit? I see this one often from a few people on twitter, but I’ve yet to see a concrete notion of what this even means. It seems to mean something different to everyone I hear it from: “people don’t think my code has enough category theory vibes”, “people don’t seem to like me very much”, “people don’t roll out the red carpet for me”, “people don’t use my libraries”, “people don’t buy my book”, and “i’m not elevated to godhood within this community for the work I do” are the most common.
Many of these takes are unfathomably entitled, but when it comes to category theory in Haskell, I’m really not sure how to address the pedantry short of endless patience (which I do not have) and nodding my head in agreement at every little criticism that exists, and then ignoring the pedants and doing my own thing. The latter I’ve done rather successfully, and people really don’t bother me about it much in any case. I’m saying this as someone who helped contribute to a publication in the ACT field: having guiding principles is one thing, but for the love of god learn some statistics and understand the difference in utility between interpretable and flexible program models!
You’re welcome to just ignore people and create cool stuff and show it to other people who do cool stuff too. You can certainly show it to me! A thing I can run beats navel gazing any day of the week. I find that gatekeeping seems to arise near spaces where knowledge is a proxy for social status, but you’re free to ignore it as you please.
18 Likes
I think when people talk about gate-keeping, they’re talking about gate-keeping people, not ideas.
I think all projects gate-keep ideas to some extent (imo it would be pretty chaotic otherwise). An extreme hypothetical would be if someone came in and wanted to add arbitrary side effects to haskell. I imagine that proposal would get shot down pretty quickly.
idk if I would call disagreement over haskell extensions gate-keeping ideas either, I just think it’s just healthy disagreement (:
Also, take this for what you will, but I only hear about haskell’s gate-keeping problem from inside the community. I’m not saying haskell doesn’t have this problem (it very well might), but it might be worth looking into if we’re making the problem seem worse than it actually is.
2 Likes
Gatekeeping isn’t always a bad thing. Do you want everyone being able to make random decisions over GHC, core libraries or other parts of the ecosystem? Probably not. That’s why we have committees, processes, the HF to mediate etc.
As much as it can be a nuisance not being able to push all your ideas into every project, there might be reasons.
Open source is distributed. A maintainer of a library has no obligation to collaborate with anyone. You can fork and use their code. Be thankful they give you that permission (they don’t have to).
If you feel GHC SC/HQ, CLC or other major bodies/projects are being uncollaborative, please reach out to the Haskell Foundation. It can often be lack of time, miscommunication or other things.
7 Likes
I’m astonished you have no awareness.
I’m astonished that you seem to have stopped at precisely the first line and failed to read the rest. How were you gate kept and from what exactly? John was extremely respectful in answering all of your queries. He has a point of view, too. It seems to me that if you felt “gatekept”, then you felt gatekept because you met up with a worldview that didn’t match your own and that was frustrating. But I see nothing in here which could be construed as insulting, or gatekeeping other than the insertion of jargon, which you already knew! How then are you being gatekept? This is the sort of entitlement that I’m talking about above: you are neither entitled to everyone’s agreement, nor are you entitled to have everyone speak to you in the manner in which you want to be spoken to.
The world just doesn’t work like that. If you want people who think, feel, speak, and write in the same manner that you do, find an echochamber, write a diary, or train a chatgpt bot on your posts. Otherwise, you are insulting everyone in that thread who took the time to engage you in collegial debate.
13 Likes
I ended up going on a rant, so I’m just gonna put a little summary here at the top…
TLDR: We need more people championing and working on the “smaller” issues like duplicate record fields/namespaces,cabal add <package>, and better documentation/business focused packages.
Rant following below.
I do have one (maybe unpopular) thought to offer here thats in agreement with @AntC2. He made a comment here saying:
DH has sucked all of the air out of the room
…
I want it to take the language as at 2016 (Pattern Synonyms) and continue all the half-finished other stuff – like FunDeps with Overlapping, a records system, Datatype contexts done
It’s not that I dislike dependent haskell; on the contrary I think it’s really cool and I look forward to finally seeing it arrive. But I think there were issues more important to work on than DH, atleast as far as helping haskell become more mainstream is concerned.
Haskell is a powerful language, but it has some very annoying quirks, like the duplicate record fields issue, or having to dive into a cabal file to add dependencies instead of just calling a command like cabal add <package>.
I recognize that these issues are not “major” problems and can be side stepped atleast relatively easily, but they are annoying. Annoying is the evil twin brother of convenience, and if I’ve learned anything from Google (anecdotally confirmed by my own experience with my colleagues), convenience is far more pursuasive than power. In my own job, I’ve recommended powerful tools over and over again, only to have them bypassed for an inferior tool that was way more convenient to use.
If our community put as much effort towards fixing the annoying issues as it has towards the large milestone issues, we’d probably already be atleast heading towards greater growth.
For example:
John Ericson is currently advocating for the pattern signature proposal here. I don’t mean to be dismissive of his efforts, but I don’t believe newcomers would care much for this. I surely don’t understand it too well and I’ve been using haskell for a good while now.
Richard gave up on the Local Modules Proposal because “there are other battles to fight!”
Perhaps this is why people say we’re more focused on academics than on being practical? I assume fixing issues like record dot syntax (fixed already), local Modules, and improved tooling like cabal add <package>; are low hanging fruit compared to something like DH, or improving the architecture and organization of ghc. But we’ve put all our efforts on the huge things and neglected the little ones.
I didn’t even consider haskell viable for serious use until HLS and RecordDotSyntax came into the world, but haskell has obviously been viable for a long time now. I also think D is a really cool language, but it’s language server is very buggy so I dismissed it. Zig is a cool language, but they have no package manager, so I dismissed it. I don’t mean to be this way but I can’t help who I am, maybe it’s because I’m immature. But I think this is what we’re up against when other programmers in the greater community look at haskell and see annoying issues that arent fixed. They’re quick to dismiss.
Sorry for the rant! I hope my thoughts have come through clearly
8 Likes
If you think there are features that need to be added to the Haskell ecosystem then the only thing to do is to continually advocate for them, and advocate in an effective way, such as making connections with the maintainers of the corresponding tooling and entering a dialogue with them.
1 Like