All right, so our final talk for the Dev Room today is by David Christensen.
He is the Executive Director of the Haskell Foundation and has worked with Haskell and
functional programming in both academia and industry.
He was a major contributor to the first version of Idris and its Emacs mode, together with
Daniel P. Friedman.
He wrote The Little Typer, an introduction to dependent type theory, and is currently
working on functional programming in Lean and introduction to writing programs in Lean
4.
His presentation today is Open Source Opportunities with the Haskell Foundation.
Thank you, David.
Thank you.
So, as a brief overview, I'll be presenting three major sort of categories of speech today,
I guess.
A bit about lore and values of Haskell for those who are new to the community, a bit
about institutions and projects that kind of keep us all up and going, and at the very
end I will plug my employer, the Haskell Foundation, as one does.
So to begin with, lore and values.
Many people coming in here who don't know Haskell so well might be thinking, what is
Haskell?
And I'm not going to answer that at all.
I'm going to answer another question, which is, who is Haskell?
And the reason why I think this is an interesting question to answer, well, my thinking was
really influenced by this essay by Ken Pittman from back in 1994 called Lambda, the Ultimate
Political Party, which was kind of a riff on a series of MIT, AI lab memos, Lambda the
Ultimate X, where X are things like op code and so forth.
And most of this is a bunch of details about the LISP standardization project of the early
90s, which is not so relevant anymore to most of us.
But for those who are not historians, the author makes a wonderful point where he proposes
a thought experiment, and in this thought experiment he says, take the LISP community
and give them the C programming language, don't let them talk to C programmers, come
back, check in after some time has gone by, and what should you expect to find?
Well, you should expect that the version of C that the LISP hackers have been hacking
on has grown Lambda, it's grown garbage collection, it's grown fancy interactive environments,
it certainly won't run on low end machines anymore, whereas you'd expect that C would
be sort of basically like C, but better in the ways that C normally gets better, like
maybe Boole has become a type and things like that.
This is from the perspective of 1994, that was not the case yet.
And what this really says is that the way we should understand a programming language
is really as like a shared artifact for a community of practice, like a group of people
who are working together on some project.
We're not all identical, but we all have something in common which draws us to this programming
language, and what this really means is that like the values of a community shape the development
of a programming language over time, and the shape of the programming language affects
the values of the community, because if you hate it, you're going to leave.
So, what are some values of the Haskell community?
Well, we think that elegance is a very important thing, very, very important.
But we also like to build things that really work, you know, there's a stereotype of Haskellers
who, you know, like once they're programmed type checks, they just like delete it because
they're done, and that's not true at all.
We really do like to build things, you know, like, I used Xmonad for like a decade, but
also we really do appreciate a mathematical inspiration, you know, we like to sort of
be able to look at a thing and say like, oh, from this branch of mathematics, this means
this thing.
And a few of us do that, and the rest of us look at those people and say like, yeah.
But as opposed to, eh, right, we also really like playing with things, you know, like playing
practical jokes in the type system is something that will get you respect rather than discussed
in Haskell.
We have a real culture of like colluding through a thing, and then cleaning it up and making
it elegant and beautiful later, like you're not expected to prove theorems, and then do
your work, it's more like find a thing that works and then see if you can prove something
cool about it.
We tend to be pretty anti-authoritarian and independent people, that makes my job as chief
cat herder more kind of like chief mountain lion herder, which is fun, and typically when
we want to make a thing that works well, we're going to be using kind of lightweight semi-formal
methods like, you know, fancy types or property-based testing, things like that, as opposed to other
processes that are used more so in the rest of the world.
We like cleverness, you know, if you can come up with a thing that's like fancy and powerful
and cool, like people look at that and say, yes.
We tend to have low power distance, you know, if you go to a Haskell event and the person
with like the gaggle of young Haskellers following them around says something and you
talk back to them, you're likely to be met with respect rather than with like rejection
for having dared cross the great leader.
We like novelty, and we tend to have a lot of respect for knowledge, and we don't want
to say like, oh, that's just book learning, and we also tend to be a bit insular.
There's a bit of like a not-invented-here thing that happens quite often in Haskell,
and also we've sort of mass-imported a lot of random-unix stuff, like, you know, a preference
for kind of grody command-line applications.
I think some non-values of the community.
One is like achieving correctness through formal discipline organizational design.
That certainly happens in some organizations, I think more in the corporate world than in
the open-source world.
But we also tend to not use traditional software engineering practices even when it might be
relevant and useful because we just kind of look at that and say, huh.
And also, while we value simplicity and beauty in our language, the things outside of the
language we often look at and say, yeah, it's okay if that's a bit crunchy.
So where is all this coming from?
You know, a community has values, but it also has history.
Well, back in 1976, two very important things happened.
The first was a paper by Dan Friedman and David Wise called, Cons Should Not Evaluate
Its Arguments.
Cons is the name of the list constructor in old school lists, and today in lists today.
Also David Turner made a new version of the St. Andrews static language, which was lazy.
And this sort of gave rise to a cottage industry of cool things that are not all in the slide
here because there's too many of them.
One notable example in 1984 was lazy ML from Schalmers and also of course Miranda in 1985.
And as we almost know, Miranda is a trademark of research software limited.
And so then a bunch of other languages came out, like Orwell, Alpha, Clean from the folks
at Nightmakin, a really great, interesting language with some cool ideas you should look
at, Ponder, and then people would think, well, we've got this nice compiler over here.
We've got this nice library over here.
We can't use the library with the compiler because they're different languages, but there's
not anything importantly different about them.
It's just that this one came from this university and this one came from this university.
And to be clear, this was a very university-led phenomenon, all of this lazy programming in
the 80s.
And so a committee got together, and in 1987 and through 1990, they started working on
the sort of committee language that they would essentially shave off all the things like,
this one uses a single colon for the types, this one uses a double colon, this one uses
a capital letter for constructors, this one uses a lowercase letter, and shave off those
differences and make this language where you could use a library from the one site on the
compiler from the other site.
And unfortunately, when you get research, fortunately or unfortunately, when you get
researchers in a room together, they tend to do research, and all of a sudden they figure
out type classes and they start to do an I.O. with monads, and then Haskell was born.
And the, yeah, yay!
So the 1990s was like a period of furious hacking both on the definition and the implementation.
The two kind of went hand in hand.
There were lots of implementations with Haskell in the start, you know, because the idea was
that it would be a common standard for implementations, sort of like, in this sense, more like C or
common Lisp, and less like, you know, Python or Perl or Rust, which are sort of defined
by their canonical implementation.
You know, in 1992, work was started on GHC, in 1995 on hugs, has anyone in here used
hugs?
Ah, good, some hands, yeah, so back in the day, GHC didn't really, didn't have a REPL,
so you'd use hugs for the nice interactive environment and the error messages, and then
you'd use GHC to compile your code, kind of like standard ML programmers do with like
SML and J and Milton.
You know, and by the end of the 90s, we had the Haskell 98 report put together by the
committee, and by 2001, GHCI came out, and I see this as kind of a watershed moment,
because it's when GHC began starting to kind of serve all of the needs of the Haskell community
rather than just the batch compiler to make your fast code need.
You know, in the 2000s, we had a fairly finished language standard, right, the Haskell committee
disbanded itself after Haskell 98 came out in 1999, and a while of work was put into
making Haskell go fast, like let's make the compiler generate better code, let's look
at all these nice optimizations we can do, also at doing like reliable concurrent programming,
so we got a lot of cool like parallel Haskell features, we got software transactional memory,
all this like space age technology stuff from the perspective of the mid-00s at least.
And in the 2010s, you know, as I should say, in 2009, we got the Haskell 2010 report, and
that was actually the last major revision to Haskell, and there isn't really a committee
around it anymore that feels like they can define a new Haskell language, and in some
sense, this report was a little bit anachronistic, because by this point, GHC was the Haskell
implementation that everyone was using.
Through the 2010s, GHC was extended with all sorts of super fancy types.
You've seen a little bit of them today, but there was this whole line of research of how
can we extend the expressive power of the type system while still keeping a lot of the properties
we like of Haskell, like being able to write down a simple program and have it tell me
what the type should be, as opposed to having me tell it what the type is first, and then
having it check the program.
And it's, you know, we're only a little bit into the 2020s, but I think that what's happening
here is that we're going to finally deliver on our potential of having the best experience
driven by the fancy types and the fearless concurrency and all these things, but we'll
see what happens.
So a little bit about institutions.
I've been talking a lot about sort of community and history, but a community is more than
just a group of people, there's also, you know, figures within any community who kind
of set the agenda for that community, who others look to for leadership and inspiration
from time to time.
And an interesting thing about Haskell, this comes up a lot in various discussion boards,
is people will say, what is the Haskell X, right, where X is drawn from the set containing
build tool or tutorial or book or IDE or compiler or whatever.
And in fact, we can't answer that question because unlike something like, you know, Python
or Rust or many other of these implementation defined languages, there isn't really any
organization that owns Haskell and can say, we're going to now say that this is the official
Haskell X.
And, you know, like, we're essentially defined by GHC, but it doesn't have, the GHC project
doesn't have this kind of leading role in the same way that, like, the Python project
has in Python.
So that's, we do have various committees that are, you know, that exist and people mostly
do what they say.
And like I said, we're a fiercely independent bunch of people.
So there's the Core Libraries Committee and they're the ones who are maintaining and controlling
the standard libraries, so things like strings and lists and all the basic stuff that you
need that essentially every Haskell program is going to need either directly or transitively
through other things.
Then we have the GHC Steering Committee and the name of that committee is a bit misleading.
In fact, what they do is they evaluate changes to the language implemented by GHC.
So in some ways, this is the forum in which changes to Haskell are discussed and if you
have input about it, that's where you should show up.
Also if you'd like to participate, you know, they regularly have new nominations, so it's
a place that you can do that.
And then we have the Haskell Org Committee, which is responsible for administering the
Haskell.org site and that's both the website but also, like, the sub-domain namespace.
So when I needed to get errors at Haskell.org for a thing, they're the ones that I went
to and asked.
And they also, for historical reasons, run the Google Summer of Code or Haskell Summer
of Code when there is no GSOC.
The key tools in Haskell, as we've seen earlier, there's the major compiler, GHC.
We've got HLS, which gives us all those fancy features that we saw earlier in the talk.
There's Cabal and Stack are the two major build tools.
There's GHCUP, which is like a tool chain installation and management program, which
is quite convenient to use.
There's Hackage, which is kind of our C-Pen or C-10 or crates.io or depending on where
you come from, one of those might make sense to you, which is a centralized repository
of packages.
Luckily, we've just got one of those.
Stackage is a version-pinned distribution of packages from Hackage that have been tested
to work well together, so you can get a coherent set of stuff.
These days, like in the old days, as the name suggests, Stackage used to work with Stack.
Now you can also point Cabal at it as well, if you want.
Then there's Haddock, which is a documentation generator, and it's in need of some serious
refactoring.
The maintainer is sitting over here, so if that's something you'd like to get involved
with, you should go talk to them, because that could be a really useful way to help
out.
Also, GHCUP, I know, is looking for a co-maintainer to share some of the burden there, so that's
another good place to get involved, where you don't have to be a super-type system expert.
Last meeting's Haskell Playground is looking for volunteers as well.
This is a sort of up-and-coming project to have sort of online place where you can go
put in some Haskell code and run it and see what happens, without having to install anything
on your machine or anything like that.
You can think of it as, essentially, like an active paste bin.
I've been instructed to tell you to look at the help-wanted and good first-issue labels
on the issue tracker, and mentorship is available from the author.
The Haskell Foundation is the other institution that I didn't talk about with the first ones.
We're a very, very new non-profit, just a couple years old, and we are trying to broaden
the adoption of Haskell because a programming language is more useful when more people use
it, so the more people we can get making cool Haskell stuff, the better it gets for all
the rest of us.
Also, we think that there's a lot of really good things in Haskell that haven't, like
good ideas, that haven't spread as far as they could yet.
The rest of the world definitely deals with first-class functions now, so we've succeeded
there.
The rest of the world is basically catching on about monads, so we're succeeding there,
but there's a lot of other cool stuff that I think we still have that if we want to make
the world a better place, we can spread those good ideas.
The point of the Haskell Foundation is not to come in and take over everything.
Our goal is really to support existing processes from our fiercely independent Haskell community
and figure out what opportunities to help out.
I am the executive team, so I've been in that role since May of 2022, so I'm still fairly
new at it.
I used to work at Gelwa and Deon Digital.
Before that, I have a PhD from IT University of Copenhagen from 2015.
I also did a postdoc in Indiana University.
I worked on interest one, and I helped write the little typer, and I'm working on functional
programming in Lean.
As you can see, I'm into dependent type stuff, but that's really not the focus of where I'm
working in Haskell.
I think dependent types are cool, but there's way more cool things than just that.
The other full-time person we have at the Haskell Foundation is Brian Richter, who you
may know online as Shriekat.
I'm actually not sure how to pronounce that.
CHR is a consonant cluster found in my own name, but nonetheless unusual in English.
He's doing full-time DevOps and CI work for the GHC project and helping to unstick things
there and make it easier for both the existing team and new contributors to work on it.
He's also looking for volunteers to help out, so if you have knowledge of CI and DevOps
things generally, and in particular GitLab, Nix, Python, Bash, and or PowerShell, get
in touch with him and he'll put you to work doing useful, interesting stuff for GHC.
Another project of the Haskell Foundation is the Haskell error index.
This is a new website, which you can get at errors.haskell.org.
It really got its start at Xerahack last summer.
The way this works is that participating Haskell development tools, and so far there's three,
that's GHC stack and GHC up, can assign a unique code to each of the error messages
and warnings, and then these can be looked up on this website.
The website contains, for a given error message, detailed description of it that's sort of
longer than you could put in the error text itself.
It can contain any number of examples, so ideally we're going to be providing sort of
a before and after example, like a program that exhibits the error message and then one
in which it has been fixed, along with details about why that program exhibits the error
message.
I could really use some volunteer help on this one, so if you're good at CSS and JavaScript,
then dark mode support would be super useful, and also we put some work into the CSS, but
it could use more, like it's not the most beautiful of websites yet.
Also writing documentation content is super useful.
If you know enough Haskell to understand one error message and you can write a markdown
file and use git, then you have the skills necessary to contribute documentation for
one error.
So far we have 72 in there.
I hope that with the new GHC release coming out that supports the error codes, we'll quickly
get the 371 remaining errors documented, no, 271.
And also, if the site backend is a static site generator written in Haskell using the
HACA library, and right now the deployment script takes too long to run, and if you can
help me with the caching to fix that, that would be awesome, because I'm terrible at
that stuff.
As you saw earlier, Frasier is running our security advisory database.
This is a new project, a new initiative, sort of inspired by the Rust and NPM advisory databases.
The idea is that it's going to serve as a data source for tools like Cabalstack and Dependabot.
And in particular, a lot of organizations that want to use Haskell need to pass ISO
2701 certification, and doing that is certainly possible without one of these automated scanners,
but then you have to have a conversation with the auditor, and that makes things slower
and riskier and more expensive.
So if you can just check the box, that's much better.
Also there's real value in finding out whether or not one of your dependencies has some sort
of a known issue.
Volunteers are wanted for the security response team, which is going to be administering the
actual contents of the database, but also for tool development.
It would be great to be able to sit down and say, you know, Cabal audit or Stack audit
and have it spit out a list of things to look out for, and also some public communication
help could be useful.
Right now we have like a data format for the database, but generating a nice website that
documents everything in the searchable would also be a really useful contribution.
We have a podcast, the Haskell Interlude podcast, which is looking for guests, members
of the Haskell community.
So if you'd like to get on there and have a discussion with some leading Haskellers
about what you're up to, that would be really cool.
Email podcast at Haskell.foundation.
The Haskell Optimization Handbook is an in-progress text on how to make Haskell code go fast.
I blurred out the address on there a little bit just because it's in the process of moving
from one address to another one.
But if you Google it, it'll come right up.
This is being organized by Jeff Young who works at IOG.
He's known as Do You Can Do on the Internet, so you can get a hold of him if you'd like
to find ways to contribute text or infrastructure to this project.
In addition to all of these sort of concrete technical things, we're also orchestrating
the Hackage Security Signing Process.
So Hackage uses an instance of the Update Framework, which is a sort of standard way
of securing software repositories against man-in-the-middle attacks and untrusted mirrors and these kinds
of things.
And part of this process is that we have a collection of trustees who have keys, and
any three of them have to sign the metadata file from time to time just to keep the thing
going.
And they're certifying that all of the associated roles are correct.
And that's been a volunteer-led process in the past.
And we've had a couple of times where we thought, uh-oh, we've got to sign this real
fast, otherwise things are going down.
And so the HF is, by being a professional organization, we can put a thing in the calendar
and get the process going in plenty of time and all of those things.
Also, we're going to be doing a sort of lottery factor audit of key projects in infrastructure
soon and try to find more places where we need to recruit extra maintainers for important
projects and that kind of thing.
Some people call the lottery factor a bus factor, but I'd rather think in terms of how
many people can win the lottery and retire from computing forever without the project
collapsing.
It seems a little happier.
We've also spent some time helping out the GHC developers.
The results of this end up on discourse.haskell.org, typically.
Recently they asked us for some help in going out and surveying a certain number of GHC
users about priorities for the next six, nine months.
And then we collected feedback on that and then developed a report where they said what
they're actually going to do based on the feedback.
So this is available to be read.
And right now we're trying to do something similar for a project on making nightly releases
easier to get to.
So right now you can get nightlies if you know the incantation, but we'd really like
it to be super easy to get a hold of them.
And so if you go find, if you think that you could use nightly releases for something,
then please go find the discourse thread and post because that way we make sure that whatever
solution we have incorporates your use cases as well.
And I've already discovered a few that I hadn't thought of, so that's been a useful process.
We're organizing a workshop for new GHC contributors.
So if you'd like to get started on hacking GHC, but don't yet know how, then you should
come to, then you should come to zero hack three days before zero hack and get an introduction.
This is still an in progress thing.
We don't have a specific speaker list yet.
Simon's definitely talking, but the rest is depending a little bit on a survey that's
out there.
So if you fill out the survey and say what you're most interested in learning to hack
on, that'll affect the people who we invite to come and present parts of GHC for potential
contributors.
And also if you know how to run a hybrid event well, get a hold of me, I don't.
I'm going to do my best, but if you could spare 45 minutes on the phone with me to tell
me all the things I'm about to do wrong, that would be very valuable.
So email me if that's a thing.
We have two big working groups at the moment.
We have a technical working group which evaluates various project proposals and especially proposals
where Haskell Foundation like administrative time or money would be useful.
And so if you have something like that, please come and give us a proposal and we'll discuss
it and try to refine it and eventually hopefully fund it or administer it or otherwise carry
it out.
We've also used this to host like a community RFC process in cases where that's needed because
as I said earlier, there isn't really anyone who owns Haskell.
So it seems as good a forum as any to have some of those discussions.
And we have a stability working group which meets every two weeks and we're looking at
which involves GHC developers and academics and others and we're trying to find ways to
reduce the difficulty posed by updates to the Haskell ecosystem.
And that's going to be some combination of social and technical means over time, lots
of small stuff.
Thank you for listening.
If you want to get a hold of me, I'm David at Haskell.Foundation or I'm Christensen
on Matrix.org.
And then the Haskell Foundation itself is Haskell.Foundation.
You can also look at Haskell.org to find out more about Haskell itself.
We have, we're on Mass on Twitter as well and the names are up there.
And I believe a few minutes, five minutes left so if there's any questions.
Thank you, that was a great talk.
So I observe like what Haskell Foundation does and there's like a lot of great initiatives
and I think it pushed the language forward.
But I'm wondering, so does Haskell Foundation measure somehow how popular Haskell is?
Every other month there is like a thread that Haskell is dying.
So I was just wondering like, do you have some like a concrete data that would say otherwise?
Like that, I don't know, like a job postings are growing or the number of companies that
using Haskell are growing or like the community is growing somehow.
Like do you gather some data like this?
Not particularly, no.
I haven't found a good way to do it that I think is going to be more signal than noise.
I don't think Haskell is dying.
I think that there's a couple of people who feel that way and they're entitled to that
feeling and they say it regularly.
But I don't think that that's a commonly held feeling is my impression.
I get the impression that's more a feeling that a couple of people have.
I know that I keep hearing about new users of Haskell who I'd never expected because
they're not very public about it.
Hackage continues to grow.
I see job posts on a regular basis which I didn't see a couple of years ago.
So those are all anecdotal qualitative things.
If you have ideas about non-misleading measurements that are cheap enough that I can do them being
essentially one person with a, you know, not tiny but not infinite budget then.
Yeah, definitely.
I'm not saying it's easy.
I was just wondering if you maybe do a self-light.
As you know from my background, as you could see from my background, like it's very much
on the like programming language side rather than the market research side.
So if you do have good resources, I'd love to hear them.
Sure.
Thanks.
Okay.
Any more questions?
It seems not.
So thank you very much, David.
Thanks.
Thank you.