Hello Discourse!
You can check out the minutes and agenda for the Board meeting that took place on the 2021-09-23
Have a nice week-end!
I don’t quite follow the “… letting Haskell die” thread? I’m missing context for sure, why would this need to appear in the minutes?
Andrew: We need to help the junior professional developers get better. This demographic
needs more hand-holding, and they are at that point where they can make a big mess, so how
can we make the tooling & learning materials get better? By “junior professionals”, I mean that
they can have a lot of skills in other languages but are still relatively new to Haskell in a
professional context. This is to help the industry.
Isn’t it to help the developers? Regardless of what their intention behind learning Haskell is?
If you can’t get them up to speed, then selling a new company on using Haskell is going to be incredibly hard.
Why sell Haskell? Whether Haskell is a good fit for a company is a matter of evaluating their situation, business needs, hiring capacity etc.
It makes me sad to see that the focus still seems to be on salesmanship catered towards industry and less about how to make the language better, regardless of its application: be it hobbyists, open-source, research or industry.
Mission notion: Amplify the impact of the Haskell language.
Amplifying impact can be done in ways that aren’t helping the language itself. Look at Java.
“Salesmanship” can mean many things, and it’s a skill successful academics deploy all the time too: it’s about showing the best parts of something in a persuasive way.
Also, I really don’t understand your bias against making the Hs ecosystem attractive to “industry”, which too can mean anything from
a bootstrapped 3-people operation to IBM. If anything, it’s high time to open up to the world after being trapped in “good enough” limbo for 30 years.
I wasn’t questioning the nature of “salesmanship”. I was questioning the focus of the mission statement/strategy, which has also been discussed here in great length: https://groups.google.com/u/0/a/haskell.foundation/g/board/c/pxyFatD_BrI
From reading the meeting minutes, I don’t see much of a change regarding my concerns.
I do not have a bias against making the HS ecosystem more attractive to industry. But doing so is a side-effect of caring about the language, the ecosystem and the community, regardless of its application.
The excessive focus on improving industry adoption, catering towards industry users, getting haskellers “up to speed” for industry etc. instead is what sounds biased.
“Excessive focus”? Seriously, knowing the history and context of Haskell, this is pretty rich.
“Excessive focus”? Seriously, knowing the history and context of Haskell, this is pretty rich.
Yes. The Haskell ecosystem was largely built by volunteers. Some of them also happen to work with Haskell in industry (including myself). Some don’t. There are very few companies who really focus on improving the Haskell ecosystem. Most of the time we do it in our free time after work.
Industry isn’t the main driver of the ecosystem. It’s developers. That means us.
I want to see how HF plans to engage the community and its developers better, not just worry about startups picking Haskell as their language.
Those things are subtly intertwined, but it’s a pretty large difference whether you primarily care about improving the language or improving adoption.
I too am both an active OSS contributor and a commercial user and I’m largely with you on these issues.
What I see as a qualitative difference is that there is no potential end to “improving the language” (it’s a meta-language born out of the need for experimentation after all), whereas improving adoption revolves around a set of mundane infrastructural issues such as documentation, GHC and base stability, IDE tooling, Hackage ux, build systems, including paying the bills for aforementioned hosting and build systems… and fixing these things with, yes, industrial support, will benefit all, commercial or not
I remember a great talk from SPJ about improving computer science in education. So why not “Increase Haskell adoption in universities” for example? Where did all that go? I’m confused.
There are Haskellers that aren’t even working in industry but are indispensable to the community.
I believe the mission statement should be inclusive and be a representation of the community.
There are Haskellers that aren’t even working in industry but are indispensable to the community.
If, as I hope, we are not talking past each other, the original point was about creating educational resources or other on-ramp conditions for “”“industrial”"" programmers (and, transitively, their employers) who might consider introducing Hs.
I really fail to see why this would be a bad ideal to strive for; should we really understand PL communities as zero-sum? If anything, inclusivity should cut both ways by definition.
And while I’ve long been wary of corporations coopting open source communitites while giving little back, I think increasing the chances of the HF getting some substantial funding on a recurring basis that would be funnelled back into community activities is a very worthy goal and indeed a priority.
IMO it’s past time Haskell stops playing minor league for the sake of chasing some impossible ideal of perfection.
Again: I’m not anti-industrial.
But, to be frank, I think HF is only something worth supporting IF:
You make a good point here. We don’t want Haskell to be adopted because we are better at advertising than anyone else. We want it to be adopted because (we believe that) it’s a better way to write software.
But “a better way to write software” encompasses more than the language, dear to my heart though the language is. It encompasses compilers, installers, libraries, tutorial materials, and community. I think we (all of us) want to make all of these things better.
So I see a drive to “adoption” as shorthand for “make the language and its ecosystem of tools, infrastructure and community work smoothly together, so that there are no barriers to adoption, and so that the benefits of adoption are clearly but truthfully displayed”. That’s a bit of a mouthful. But if the shorthand doesn’t work, or can easily be misinterpreted, we should work on the language.
The other thing to bear in mind is that what is a barrier to adoption for a company may not be a barrier to adoption for a hobbyist. If I’m going to bet my company on your language I want to be pretty sure that I’m not going to be stuck because SPJ goes awol and GHC doesn’t work, or that a new release carelessly breaks everything. I need robust tools and the confidence that they will work.
So the bar is higher for adoption at larger scale, and that in turn needs more resources, which in turn may be available if we have a credible story for how they will be spent to give that higher level of reliability. The HF is in part there to provide that credible story.
So I see the HF’s apparent emphasis on corporate users as being to do with addressing that higher bar. But everything done for that higher bar also benefits hobbyists, teachers, students, open-source enthusiasts. It’s not “instead of”, it’s “as well as”. We really do want to improve Haskell for all audiences.
Excellent! Why don’t we say exactly that?
Something like:
"The Haskell Foundation stands for improving Haskell: the language, the ecosystem and the community. Because we believe it’s the better way to write software."
This encompasses that we care about, well, all users. We don’t have to go on a witty tangent and pull out the whole story from under the carpet of industrial use cases. I believe it wouldn’t be the right signal.
I don’t want to be argumentative and I totally see what you mean with robust tools and proper support for GHC. But I’ll admit that through my personal career, the highest engineering standards I encountered in open source projects that someone did on the side (as a passionate project) and the lowest engineering standards I’ve encountered in industry (because meeting deadlines was always more important than dealing with possible technical debt).
And I think we want to facilitate the ability to exercise high engineering standards through the language, even if most industry users aren’t particularly interested in those.
Otherwise I pretty much agree with you and I think we’re on the same page.
I definitely agree with julians points here. Industrial code seldom if, ever a useful quality bar. It’s more typically the trash tier of “it works enough for a narrow reading of then goals”.
Thank you Simon, this (as always) goes to the heart of the matter.
This has nothing to do with tongue-in-cheek jokes about the poor quality of enterprise software (??) and everything to do with the sad realization that OSS doesn’t pay the bills by itself.
Louder for the folks in the back : in order to make Haskell better for everybody, we need a coordinated, extensive effort which will likely require money. And people won’t donate to our Kickstarter just because we’re cool and different from the rest, but because we make something they value.
Good point. I didn’t mean to imply that volunteers have low engineering standards – that’s certainly untrue. But with the best will in the world, it’s really hard for a volunteer to consistently, week on week for years on end, guarantee the kind of reliability that someone who is betting their company on Haskell needs.
For example, suppose there is a bug in the garbage collector, so the program crashes. That can be agonising if your business depends on your website working; but it’s really hard to expect a single volunteer to drop everything to fix it, which might in any case be extremely tricky to do. Especially if the person who wrote the original code has long since moved on, so it’s not clear who is responsible any more.
Another aspect is that there many boring-but-vital bits of infrastructure. As a volunteer myself, I’m motivated to spend time on (say) implementing impredicative types in GHC, and I would like to think that I do so to a high standard. But it is less easy to motivate myself to (say) fix a potential security hole in Unicode string processing (a recent example). Yet it still very important to get it done.
So I am not implying even a scintilla of criticism of volunteers, or their technical skill. But to make Haskell really “a better to way to write software”, I think it is important that we complement that passion and technical skill with consistent bread-and-butter “glue”, to make sure that all the pieces work together. That’s the bar that gets higher if we want to broaden adoption.