Jasper Van der Jeug is interviewed by Niki Vazou and Joachim Breitner. Jasper plays an important role in the Haskell community, helping with haskell.org, the Google Summer of Code project, ZuriHac and the ICPF programming contest, so there is much to talk about.
Jasper Van der Jeug is interviewed by Niki Vazou and Joachim Breitner. Jasper plays an important role in the Haskell community, helping with haskell.org, the Google Summer of Code project, ZuriHac and the ICPF programming contest, so there is much to talk about.
Nikki Vazou: Welcome to the fourth episode of the Haskell Interlude. We will talk to Jasper about Haskell.org, Google Summer of Code, the 10 years it took to get UTF-8 into text, and running ICFP programming contest.
Hi everyone and welcome to the Haskell Interlude. I'm Niki and I have together with me Joachim.
Joachim Breitner: Hello. That's me.
NV: Our guest today is Jasper Van der Jeugt. So. Jasper is the developer of numerous open source Haskell projects including Hakyll, and very active in building a Haskell community. So even though my personal website is proudly generated by Hakyll, I met Jasper when we served together at haskell.org. So Jasper, can you tell us a little bit about haskell.org?
Jasper van der Jeugt: Hi yeah, so thank you for having me first and for all. Um so haskell.org is the foundation that's legally responsible I think for a lot of the stuff that's going on in the Haskell community. It has a board and you know there's um, people serve terms on it. Um I think it was originally started because there was this real need for sort of a legal entity for the Haskell community, since we ... And this was before my time, right, um, or before I was actively engaged and in the Haskell community. But I think yeah sort of we started getting some donations, for example through Google Summer of Code. And at that point the Haskell community didn't really have a way to receive these funds, and also for in order to register domain names and things like that, it was kind of set up as an entity to take care of all of that stuff. And since then it's sort of accumulated a couple of other responsibilities. Some responsibilities were added, some were moved again to other committees. I think it's actually a little bit of a complicated situation right now, and, like it's, it can be a bit confusing who is responsible for what in the Haskell community. So I think this is one of the things, when we, when the Haskell Foundation was launched last year, um, that we would like to fix, basically. So apart from the haskell.org committee, there's also plenty of other committees like the Core Libraries Committee the GHC Steering Committee and so on. There used to be a separate committee for the website as well. That was sort of spun off after there was a lot of disagreement on how the downloads page should look like. And so we sort of got into this situation where you have all these different small committees. It's not really clear who is doing what. I mean, some of the responsibilities are clear, right? Like for example, haskell.org has been organizing Google Summer of Code for a long time and I think, I mean it's mostly myself, but I think we're doing a good job. There's other things that it's also, um, doing well. But it's really just a few volunteers and you kind of need a larger organization, I think, to push through some changes. I think the haskell.org committee is good at sort of like looking what was there and making sure everything stays working and so on, but definitely I think, if you look at the past five years or something, it hasn't been great at actually driving change. So really I hope the Haskell Foundation is. Yeah, they just have a little bit more resources, of course, and they're in a place where they can I think talk more easily because they're sort of an umbrella organization. It's easier for them to communicate with the other committees like the Core Libraries Committee and really, you know, get stuff done.
NV: So, I think it is my understanding, and maybe it's important to make it clear that haskell.org supports the Haskell Foundation and it's like, the goal of Haskell Foundation is to achieve more things, and as you said, but maybe you can clarify, to make change under a more official organization. But it's a collaboration, right?
JvdJ: Right. And I think the goals are really largely the same for both organizations, like we both want to see basically increase Haskell adoption, make it more easier for new people to get into Haskell, and make everything sort of smooth run, make sure there's no large bad disagreements in the community ...
JB: So when the Haskell Foundation was thought of and created, was haskell.org approached to see if if haskell.org as an existing foundation, an existing board, existing for so long, could just have grown into this new thing and and why was that not done then? Why do we now have two foundations that at least by surface value seem to be rather similar in their goals and scope?
JvdJ: I think that's a great question. Um, so yeah, I think Simon Peyton Jones together with Mathieu Boespflug from Tweag, and a few other people were, I think, Tim Sears as well, were the people who sort of came up with the the idea of the Haskell Foundation. Um, and haskell.org was really one of the first groups they contacted to get some feedback on the idea. The reason why there's two groups, I think, I think you can say that like haskell.org has been doing what it's been doing. But like, as I said before, it's not really good at sort of making these huge improvements to the ecosystem. I think the people who came up with Haskell Foundation took a look at other programming languages like Rust where they have this very strong community model. And basically said like, okay, why can't we do that, right? Like it seems like a very good model to drive contributions and to get new people in, um, so we can give that a try for Haskell. Um, this is my personal opinion and not speaking for the committee or or whatsoever.
JB: Sure.
JvdJ: I think it's feasible that in a couple of years there will be only one organization, um, that drives, because as you said they have very similar goals and so on. But also on the other hand haskell.org has existed for maybe 10, 12 years now ... No, it must have been must be way more than, I'm actually not sure. But what I'm saying is, it's been stable, right? And it's been able to to deal with all the legal stuff that comes up when when you run a nonprofit. So, whereas the Haskell Foundation is relatively new. Especially when it was sort of at its inception, we didn't really know how it was going to go, if was going to be successful, if it was going to be able to get more sponsorship from the industry. So you don't want to really, okay, let's go all in on the new thing immediately, right? And I think that's one of the, at least from my personal view, think that's currently a very good reason to have both?
JB: I guess it's an instance of "don't break a running system" and that there's this microservice running and it does one thing well and let's just build a second microservice next to it instead of just of redoing it and if it goes wrong, breaking the running foundation in a way.
JvdJ: Yeah.
JB: Yeah, that makes sense.
JvdJ: Obviously due to, like the Haskell Foundation has a lot of potential to be better, I think, if only for the fact that the haskell.org committee is just a couple of volunteers while Haskell Foundation is actually be able to employ people, right, to work on so full time, which makes a huge difference. So yeah, we'll see, I'm pretty excited for it, for the Haskell Foundation.
NV: Currently you keep, like, haskell.org keeps the Summer of Code, right?
JvdJ: Right. Yeah.
NV: Which is one of the most active, let's say contributions, that it is doing.
JvdJ: Yes.
NV: So maybe do you want to tell us what it is, for somebody who doesn't know?
JvdJ: Yeah, um, so Google Summer of Code is a program in which Google pays students who work on open source software. Obviously there's some, you know, you need to have some kind of filter, right? You can't just have students apply directly to Google, because then Google has to sift through millions of different open source projects. So maybe it's just the pet project of one student and so on. So the way it works is that organizations or open source projects apply to Google first, um, and they either get accepted or not. It's, the criteria, kind of, we don't really know much about them. It's like an internal Google process. And then once we, for example, haskell.org gets accepted, it's our turn to receive applications from students and then kind of decide which ones we want to accept, also guided by the budget that that Google gives you, of course. So there's ... so when I started, or when I became a member of the haskell.org committee, we actually weren't part of Google Summer of Code. We had been for most of the history of Google Summer of Code, I think, I think we only missed maybe the first year, um, then kind of missed out around the 2016 period I think, when there were some internal changes at Google and so on. I think they made the application process a lot stricter for the open source projects, whereas I think Haskell used to sort of get in by default, Even though we didn't really put a lot of effort into a good application. And then um yeah, obviously when we noticed that we weren't accepted for it, we organized our own Summer of Haskell. Which, so without the money from Google and just by finding sponsors on our own, which was also a great experience, but obviously it takes a lot of more, it takes a lot more time, right? If you have to go and fundraise yourself. So the year after that we just really took care that to, you know, really put a lot of effort into our application towards Google and we managed to get back in and, yeah, I've been sort of the main point of contact, I guess, for GSOC at Haskell for the last five years or something. And yeah, sometimes I try to mentor a student myself. Last year I mentored someone, like Beatrice. Beatrice made a lot of improvements to Stylish Haskell, which is ... I was pretty happy about it, because Styish Haskell is also pretty widely used now.
JB: What what is Stylish Haskell? Just for those who don't know?
JvdJ: So Stylish Haskell is a code formatter that will take a Haskell program and reformat it. So it differs from other formatters like Ormolu or maybe most famously goformat, gofmt from golang, which I think is the formatter that kind of introduced the idea that you just run your code through a tool, and whatever styling you used before, the output is always deterministic. And I think Ormolu is the one implementing that in Haskell, alongside a few others, and so Stylish Haskell is quite different from that. Because I really don't want my program to be reformatted too much, I would say. I think code is read a lot more than it is written. So if I spend like three minutes or something at this, like this complex section in a program that's hard to read and I spend like three minutes to really format it nicely and so on, I think they can actually be a good investment to do this sort of manual formatting. So Stylish Haskell is more of a formatter that takes care of the things that I don't want to do manually like sorting imports, aligning imports and those kind of things.
NV: Is it like HLint?
JvdJ: Um, no. So HLint really looks at the meaning of your program, where Stylish Haskell really just looks at the syntax. And for example, it will make sure, you know, if you have a Haskell program with a lot of imports. It will sort of align them all nicely with the things that you're importing on the same column in your terminal. It will align other things like record syntax and, yeah, bunch of improvements like that.
JB: Okay, so you were talking about the GSOC project for Stylish Haskell.
JvdJ: Right. Yeah, okay, to get back. Yeah, so that was a lot of fun. But ah, but this year unfortunately I didn't really have too much time to mentor someone myself, so I was just taking care of the admin work, um, but I'm still pretty happy actually about GSOC, especially because it was the way I sort of originally entered the Haskell community. Um, even though I had already written some Haskell code I wasn't interacting too much with the community. And that kind of changed when when I did my first Google Summer of Code code project when I was a student. Which was blaze-html. And yeah, just sort of met a lot of people through that process, virtual or in real life, like, I guess, Simon Meier and Johan Tibell ...
NV: So these were your mentors.
JvdJ: These were my mentors, yeah. And I think that project is really where I learned Haskell. So even though I was writing Haskell before, that's a point where I really learned Haskell.
NV: This blaze-html, what is that?
JvdJ: So blaze-html is an HTML combinator library. So it's a Haskell library that gives you a number of functions like for example ... and basically these functions map exactly to HTML elements. So for example, if you want to write a paragraph in HTML you would use a "p" tag. And so blaze-html maps that to a "p" function that you can give some text to, something text-like like a string or maybe all the nested HTML elements. So it kind of uses the ... I think it's called HTML combinator library because it really takes the approach of a parser combinator library whereas you ... where you sort of combine all these little functions in a pure way. But you do that for constructing HTML documents rather than, yeah, writing a parser, and this makes it different from what most people were doing at the time which is more akin to just having a text template that contains HTML tags and then some user data is spliced in.
JB: Right. And then I think your your second GSOC is kind of interesting, the second project where you actually took part, which is from exactly 10 years ago, 2011, and the goal was to replace the internals of Data.Text with a UTF-8 representation rather than the existing 16-bit representation, and of course that's amusing in this year, because the Haskell Foundation has funded a project to do that now and it's actually about to land. So, have you looked at the details of that current implementation, how it is different from your approach back then, and what prevented that GSOC approach back then to actually land in the main line of text.
JvdJ: Yeah, um, that's indeed a pretty funny story. So after I did the blaze-html project for my first Google Summer of Code, one of the other things that also came out of that was this library called blaze-builder, which I ... which was more like Simon Meier's thing than it was my thing. He put a lot of effort into that and anyway it kind of made me care about performance in Haskell a lot. And so I wanted to do a second GSOC project, of course, because I had such a good experience and I also felt that like I was getting better at writing Haskell code and there was this project for converting the text package to use UTF-8 rather than UTF-16. So I think it's important to mention that "text" was really a relatively new project at the time. That was, I think Tom Harper did for ... sort of in relation to his PhD thesis, and the big idea of this text library was at that point, it was more about having fusion than really having just a performant everyday library you want to work with. And internally it uses UTF-16 to represent text. So if you want to represent human-readable text and you know more than ASCII set, you also want to be able to include Chinese characters or something, there's a bunch of choices. So the most common one is UTF-8 and this means that the characters, encoded characters, can either be represented, if you have your memory, it's either going to be one byte, two bytes, three bytes or four bytes, and it's kind of designed in a way so that common characters, at least in English language, for example, ASCII, the ASCII subset just take up 1 Byte. So for some text it works really well, right, because you get just one byte per character. On the other hand some less commonly used, at least in English, characters end up taking three or four bytes. UTF-16 is a different representation where the units are sort of 16 bit with things, and you will either have one of them or two of them. So with UTF-16 you're really like every character takes up either two bytes or four bytes, where it's one, two, three or four with UTF-8, and the question is of course which one of the two is better and this is a very hard question and I'm not sure if there's a perfect answer for it. And so the main advantage ...
NV: Wait, what do you mean when you say better? Is it memory efficient, or runtime, or what is the criteria?
JvdJ: Well, that's also the hard question, right? What is the criteria? So like it could be either like it's just faster to process ... For example, UTF-16 is faster to process in general, because for every character you process, there's only going to be two cases, right? It's either two wide or four wide. On the other hand, if you're just processing English text, it may be possible that every character fits into one byte perfectly and then, even though you have four cases for every character you're processing, it's going to end up being a lot faster because you can just fit more stuff in your L1 and L2 caches. Um, and yeah, you sort of like have these really hard tradeoffs everywhere and it's really hard to kind of like, that makes it so hard to say okay, we're going to switch to UTF-8 because it's, yeah, better right? Because there's no such thing as better. Like each one of them has advantages and disadvantages. So for example, one common argument is that UTF-8 is always better for more memory efficiency because it can be smaller, but that's not actually the case because there are characters that take three bytes in UTF-8 that would only take two in UTF-16, so even the memory efficiency argument is very complicated. Um, so right, so I was working on porting the internals to use UTF-16 at the time ... sorry, to use UTF-8 at the time, it was using UTF-16. This was quite challenging, I think, I think my mentors didn't really think I was going to be able to do it. Um, because there was also a lot of benchmarking involved and I think I spent like half of the, some are probably just benchmarking things and it was kind of ... I think the project was sort of set up by Brian O'Sullivan, I think. Johan Tibell was like, okay, we should really properly see if there's any way it can be faster. And the way it ended up is that okay, I ended up with this port to UTF-8, and the question was really, is it better? And yeah, like in some cases it's better, but in other cases it's worse. And I think Brian especially was more on the on the conservative side at that time. And kind of more was making the argument, as long as it's not really clear that it's better in most cases, we should just keep things as is, right, in order not to break things, especially because there are also other linked projects that rely on the internal encoding of text, like the icu library and so on. So you wouldn't, while I finished porting text, I didn't really, like within this summer I wasn't able to take a good look at all the dependencies of text and so on. So yeah, we didn't end up merging it, because it, I mean it wasn't clear if it was going to be better. I think a lot of stuff did get merged, though, so for example, like a lot of benchmarking and testing code. But on the other hand I think now in retrospect it was ... we were never going to be able to say that one way is really better just because there's so many different tradeoffs involved. And so yeah, the funny thing is that now this project has been sort of revived. Even though none of my code is in it, I think, because just the actual internals of text have evolved so much since ten years ago that just the code I wrote isn't super useful anymore.
JB: But so but what has changed since then? Is it just that now the text maintainers are a little bit more willing to say, oh yeah, this is a change that may degrade performance for some but we expect that it is actually a better choice for most of our users, or is there anything else that has changed an ecosystem of text or the mentality of Haskell developers to make it possible now?
JvdJ: I think what's changed is that, and I'm not really sure, because I was a student at the time, of course, I didn't really know how the internet worked and how companies work and that that kind of thing ... And it's only ten years ago, so I think back then UTF-8 was already becoming sort of ubiquitous on the internet, like pretty much everything was encoded in UTF-8, but at the time there was also still big projects and libraries using UTF-16. So obviously the advantage, I didn't actually mention this, sorry, so the advantage of using UTF-8 is that a lot of text, basically maybe pretty much everything you find on the internet and like JSON documents and like programming language source code, it's all almost almost exclusively encoded in UTF-8, so that means if you're reading a file encoded in UTF-8 into text which uses UTF-8, you can do it really fast, and that's really sort of the main advantage. And I think, this sort of UTF-8 everywhere has become more clear over the past ten years. Maybe another thing that's helped is that there's other programming languages who have just sort of chosen for UTF-8, and it turned well, so you can kind of use those as a success story.
JB: Yeah I think that makes sense.
JvdJ: And obviously the, I think, Haskell Foundation is also a bit directed, of course, by what the industry wants. And think especially for, yeah, in the industry it makes just sense to use UTF-8 at this point.
JB: Okay, maybe on to what's more entertaining topics, because I think there's plenty of that related to your work with Haskell as well. In particular very recently you've organized the ICFP Programming Contest. So how do you get to do that?
JvdJ: That's an interesting question. I'm not really sure how I got to do that. Um ...
NV: Would you do it again?
JvdJ: So first of all, no I would never do this again. It's been one of the best experiences, sort of programming-related, I have had, just because you really um, okay so maybe we need to put a little bit more more context here. So the ICFP contest is a programming contest that's held, so it's affiliated with the ICFP conference, which I think maybe most listeners know. Um, so it's a yearly held contest, you ... teams take part. You can be a team of any size. You can also just participate on your own. I think that's one of the things I quite like about this contest is that the barrier to entry is very low. Like there's no entry fee or whatever, you can just have a look. If you like the problem, you can get started. If you don't, well you can do something else with your weekend. Um, and so it runs for 72 hours. So it's pretty intense and I've been taking part of it for most years in the past, I think, even though I'm more of a casual participant. So I don't do the thing where I don't sleep for the weekend and so on, right, and I also don't expect to really be competitive, because some of the people who would take part of this are just really really good at competitive programming. Um, I do it more just because I find it fun to write something like this in Haskell and it's usually, the problems are very different from what you do at your work, right? So it's pretty fun and then, yeah, so this year I was asked to organize it. I didn't do that alone, of course, like I asked my friend Alex Lang, because also he's one of the people I usually take part in the contest with, so we kind of have an idea of kind of what we like and what we don't like. We asked some other people people as well. But I think it was mostly us two, um and yeah, it's really, I would say it's really fun, really challenging. It's a lot of work. But you really sort of get to create your own world with its own rules. Um, I would say, because you get so focused into this problem that you're really inventing, right? There's no real world ... maybe sometimes there's a real world application. In our case, it was based on a TV game show. So the real world application is not super important.
NV: Which TV show?
JvdJ: Right, so this year the problem was based on this Japanese TV game show where you're, so you're standing next to a pool and there's this giant styrofoam wall coming towards you with a hole cut out, and the hole would but be like some strange shape. Obviously for ICFP Programming Contest we started with a lambda-shaped hole. But then anyway, if as you see this wall moving towards you, you're supposed to put your body into the shape of the hole, so that the wall passes you and you don't fall in the water, because if you hit the wall it sort of pushes you in the, in the water in the game show. Um, and this was our inspiration for the contest. Um, so what we would do is we would give people a 2D figure. So imagine a figure made out of just solid sticks connected with chewing gum at the at the ends or something like this. So you can kind of, you can't really bend the edges or something of the figure, but you can move all the corners. I think it's also similar to World of Goo if you've played this game before, but yes, you can imagine maybe with an example ... Like if you get a triangle, there's not much you can do with it, right? Because the edges are rigid so you can't really manipulate it or ...
NV: All of them are connected.
JvdJ: Yeah, because all of them are connected. But if you get a square, yeah, if you get a square or rectangle there's more you can do with it, right? Because you can kind of squeeze it together or make it longer and then especially if you have a bunch of squares and triangles and they're all connected and so on, it gets quite complicated. And so the idea was really that you people get this sort of figure made made up out of lines and you were able to manipulate the length of the lines just a little bit. And this was necessary because we were playing this game on an integer based grid. Um, that was just really an artifact of because if you're doing a competitive programming thing, using floating point numbers is sort of hard. Especially if you want to want to program a fair judge. So anyway to get back to the problem. Yeah, you really have to manipulate this figure and kind of put it into a shape that fits through the hole. The hole is also just a geometric primitive you would get. And then you would also be awarded a score based on how close the figure you folded into is similar to the hole. So more similar to the hole is better.
NV: And so I have two questions. One is: can somebody play the game now? Is it still up?
JvdJ: Yeah, yeah, so we, I mean, the PDF is still out there with the problem description and we also still have the website available where you can submit solutions and so on, so you can still try it out and also all of our automated searches and tools like basically everything is open source now. But of course a lot of the participants have also open sourced their code.
NV: Okay. So my other question is: It sounds like all this has a lot of graphics.
JvdJ: Yeah.
NV: Did you develop all this in Haskell?
JvdJ: Um, we did ... the, okay, to take small step back, I think one of the constraints we really had when we were coming up with the problem is that graphical is good. Likw it's very nice and draws people in if you can visualize problems, and obviously I was explaining the problem to you just now because it's a podcast but if I could just show an image, like it's much clearer, like it's a very very visual thing and that's intentionally what what we were going for. We, and yes, Haskell isn't traditionally a language people use for graphical things. But I think it has some good libraries like "diagrams" and "gloss" and other options as well, like you can also do a lot with just HTML and in-browser stuff. For us that didn't matter too much because maybe at work I wouldn't consider using something like gloss, because it's more of an experimental playground kind of thing, maybe not perfect to build this really big UI where you need lots of predefined widgets like dropdowns and it doesn't do all of that. But since it's just a contest and it's really more me and Alex programming things, looking at it, yeah, this is good, this is less good. So it doesn't really have to be, I mean, obviously it has to be correct, but it doesn't have to be industry ready, so to speak. So, and actually for in terms of graphics, we mostly ended up using SVGs because it's a standard format and you can parse them and they're quite easy to generate as well from Haskell and you could ...
JB: I've heard that there's a blaze-based library for generating that. Maybe you you knew about that already ...
JvdJ: Yeah, there is. I'm not, I'm actually not ... Like, I know who did it, but II'm not the author of that, actually, and we ended up making a small own library actually for the contest to deal with SVGs just because we wanted to do some sort of animations and so on. But yeah, please don't use this library, of course, we just added in the things that we need and it's a bit rough around the edges.
NV: And okay, so you put all these efforts on Haskell, you developed your own language, your own library and you have a most probably correct game definition with graphics. And who won the contest?
JvdJ: So the contest was won by RGB Team. Ah, they're a team of three programmers from Belarus, I think, and, I think one of them is quite well known in the competitive programming community. It was quite ... so one of the interesting things about the contest is that people were, rather than relying on fully automated solvers for this problem, a lot of people were building tools to solve problems instead, so they could, you know, themselves visually drag around parts of the figure and try to solve that problem that way. And then obviously the teams that did better would even improve these tools with lots of buttons and things so on, so they could run local algorithms, for example simulated annealing and so on, on parts of the figure. Or on the whole figure, of course, and so you ended up with this kind of interesting, I think it's quite interesting, because traditionally the focus has really been on programming, just like algorithms and solvers, whereas now people who could really quickly throw together a UI had a little bit of an advantage as well. So I thought that was a nice change from the usual formula. Even though we didn't expect that people would go so far with this.
NV: C++ won the context as usual, no?
JvdJ: Um, so yeah, the winners used C++ but I think the most interesting observation is that all 3 Okay yeah.
NV: ICFP contest is generated by ICFP, which is this Haskell-friendly functional programming conference, and I still don't understand why all these problems that are designed to be solved by functional programming are still better solved by C++, so is it the programmer or is it the language, and how much at the end the language can improve the solution?
JvdJ: That's a good question. So I think, first I don't think the problems are designed to be better solvable with functional languages. Um, usually there's some sort of functional programming references or components in there. But that's really just because the people who organize it traditionally are connected to that world. So at least for us it didn't really, we didn't really design something that would be more easily solved with one language rather than the other. Okay, there's a few other ... So I think it's very much the developers rather than the language, especially this is a 72 hour contest so code quality means almost nothing. You're just going to discard it after three days. Some things are helpful, I think.
NV: Is that important for the corner cases which is what most of this contest try to ...
JvdJ: Yeah, so I think in in our context there were a lot of corner cases and edge cases especially with regards to geometry. So I think, I mean obviously I'm speaking for myself, doing it in Haskell is much more enjoyable. I think in general, if you're doing this sort of contest, just using anything with a type system will give you an edge over other teams. Just because you're working on this thing for 72 hours, right? So you're super tired. You make mistakes easily. And just being able to to catch a lot of those makes a big difference. Then there's obviously been some contests in the past where just raw performance number crunching makes the difference between the best teams. And then obviously you're going to have an advantage when you're using C++. So yeah, I think this year what was quite interesting is that the three, so the top three teams both had significant parts in Rust, so maybe that's the competitive programming language of the future.
NV: In Rust. No C++ anymore.
JvdJ: No, I think the winners still used C++.
NV: As always.
JvdJ: Although I'm not sure which parts were in C++ and which ones were in Rust. So it's also very common for in these programming contests to use multiple languages. I don't really know why that is, I suspect you're just with three or four people in a team just trying to get stuff done really as quickly as possible, because a couple of hours can make the difference. So everyone. just sort of writes in the language they're best in.
JB: Right, so but it's not just that you let other people have fun by writing fun programs. You're actually letting other people have fun by playing some games and I found two of your games, one was called Beeraffe and the other one Sokyokuban, and they were both very interesting. Um, and maybe it's worth briefly just pitching the game so that the listeners will after this podcast go to your website and play these games and enjoy them. So what are these games?
JvdJ: So like many people, I think, I originally got interested in computer programming because of game programming, or like you, you're a teenager, you play video games, you're sort of creative like ah I want to try making some video games. That's also one of the reasons C++ was my first language, I think, and I think recently I got a bit back into this over the last three years or something. And one of the reasons for that I think is that the browsers are very good now. So one of the problems you were, like when I was trying to program games as a teenager or a kid is you're using C++ and it's kind of messy and then if you want to have someone try your game, you have to send them an executable and then a bunch of DLLs and it never, like it's kind of shady as well, right? So I think one of the cool things nowadays is you can just use a browser and so I think the games I make are ... An important, a big part of them is that they're browser-based because I want people to be able to just try them out right now, you can just go to a website and try it, no login, no download anything, no stuff like that. So these are both games like that. So the first thing I did in this style is Beeraffe. So I think you can find it by just googling it or maybe there'll be a link or something, but it's basically a game where you combine different things into other things. So for example, you will, so it's based on nouns. And there are many different objects in the game like a cat or a dog or like a drink and like a giraffe, things like that and you just kind of put them together to create new things. I kind of like the idea of making more alternative games, shall I say, because the, a lot of games these days are sort of, evolve around the same concepts, right? You're just shooting stuff and killing other people or you're trying you're jumping around trying to evade all the things. So I think it's quite ah, it's more interesting to kind of try to come up with new things and so Beeraffe is kind of inspired by Katamari, Which is an old video game where you sort of roll this ball around the field and there's little lots of objects around in this world as well, and you start with a really small ball and you're sort of pushing this around. So maybe you will encounter some marbles or other small objects or some candies and these kind of become part of this big ball you're rolling. And you kind of by putting on more and more stuff you sort of level up from using marbles to using chairs and then people and then even until skyscrapers and so on. So really, this sort of bizarre world. We're just putting stuff together, I think that's mostly, I wanted to sort of do a simple 2D version of that. And then um because one of the problems for me is always, even though I think I'm a bit like more, I have some creative side like if you're doing video games, part of the hard, the hard part is really coming up with the artwork and so on, right, because every video game leads needs a lot of images. Um, so I always try to find creative things to get around that. So for Beeraffe for example, you're just playing with emojis really, so rather than obviously drawing images myself I rendered a big set of emojis that had these images corresponding to lots of words and so on using a couple of filters and ImageMagick or something to make it more pixelated, and the advantage of that is obviously you don't have to come up with the words that go with the pictures because they're already emojis right? So they have a sort of a canonical word associated with them. Um, so the second game I did more recently is actually a byproduct of the ICFP contest actually. We were ... in September we were told that we had the chance to to organize the ICFP programming contest, and obviously you start playing around with a lot of different ideas like, ah, should we do something with this, should we do something with that. One of the things we were very interested in was weird geometries, non-Euclidean geometries. Um, and so we wanted to do something with hyperbolic geometry. I think we were actually quite convinced at some point that the ICFP contest would be something around this thing, and started building some prototypes together with Alex. And we found that you can play this game called Sokoban which is a very old and existing, but long, really a classic among puzzle games. You can make a version of that on the hyperbolic plane as well. And so we started putting more and more efforts into this, and then at some point they kind of became clear that it's not really a great fit for the programming contest.
JB: Because it's too simple, or ...?
JvdJ: Um, I don't think it's too simple. I think the problem is if you're working with this hyperbolic geometry, it has a really high barrier to entry, of entry to just sort of you know, put down all the sort of primitive functions and so on you're going to use. Also writing a visualizer becomes very hard. So first of all, there's this really high barrier of entry. Second ...
JB: Because it's too mathy in a way ...
JvdJ: Yeah, I think it's too mathy in a way. And secondly, then, once you sort of get past that hurdle, I think it would be in most problems you would just kind of represent the grid of tiles as a graph, you know, where you have a node and then you have neighboring nodes representing the neighbors of the tile. And that part really isn't too different whether you're doing a weird geometry or a sort of really classic 2D geometry, right? You still have the concept of a node, you have neighbors, like you can move to your neighbors and so on. So in that way like all of the algorithms are still more or less the same, so it doesn't really play to the strengths, I think, of using a hyperbolic geometry, whereas it's much more interesting for humans because it's very weird visually and it's very non-intuitive. And I think those attributes. Yeah, it's just well suited for humans and not really for computers. So we decided to, okay, this is kind of a good idea and like, it's kind of fun to play this. So let's just do this as a simple web game rather than the programming contest and then we put also quite a lot of effort into finishing that and I'm quite quite proud of that, also because you, I think, there's few ... there's some other hyperbolic geometry games, but most of them require you to install a bunch of stuff and so it doesn't really have this low barrier of entry, and this is just something you can go to in your browser and start playing immediately.
NV: So I still find it amazing that you use Haskell to develop games and to make them run in your browser. So I want to ask as somebody who doesn't know anything on how to build all this stuff in Haskell, how can i start?
JvdJ: So well, this is actually, these two games are actually written in PureScript, not in Haskell, and before that I also tried to do some games in Elm as well and I also tried Haskell in the browser. Yeah, these three are really the the ones I've tried: PureScript, Haskell, Elm. I would, I think Haskell in the browser has come a long way and it's definitely possible to program games like this, right, because they're not computationally the most expensive, like you don't have to sort of squeeze every bit of performance out of your JavaScript. But yeah for me one of the reason I like to put out these games as well as because they're very, if you just do it and if you just compile to JavaScript and a bunch of static assets, they're very easy to host as well, you don't need to keep a server running, you don't need a backend. They're easily archivable. So like if, even if I can't compile the original code anymore I can just take the JavaScript and run it, right? Browser APIs don't look like they're going to change that much in the future. So obviously I were to do a game that had a significant backend portion to it as well, Haskell is undoubtedly still for me the best language to use on the backend. And then I would probably use something like GHCJS, because then it's just so nice to be able to share code on the frontend and the backend, right? But given that this wasn't really an argument for me, I think PureScript is kind of like a very neat mini Haskell that I can use, and in fact, if you know Haskell I don't really think you you go through this learning process or anything, right? You can just sort of pick it up and start writing. There's going to be a few minor differences that are annoying at the start and you need to relearn a bit, I think especially laziness versus strictness is a big one.
NV: You support which? At which side are you?
JvdJ: Oh I'm a lazy person both in terms of my life and programming language preferences.
NV: Makes sense.
JvdJ: Yeah, composability by default is I think the way to go. But yeah, well, I ran into this a couple of times in PureScript. When for example, something would be just an infinite recursion error because the language is strict, right? And I'm used to doing lazy things. But overall I think it's, PureScript is quite nice to just do these small games. It's like Haskell but you can talk to the browser directly. That's basically it. I also tried Elm for a bit and even though I think some parts are very nice, there's like ... The problem with Elm, especially the recent releases, is they make the FFI very hard to talk to and if you're doing these sort of games, it's often very important that you have the latest browser API for some audio calls or whatever and yeah, if Elm doesn't support, it's very hard to do the, to write the FFI bindings yourself so that kind of made it a non-option for me.
JB: It's kind of worth noting that the game, like this Sokyokuban even has a two hour forty minutes playthrough by some Twitch gamer on Youtube so if people want to um, see it but they're too lazy to play themselves, they can actually sit there for two hours and watch somebody else do it. Which is impressive.
JvdJ: Yeah I think it's actually, I saw the video as well and I think it's very impressive, like the time he took to go through the puzzles. Because of, I mean doing a puzzle game is quite fun, especially if you're designing it with more than one person, because you can both kind of create puzzles, right, and send them to each other and get feedback on it. And this Twitch streamer definitely went through many of the puzzles faster than than we did.
NV: Okay, but this all is not Haskell, so let me bring you back. Maybe with a closing question. So yeah, I would like to ask what you think it's missing maybe to be able to use only Haskell to develop these fancy games and where do you see Haskell going.
JvdJ: That's a very open-ended question. So obviously I do more than programming games, I also do some open source projects, and what I need for that is very different than what I need for games. I don't feel like I need a lot from Haskell. I'm a very I think sort of individualistic person, right? In terms of, well I would say Haskell works very well for me. It has all the right parts, I think it even has a few parts that I don't need, but that doesn't really matter, because I don't have to use them, right? I think maybe there's been this sort of discord in the Haskell community recently that it has too many features. Or like too much stuff. I don't really feel that way. I think because Haskell still gives you the choice of what you want to use, right? You're not sort of forced to use all of it. So and in terms of the language I don't think it's missing a lot of features. So maybe I'm wrong, right? Because there's always features that you think aren't going to be useful, but then they are introduced and you find using them a lot. This for example was the case for me with multiway if, which is an extension that just makes the if-syntax in Haskell a little more extensible whereas you could only really do two cases before, if-else, in Haskell. This gives you a way to iterate many cases and I thought, when I first thought that I thought like, oh, this is pretty useless, because there's already, we already have guards and we already have so many ways to do if-else in Haskell, right? But I ended up using it a lot now and, so ...
NV: And this is a language extension.
JvdJ: Yeah, this is a language extension. So I would say I'm super happy with Haskell as it is. I think you need to be, um, obviously if you start using Haskell, you need to be a bit aware of which parts you want to use and which parts you don't want to use. I would just say start with what you need and then if there's all things that seem to help you, sure, go for it. But yeah, I don't really want to ask for much more. But then again language extensions pop up and they turn out to be extremely useful, even though they I didn't think they were going to be useful at the start.
JB: That's good to hear. All right, I think you said Haskell works very well for you and I think we can say that you work very well for Haskell and want to take this to thank you for all your engagement with haskell.org. I think especially this kind of background work that just keeps the ecosystem and infrastructure going and makes sure that this website and that GSOC works and even doing that for many years in a row is very essential for the success of Haskell, because we're building on it, and if that doesn't, that starts not to work, then we would have a big problem. So, yeah I think, thanks a lot for working well for Haskell at this point.
JvdJ: Yeah, thanks.
NV: Yeah, thank you very much and thank you for this podcast.
JvdJ: Thanks, and nice talking to you.