Haskell Programming

I'm Christopher Allen. And I'm Julie Moranicki and you're listening to the Changelog. Welcome back everyone. This is the Change vlog on your host, Adam Stakoviak.

This is episode 198. Got a great show on today. Talking about Haskell, the programming language. We talked to Chris Allen and Julie Warnicke about Haskell, about their book Haskell programming.

We talked about their passion for this awesome language. We talked about also Julie's path to Haskell because Julie in this case is a beginner. She was brought to Haskell and also programming from Chris. They have this mentor, mentee relationship.

They're also co authoring this book together. Really great deep dive into this language. We had four sponsors for the show today. Toptal, Linode, Oppbe and Truesight Pulse.

Our first sponsor of the show today is our friends at Toptao. Now if you're new to the show, let me tell you, we love Toptao. If you've been listening for a while now, you know that we love Toptao. Toptao is an exclusive network of top freelance software developers and designers.

Top companies every single day rely on Topta freelancers for their most mission critical projects. And one of the things we love about Toptal is this worldwide community of engineers and designers that just love to enrich the community. As a Toptal engineer or designer, you have the flexibility to travel the world, be able to blog on their blog, be able to apply for open source grants, contribute back to things you really care about. Head to toptao.com to learn more.

That's t o p t a l dot com to learn more or for a more personal introduction, email me adamsball.com@the love to help you take your first step with Toptal. And now onto the show everyone. We got an awesome show today. Jerry just want started off as many shows since this is the last couple shows, but start off with an issue.

I think the issue number was 384from Zachy. I think Manny, I'm not really sure that's exactly, but we got Chris Allen here, we got Julie Morenicki here, talking about Haskell programming, a book, a language obviously and a lot of fun for beginners. But Jared, what do you think about issues? Always spawning these, these, these great shows, hopefully for our listeners.

Well, I love it because there's no better way to know that we're specifically treating the topics our audience is interested in. And we had Haskell brought up a couple of times as requests and just had never had an opportunity to discuss the language specifically and this particular issue wasn't open too long. It was like January 31st, but there was like three or four immediate thumbs ups and testimonies. That learning Haskell was a lot easier with this particular book.

And so, yeah, it was a good opportunity to have Julie and Chris come on and talk to us about it, I guess with that. Chris, Julie, welcome to the show. Thank you. Happy to be here.

Thanks. So maybe for it's a little easier because you got a man and a woman, but for separation of voices, let's get a couple introductions out of the way. Chris, maybe give us a brief introduction of who you are and Julie will follow up with you. So I'm Chris Allen and I'm a working programmer that has worked mostly in small medium sized businesses and startups.

I'm just a working programmer. And what about you? Well, my name is Julie Mornicki and I am not a working programmer. Or at least I wasn't before NetChris and I was a teacher and a linguist and so programming is all pretty new to me in the world of programmers.

Maybe the best part would be to just kind of pry about a bit more of your backgrounds and just quoting you, Julie, in your about section for the book. And so just kind of to overarch the long conversation we'll have for today for listeners or the comic has obviously also this book they've written together with Haskell programming and just in general the path to becoming a programmer, going from a beginner, going from the background you've had to, you know, being a, being a programmer. Right. And this, this path you've taken.

But this book, as you said, I'm quoting you, this book developed out of the mentor, mentee relationship that you and Chris have out of your dialogues, out of your friendship and your commitment to sharing all the things you've learned in this path and you and Chris together with as many people as possible. So I think it's kind of interesting to sort of like paint the picture of your perspectives. It sounds like you got this. I just put it in parentheses here for us behind the scenes.

But I put Julie the beginner and I put Chris professional because you both say those things in your about section four for the book. Maybe we can kick off with just some backgrounds a little deeper kind of where each of you kind of maybe. And maybe Julie, you're a little sooner rather than Chris, but where you each picked up program. What got you into developer?

Okay, I'll start because mine is the most recent development. I just, I was never really interested in Programming at all. I mean, when I was in linguistics graduate school, there was. This was back in the late 90s, and there was starting to be some interest in, like, computational linguistics.

Well, not starting, but at our school there was starting to be a lot interest in computational linguistics, and people tried to get me interested in programming. I was just always really resistant to it. I'm not sure why exactly. But then in a couple Years ago, in 2014, I met Chris on Twitter and Chris was really excited about the fact that I have a background in linguistics and tried to.

Well, did not try. He did persuade me to learn Haskell because he wanted me to become interested with him in natural language processing. So I was still pretty resistant for quite some time. But then Haskell itself just started to become interesting to me as a language.

And then as you start to. Actually, for me anyways, I started to get some familiarity with Haskell, and then it started to become exciting. Like, it started exciting for. For me to be able to do all kinds of things.

Like, I just started my blog with Hackl now, and so I had to learn about how to get things on a server and stuff like that. It was all really exciting for me. I know that sounds sort of. Sort of.

Oh, Hackl is a. Hackl is a. It's a static site generator. It's.

The name is actually a riff off of Jekyll. So that makes sense. Yeah. So it's a site generator written in Haskell.

And so it's. Anyway, I just started using it on my blog, so I had to learn a serv and stuff like that. Being able to do those things now is really exciting for me. But really, five years ago, if you asked me if I was ever interested in, you know, learning about servers, I would have said absolutely not.

So I have to be honest with you. I talk to people that they learned that I do this show and Jared and I do what we do around software development. And these are people who have never touched it. Educated people, teachers, you know, you know, smart people.

But, you know, they look at me and say, what's the server? What's the server doing? I just. I fumbled with you even trying to tell them exactly what server does.

Like it's server serves. I feel like the guy in Pink Panther, you know, you're the trainer who trains like trainers train and a server serve. But I'm with you on the whole deploying tool server seems like this black box. It does.

And you know, like Chris, last week, last weekend, he was helping me get this started, and, you know, he said, okay, so we're going to, you know, set up your server now. And so that was fine. So I have this account with AWS now, so big time. Right.

And then he was talking about nginx. NGINX is your server. And I was like, wait a second, I thought this other thing was the server. He's like, oh, well, so there's two things called server.

Right. And so he was explaining to me how all of this works and it actually is really interesting. I don't know why, I don't know. I've always been kind of more like, I really like to be outside and more of an outdoors kind of person.

And so I think I just had this resistance to spending a lot of time sitting in front of a computer. But there's a lot of fun stuff you can do and so I'm glad I got into it. All right, let's turn to Chris then. Chris, for your background, you mentioned that you've been professional programming for a while.

Kind of give us a take us as far back as you have to go to help us understand where it came from for you. Like when did you get interested in technology and software development and programming? What was a few of the guys in there? Well, I mean, technology is super early.

Mike, I don't know if you remember, but do you remember those arcade style joysticks for the nes? Yeah. Oh yeah. Those are a lot easier for a three year old to use.

That's how my dad got me started on the Nintendo. So technology started, then programming started. Later I basically ran out of games to play on the DOS computer my dad had set me up with. And I was complaining about having run out of games to play.

So he handed me a floppy and this really thick AT and T manual for GW BASIC and told me to make my own games. And eventually I did figure it out. But the problem is playing your own text management game is kind of boring because you already know all the puzzle answers. So that was kind of a problem.

Yeah. Play somebody else's game. Yeah, yeah, exactly. If only, you know, I had a modem, maybe I could have found a game.

But that's where that started. I didn't really get serious about programming until I started having more success with it. I spent a lot of time kind of fumbling with C and Linux was in middle school and I'd learned a lot about Linux to get too far with C. And where I really started kind of being able to do things was actually with Common Lisp.

And eventually that translated after high school into me Wanting to work as a programmer because I couldn't really imagine enjoying myself doing anything else. I wonder like for me, because I never enjoyed playing video games. I wonder if that's part of why I was resistant to life learning how to program. Think about that.

Because we ask a lot of people about how they got into programming to come on the show and a surprising amount it starts with video games. I was gonna say that it's like some sort of game got them in there, some sort of hackability to it that made them push the boundaries. And I noted in your about Tony that you actually said you were never really into games. No, I don't.

I don't play video games at all. And I mean I don't have anything against them. I don't want people to think I'm like judging them for playing video games because that's what people always think and I don't. It's not that they just don't interest me.

I mean I've played a couple that were fine, but it's not something I would ever like think, sit down and think, okay, have some free time. Like such a real one, play this game. This just never really happened to me. I don't know why but like for my son, you know, teaching my son Haskel now, and that was his, that's why he got interested in programming was because of Minecraft and he wanted to learn how to make Minecraft mods.

And so that's where I started for him too. So. So after I got out of high school, start working as a programmer. My first job was actually using C.

NET to recover old database file formats from mainframes and get them ported over to pretty standard Lightbox setup. Eventually I ended up in New York and started using Python and Django to make a content management system. Because we're going to work on that sort of thing, right? And my interest in open source though began when I was much younger because almost everything I used in Commonwealth was open source.

The community was by and large on IRC and mailing lists. And I couldn't have become a programmer without these hundreds and thousands of people ready to help me and write all the stuff I could use for free. What was the moment where you found joy? Tell us about the first joyous moment where you're like, this is my thing, I'm going to do this, I know how to do it.

And you got some level of confidence. I think the first thing for me was I wrote a very dumb text based file format for storing data from one of my Commas programs because I didn't understand how use databases or anything yet. And the first time I had a program that could persist its data without relying on commless image formatting and was in a format that I could read and modify with the text editor if I wanted. That was when I started really enjoying myself because then I felt like I could actually write programs that did, you know, whatever I wanted or previously they'd all been in memory.

How about Haskell specifically? You say that you've been programming for 15 years or over 15 years, and you became interested in Haskell about six years ago. What brought you to Haskell and then as a follow up to that in 2014 when you started talking with Julie on Twitter, what made you want to to pique her interest to teach her what you have about Haskell? Well, to start with the language, that was kind of a win win process.

So Python was kind of like, okay, I'd rather use a common list. I understand this more popular and it captures most. I'm sure an actual, you know, some of these common lists would crucify me for this. But it captures most of the benefits that most people care about in terms of, you know, being able to do runtime metadata programming and having a functional ish kind of base.

But I eventually moved on to closure because I needed something with more mature runtime that had threading, that sort of thing. And being able to go back to the list was just kind of a plus. Right? That was nice as nice to have macros and stuff again.

But I got these problems, problems that because I had used a bit of ocaml and a bit of hassle just a teensy tiny bit before, I knew that these problems weren't really necessary. These problems need to happen, right? I knew that, you know, everything that not everything, but the vast majority of errors on top of your runtime really could just be type errors. And it started really kind of eating at me.

And after one particular incident where I was at kind of a closure meet up, like, let's hack on, you know, everybody breaks some of these teams and hacks on problems together, I ended up having a runtime error that would have been prevented and hassle and variously found. But in closure, the vectors are actually functions. You can just use like a piece of data as if it was a function to apply to an argument. And when you do that using like an index.

And the problem is, is that the. Are you guys familiar with the concept of like a source to sync distance? Not me. Okay, so if you're Working like stack analysis or on like something kind of like co climate or one of those kind of static analysis linkers, type ers kind of things.

You're trying to keep your source of sync distance as small as possible. What that is source is what caused the problem. Sync is where the static analyzer says there's a problem, right? And obviously you want to just kind of pin it on the nose.

The problem is that people think that, you know, runtime areas can help trim that distance, but in many cases can actually make it much worse. In this case, that's what happened. And it basically led to a situation where multiple people that use Clojure professionally, myself included, spent four hours tracking down a runtime error and 200 lines of code. And I knew that was just nuts.

I mean, it's not like I hadn't debunked it. I put print lines all over the entire program and it was still a massive pain. And I realized that if I'd been using, you know, Hassel or OCaml, it would have just pinned it right where I made the original mistake, not the thing, you know, 50 lines down. So the problem is, I realized I knew I still wanted a functional language, not just types, right?

Because I did like other things about closure, like having, you know, softer transactional memory and other things like that. So that narrowed down to, okay, well, Haskell. And then, you know, concurrency and laziness, a few other things kind of decided for Haskell for me. Then from there, I realized that although Haskell was really nice, I wasn't going to be able to use it at work unless I could get other people going with Haskell.

Right? So I realized I had to take responsibility for increasing the size of QD more generally. But also specifically, I needed a path or a means of like saying the three coworkers, okay, do this, this, this and this, and then we'll start pair programming to get it going. Right?

So that's what led to the guide that I wrote is LightMyF learn Haskell on GitHub. It has over 3,000 stars. Now, that guide was basically a recommended order of free resources to get along with Haskell as quickly as possible. And it was that desire to be able to tell my manager with a straight face that, yes, I can get people going with it.

And that's also when I realized I just had to get better at teaching in order for that not to be a super messy and painful process. That all kind of culminated in me deciding, okay, I just need to write a book, because I couldn't figure out how to fit the layo pieces of existing resources together in a way that would really satisfy me. Around the time I decided I was gonna write a book. A few months prior to that, Julie and I had become friends via Twitter for reasons, you know, to learn later programming.

Yeah, just some shared interest. Yeah, we were talking. It was actually we first met in the thread about history, some kind of historical topic that we're both engaged with. I don't remember exactly what it was, but that had nothing to do with programming.

Sounds right. Yeah. And you know, I. I have had an abiding interest in natural language processing for a while now, and when I found out she was a linguist, the idea of getting her going with Hassel was kind of exciting because there is some good kit in Hassell for nlp, but it's not as mature as, you know, like say, the Stanford NLP stuff for jobs and all that.

Right. So I thought maybe that could be fun to learn NLP side beside the linguist. And since I already had this book that I was gonna work on, it'd be kind of nice to have a beginner vet the material as I'm writing. Of course, she, you know, upgraded from, you know, something vetting material to a co author.

Yes, yes, I did. Very cool. I think that's a good stage. We're taking a quick break here.

We want to talk more about Haskell. We found out why Chris likes it. Julie, we're going to ask you specifically how you came to love Haskell, which I think has something to do with your linguistics background. This has more questions about the programming language itself, but I think this is a really nice setup for this.

For this book, which people are finding quite useful is the idea of let's write a book, not just a professional talking as if some sort of hypothetical beginners out there. Let's actually have a beginner alongside helping write the book. I don't have a unique paper, to say the least, so we'll pause here, click break and we'll be right back. Our friends at Linode offer a pretty cool service I want to tell you about today.

It's called Professional Services. This is something where you can hire them to take care of semigrations, one off system admin tasks, server installs, or anything else you can think of. They offer this as an add on to the customers and I talked to Dave Messina, the product manager of Professional Services, and I asked him what it's all about and why their customers love it. Professional Services is geared towards existing and prospective customers that are looking for a system administrator to take on, maybe a test that they don't have resources available to execute on or just don't have the time to get in there, you know, into the command prompts, diagnose, troubleshoot, configure their Lino to meet the needs of their application.

So our team here is diverse and, you know, we specialize in, you know, multiple errors. We've been, you know, hosting industry for many years now. We specialize in Linux, so that's our forte. So we have, we have excellent people here that are skilled and experienced in multipliers of Linux.

So they can typically execute these projects or solutions efficiently for these customers that need our assistance. Now we know more about Lino's professional services. Tell us we're getting started. What's that process like?

This being an perspective, customers can visit linode.com, click on Add Ons Professional Services and there's going to be a Get a quote button there. That's a scoping form where they can fill out the technologies that they'd like to use and any notes that they'd like to provide us regarding their application or their goals. Once that happens, we'll follow up and speak to them further on solidifying the solution. And everything looks good when we get to work.

And so once a customer decides to move forward, what happens next? Are they assigned a person who works with them to take care of their needs and kind of walks with them through the process? Take us through the process. What happens next?

We have implementation specialists here that get assigned their project and they'll see it from A to Z. So that is, you know, working on, if it's a new deployment, working on building out the stack and then potentially migrating your data over and maybe going through a validation process with you to determine, make sure that everything looks good in terms of, you know, the data that's been moved over and how your website functions on the new Linode. And then if you sign off on that, then we move forward to go live where, you know, it's in the project and we're handling it. We'll do the DNS cut over as well.

All right, that was Dave Messina, product manager for Linode's professional services. As you can see, if you got a need, Linode's got your back. Head to linode.comproservices once again, linode.comproservices to learn more and tell them the changelog sent you. Okay, we are back with Chris and Julie and we are talking about Haskell.

We found out what brought Chris to Haskell. And we know that Chris brought Julie to Haskell in many ways. But you came to love it, Julie. And one thing that you say is that you came to love Haskell for its own sake, in part because of connections I see between it and the logic of generative syntax.

One of the things we say here on the changelog is we face our imposter syndrome, so you don't have to. And I have to say, when I read a lot of the generative syntax, I feel like the beginner. I don't even know what that means. So I think the linguistics thing, I'm not sure.

Can you help me out unpack that sentence and elaborate for us? Yeah, it is a linguistics thing. That's what I was. I worked on syntax, mostly syntax, in graduate school, particularly.

I was working on the argument structure of verbs and. Talk about that in a second. And so with Haskell, the connection is generative syntax. What you're trying to do is find the rules that can produce all the legal or grammatical sentences for language and not produce or allow any illegal or ungrammatical sentences.

Right. So a lot of linguists, not all because Chomsky's a little bit controversial sometimes, but a lot of lux, think that we have these kind of internalized rules of syntax that can. That we use to produce grammatical sentences. And that's why we can produce grammatical sentences like colorless green ideas.

Sleep furiously. That's why we can produce grammatical sentences that don't actually have any meaning. Leaving aside the controversy of that statement, that's the idea behind generous syntax. That's kind of what I was working on in graduate school.

So not too long, I guess it was a few months after Chris started trying to teach me how school. I was listening to a talk, I think it was from Strangeloop. And I think it was Paul Snively and Amanda. I'm not sure how to pronounce her last name.

Locker, Lasher Locker, something like that. And I believe it was in one of their talks, they said something like, the goal of a type system is to allow any legal functions or expressions, but not allow any illegal ones. And that's the same thing as what generative syntax is trying to do. So I started sort of thinking of types and type classes in Haskell as they relate to grammatical categories that I had been studying in linguistics.

And that's when I sort of started to love it. Like, to me, that was really interesting, those connections. And a friend of mine that I also know from Twitter, he's a Greek, hassler named George. Hi, George.

He one day when I was first starting, he also told me like if you think of, if you think of it a function like a sentence, so the function is a verb. And then the arguments that it takes in a language would be the subject and object in any prepositional phrases, for example, that it takes arguments. But in Haskell it's not taking subjects and objects as arguments, it's taking these typed data as arguments. Right.

And so those kinds of connections are what made me sort of fall in love with Haskell. And that's why I'm not really sure that even though I'm developing now a more general interest in programming, I'm not sure if I'd come to programming through any other language like it would have kind of hooked me as much as Haskell didn't. So the type system is obviously a big piece of how Haskell works and something that people either love or hate. You know, dynamic statics.

Wrong. Loose typing is one of those age old flame wars, you know, from arguing about Vim versus Emacs. It's dynamic versus static type systems. Yes.

And so here's the reason to love this type system with regard to Haskell is because of this connection that you see through it to this generative syntax idea of Chris, could you help us with the type system, explain exactly what that means. It's strongly static type, how that works and you have the real world programmer experience of like this makes me productive in ways that I wasn't without a strong type system like the error checking. Can you kind of just give the maybe the 30,000 foot blimp view of Haskell type system why it's so interesting. Haskell's type system is nice, but it is kind of instrumental thing for me.

I like it because it's relatively small and easy to understand compared to languages are trying to blend multiple paradigms. Part of the appeal of say something like Python is that, you know, there's pretty common patterns of way people do things. People aren't really trying to be overly clever where it's not merited. It's.

You don't have to guess as much with the semantics of the line code in Python as compared to say, you know, Ruby or Perl. No fast users of this language, tons of ridges of Perl users in the Haskell community, but I don't think a lot of people would that. So in Haskell the nice thing about type systems is it's actually very compact. The semantics of language are pretty alien to people, but the type system itself isn't that big.

There's not a lot of rules to it. For example, it doesn't have subtyping. It ends up that you don't actually need subtyping if you just kind of piece it apart into orthogonal components, different things you might want to use. Type classes are one of those things.

And one advantage of that, it just makes the results more predictable. You don't have to guess how a piece of code what its typical being inferred as. So for me, as a working programmer, Haskell typesystems in kind of the sweet spot where I don't really have to do any more work than I would otherwise do to make the typetype happy, because it really only disallows stuff that I would never want to do anyway. I know a lot of people who have a lot of stringent subsetists don't believe me on that point, but it legitimately is the case, at least for me.

It does take some time to remould your brain to think in those terms, but it does happen. So from there, the basic idea of the type system in Haskell is that you have these types that enumerate possible valid kind of. We call it inhabitants. We're really talking like, okay, this is a valid value and inhabits this type, right?

So Google is a type in Haskell. It's not just an alias for an integer like it is in like C, that kind of thing. It just has two values or two data constructors that are called Haskell. But there's two kind of nullary values and there's true and false.

So that has two things that are valuable and then that's it. So unlike a lot of languages, there are no implicit nulls in Haskell. So there's not, you know, true, false and null are available. We don't have that.

It's just true and false. So that's the basics of it. And if you want to write a function that takes a bool input, then you're going to match on true or false, or you're just going to pass it on down the line to a different function. Then from there it expands into type classes, which give you a way to.

I don't think I would call it abstraction, I think I would call it generalization. But basically type classes give you ad hoc polymorphism. The best analogy to draw would be kind of like Java's interfaces, but considerably more powerful. But basically you're generalizing an interface that a bunch of types may be able to satisfy and have in common.

In fact, one of the Things I like about Haskell's type class is that they lend themselves pretty well to efficient code generation. So as a result, we're able to have polymorphic numerics in Haskell by default without it actually necessarily costing us at runtime, which is kind of nice. So you don't have a separate like plus and then plus dot for ints and floats, that sort of thing. It also means you can extend other types to implement the non type class if you so desire.

But there are some constraints. Like you don't really want to use type classes willy nilly. You want to make certain they satisfy some laws or constraints that are designed to describe what behavior makes a type class predictable. Or it's basically how you encode a principle of least surprise on a per type class basis.

Then from there, contrary to popular belief, that Haskell type system has some escape hatches. For example, you can put an error value in the definition of a function if you want to say it has a type, that you want to implement it right now. And this actually turned out to be a really powerful technique because it means that I can work in terms of types alone without having actually written the code or implemented any of the functions and then test combining the functions together without executing them. Just asking my reps, my read about print loop, what type would it be if I composed, you know, functions F, G and H?

Given that I've only defined their types, I haven't actually implemented them, evaluating them would actually produce a runtime error. Tell me what happened and then I can figure out if I'm actually figuring out the right design or combination functions that achieves I want before I've really done any real work, I just wanted to say here about this one he's talking about right now. This is something I didn't really believe him. He told me that you could do this, and I didn't really believe him for a long time.

But we've actually demonstrated how to do this to a certain extent in the book and it's really, really helpful. I mean, it does work and it's a really powerful way to figure out what you're doing with your program. And basically the idea is that the types are this kind of way to step away from the specifics so you can make certain you're even thinking the right thoughts before you do all the workouts. So just as a, as a way of getting a little more background about Haskell itself, you know, a lot of most languages come out of a specific need or specific design constraints.

You know, the most Obvious one that comes in mind for me is Perl, which was created, you know, as an extracting. What the acronym is. It's for text extraction. And what's Perl's acronym coming out here?

No help Googling. I'm actually sure it's text process. Yeah, text extraction report language. The whole purpose was for manipulating and performing reports on text.

And so it's designed like that. Where did Haskell come from? What. What problems was it set to solve?

And why is it designed such a way that you just described it, Chris? And then as a follow up of that, therefore, what kind of problems is it particularly good at solving? Well, it came out of they wanted to see if they could make a programming language that was a pure lambda calculus, right? Kind of, yeah.

So they took for granted that they wanted a language that was going to be only a lambda calculus. But the motivation was that prior to Haskell, there were a bunch of different research languages running around the 1980s. Haskell descends from the ML family languages. ML started in 1973, and it was kind of descended from Landon's icewind from the 1960s.

But basically we had the foundations of a language like Haskell back in the 1970s. But those languages were strictly evaluated. And what that means is what you already take for granted in all the languages you currently use, when you pass arguments to a function in a strict language, they've already been valued. They're valued immediately whenever you bind them.

The research that was going on in the 1980s was to figure out a lazy functional program language. And Haskell was this collection point of, okay, we've got all these different implementations and designs running around. Let's try to combine forces and come up with one good implementation of a lazy functional program language. And what laziness means here is that your code doesn't get executed or evaluated until it's actually needed, rather than when it's kind of bound to a variable.

This is actually something the recent release of our book Deep dives into. But part of the motivation for this is that it means that you can write this nice, clean, maybe an experience permanent, even, say, naive code. But because you're not doing any of the work immediately upon binding, it leaves a situation where you can have code that looks nice and looks naive, but actually optimizes to what you would actually want to execute at. So the example is, when you map, say, a function F, G, and H over list, the non naive way to do it is compose all the functions that you're going to map over that list all at Once.

So you do only one map over the list, right? Because if you're using JavaScript or Ruby or Python or whatever, I mean they all have a map, right? And the problem is if you keep going map F, map G, map H map I, map J, you've now done like five loops over your list and constructed like five lists, right? One Haskell.

That's not what happens. It actually fuses them together. But the only reason it can do that is because of both the lazy or if you will, non strict semantics that don't obligate it to do all the work upfront all at once immediately. But also because of the it knows where effects can happen, so it knows when it can move certain bits of code around.

It means it's actually free to reorder your code because it knows where that is and is not allowable. The purity fell out of non strictness. Actually the non strictness means you can't actually really have an impure or to explain impurity. It means you can't have a language that has an imperative kind of sub language like OTAML does.

It means you can't have effects be implicit when you perform effects, whether that be talking over network socket or printing or whatever. It shows up in your types of explicitly in Haskell. Unlike most languages, I've actually used an impure language that was also non strict. It was a scheme dialect.

And let me tell you, getting to do things in the right order as you intended was a nightmare. And I think to lay up that particular scheme of mutations with cruel jokes and crad students. But. But the point is that basically laziness forced purity.

But then later on people realized that purity was really quite valuable in its own right. Purity and sense to be a pure lambda calculus. People really hung up on that word think it's like a moral judgment on other languages and it's just. It just means that it's just a lambda calculus.

So I was gonna. That's all up to that was kind of where we see Haskell getting used out there in the wild. It has crossed my radar a few times on in terms of web type things. Of course every language that's still actively used and maintained has web type of things.

But what are some other people might know about Haskell projects, maybe open source that you guys are aware of of where Haskell's being used to solve cool problems, to compare tests of other languages. It gets used in roughly the same domains as languages ranging from Java, Go, Scala to all the way out to say Python, Perl, Ruby, Prologue. So that kind of spans basically pretty much anything. Use garbage collected language for.

It leans more on the side of, you know, say, like go ocaml, javascala. Because it is threaded, it is compiled. So you're seeing network services, plain old web apps. There's actually multiple ways to compile Haskell JS now, so you can use it for a front web app if that's your cup of tea.

There's a Haskell like not exactly the same thing, but a Haskell like compile JS language called PureScript that has a pretty vibrant community and a very good person behind it. Phil Freeman. He's amazing. Super nice guy.

I've seen hascript recently compared to elm, is that right? Yeah, so I mean they kind of exist on some continuum, but peerscript a lot closer to Haskell. It's not identical and you still lose some stuff going to peerscript from Haskell, especially if you're using any of the advanced features. But they're.

But I mean, for example, like peerscript has type classes, ELM doesn't. And ELM is kind of stripping the shit there in an attempt to attract more people who haven't necessarily used a functional language or a typed functional language before. Gotcha. Peerscript kind of inhabit a.

It's kind of a Haskell that's been redesigned with the needs of front end DOM manipulation in mind. Somebody just requested a show on PureScript in ping this last week. Just while you're talking. Chris is a proxy for success.

I've searched the most starred GitHub repos with the Haskell language. Number one is Postgres, which is a REST API for any Postgres database, which seems pretty cool. Also, ELMS compiler written Haskell, as you mentioned, PureScript is a top five. So just to give people a taste of what people are out there doing with Haskell, I think that's good.

Let's. Let's change pace a little bit and talk about learning. You guys recently gave a speech at Lambda Conf called How to Learn Haskell in Less than five Years, which seems like a long time, but can you share more? And why does it take five years to learn?

Aside from the red ammonia concept, which we've all but skirted so far in this show, what makes Haskell so hard to go? Well, at least as a working programmer, part of the reason that it took me five years is because I'm very impatient and if I don't get traction with something in what seems like a reasonable span of time, then I kind of, you know, like an unbalanced flywheel kind of spin out and give up. And I went through that process, I think probably, I don't know, once or twice a year for those five years. So this is five years of steady learning.

This is five years. Okay, I'm gonna try to pick this up again. Nope, still can't write about that. Okay, I'm out.

You weren't actually trying for five years. It was sort of over a span of five years. Yeah, it wasn't consistent effort, but. But each false start was, you know, at least a week or two.

Right. And like kind of alternating with that. I'd also play with OGAML because it was kind of scratching some of the same itches. Right.

And I realized the problem was that the foundational kind of like the actual way the language thinks, so to speak, is just totally different. And it's actually faster if you just roll back and just tell yourself, you know what, I don't have a program. Why don't you tell me how Haskell. And it turns out doing that is much faster.

I can get somebody going with hassle weeks easily, especially if I have some paper programming time with them. If I toss them or book and pair programming with them, I'm getting them going. Two weeks hacking on web app and Haskell. It doesn't have to be hard, it's just that the existing resources were a bit rough.

And Hashlers don't have the same language or, sorry, the same community around documentation and education that some other communities have. Like, I mean, you can use if you're in Python, Ruby, js, you can use just how well designed the landing page for library is to gauge how much the maintainer cares about how much effort they're putting in. Right. Those cues, those social cues, they don't exist in Haskell.

The best library for something is going to have the same package or any landing page that everything else has. So that's another problem is that it usually gets trapped by these, like, abandonware libraries. And since nobody really makes an effort to, you know, put on their best face for their library, you don't really have to wait to discriminate. That sort of tees up the learning path for us.

Chris, I know it's taking you five years to fall, start your way into Haskell and still be a professional at the same time, Delete seems like you've had a much faster path. So let's take a break and we come back in this break, we'll kind of dive a little bit more into the learning process and maybe delete and Share how you got there so quickly versus Chris's five years of fall starts. We'll break here and right back. I'm here with Thomas Watson of Oppy and as listeners of the show, you know the wheel to turn things on their heads.

And that's no different than sponsorships. And one thing we're doing is we're going deeper into the organizations we work with. Oppie is doing some really interesting things around application performance monitoring, specifically around the js. And Thomas has an interesting story on how he got started with Oppie and also starting off their nose.

So, Thomas, say hello. Hey. Hello everybody. Thomas, you got an interesting story here with how you came to be at it seems like the node support is kind of thanks to you.

So what's the backstory on that? Yeah, so I've been doing Node JS for almost 5 years and I found out they were doing occasional performance launching and I wanted to have that for my stuff that I was doing. And they didn't have node support. So I basically approached them and said, hey, can I do an unofficial Node JS implementation?

And they were like, yeah, sure, sure, we'd love that. And I did that. And then slowly we started to work more and more together. And all of a sudden I find myself being employed now at the upbeat being there the Node JS lead and I'm now responsible for this agent that I started diagnosing the data as a open source project and I was responsible for that opiate and that's the one you install on your production service to monitor you the health and performance of your application.

So that module is opbeat Node. And so things began with that open source repo. I was happy to be interviewing with this. Yeah, I started under my own GitHub account and just did it for myself in my own projects.

And people started using it and the opbeat guys were really happy with it. And then when we decided to join forces, we moved it to opby. Org on GitHub. So now it's besides on GitHub.com, that's really interesting to see, like, because we'll get into this here in a second, but you have this passion for open source, but how you know, your own personal drive and desire for something on a particular language platform like Node and then a service like API to get that application performance wandering into your own apps.

You're like, hey, you don't have it, but I can write this. And. And now you actually work there. You're building it out.

Yeah, that's a beautiful open Source it connects with a lot of people and you can pick it to do what you want for yourself. And then if people like it, you see web texture. In this case, it's this really awesome place. I'm doing this really awesome stuff with Node that's really down in the machine room, so to speak, which is really, really interesting to do.

And right now we actually are just going out of beta soon. You can go to opbe.com node JS Sign up for beta if you want to try out the stuff. So the upbeat Node module, can you talk a bit about what it does? So it basically sits on your server inside your Node JS app, required at the top of your main program and it just monitors the whole health of your application on a request basis.

So incoming HTTP requests to your Node server because what flow was performing badly? What. What should you take a look at to optimize? Maybe it's the database thing, maybe it's the reddish cache or something else.

And it also bunches errors happening in production. So we will break down the error, figure out who made that code, when was it committed to give, when was it pushed to production. So we can all assign errors as well to the developers who actually is responsible for the code that's breaking. So obviously your passion for open source and your passion for giving back got you to doing some of the stuff about Bead and what we just described there with your notes support and whatnot.

Can you talk a bit about your work at noteschool, the open source you've written? Just some of your passions around open source and how you think about open source. Yeah, I really love open source. I've been an open source software user for over 20 years.

So when I joined the NodeJS community 5 years ago and finding something to speak open source spirit in the community was really exciting. So I've now come from an open source user to open source developers. I love to teach, that's one of my passions. And especially folks love teach programming.

So there's something called a noteschool where I try to help out as much as I can to teach other people Node JS and you get to do that not only on the web, kind of remotely, so to speak, you also get to do it face to face. Yeah, you can go into nodeschool IO and you can take some courses online, but you can also join some of the regional chapters in community. There will be Node school events where we will have tutors who can help you out with your questions and you can actually do some of these online Courses, you can do them in person, in real life with people who know Node really well. And I try to do as much as I can organize one Jin code.

Well. Cool. If you want to follow with Thomas, you can check him [email protected] Watson that's last name W A T S O N if you want to sign up for The Outbeat Node JS bet you can do so outbeat.com Node J S and I'll back the show. All right, we're back from the break.

And so before the break we got kind of a tease of this learning process. So, Chris, get to hear your 5 year false starts and the deeper story behind that for you and Jill. You come from a background of linguistics and philosophy and you were roped into this, this gig, so to speak, from, from Chris's. Yes, his perspective towards programming.

And I'm sure you're happy about it now, but help us understand the path for that, like the process to learn. Like, what were some of the hurdles you'd faced? Help us understand your path. Learning Haskell.

Well, I mean, everybody says, I see it said a lot that it's easier to learn Haskell if you don't know any other programming languages than if you're trying to come from a different language and then start learning Haskell. Because people who already know some other languages have to kind of clear out what they already know about programming because Haskell does things so differently. And I think there's some truth to that. I mean, you do have to.

From what little I know about the programming languages now I can see why people say that. I mean, you definitely have to think differently about your programming to do it in Haskell than in a lot of other languages. So I didn't obviously have that problem because I didn't know any other programming languages. So in that sense it was easier.

But for me, the big hurdles have been, well, two big things. The first one is that very, very few people learn Haskell as a first language. I mean, that's fairly uncommon as far as I can tell. And so the Haskell learning materials, almost all of them assume that you've already got some programming experience.

So they don't explain a lot of really fundamental concepts. And they often explain things in terms of like real world, Haskell the book. Not to, you know, disrespect it or anything like that, but they explain a lot of things in terms of C, which I don't know. And so things like that were really hard.

And a lot of the books explain recursion in terms of, like, looping and imperative languages. And that was really hard for me to understand because I'd never looped anything in a narrative language. So that was one of the hurdles. The other hurdle for me was that a lot of the knowledge that programmers accumulate over a period of years, doing it as a hobby before they even become professionals, things like how to use Git and how to use, like, a lot of the command line stuff, those kinds of things I had to learn kind of all at the same time that I was starting to learn how to.

So the first few months of Haskel were just like, really rough because rather than learning the programming language, you're actually learning the things to learn a programming language. Exactly. I was learning the, you know, this kind of background knowledge that programmers really take for granted. And I mean, they didn't always, of course, they just learned it so long ago for many of them that they've kind of forgotten that, like, these things are not obvious.

Right. So those were the two biggest hurdles for me. Haskell itself, I don't think, for me it hasn't been. I mean, there are difficult things about it for sure, but I really think that a lot of it comes down to how it's taught.

So one of the things is, like, not explaining things in terms of other languages. I don't think that's actually very helpful because Haskell is just so different. But a lot of the. Well, I mean, everybody starts, like you mentioned monads a few minutes ago, and like, kind of everybody or a lot of people, when they're coming from other programming languages, they think, oh, if I'm learning Hasselho, I have to learn about monads.

So they try to start there, and it's really not a good place to start. And then they're just kind of. They don't really understand the monad, and so then they just are like, oh, Haskell's gonna be too hard. And.

Yeah, on that note, then what's the. What's the best place to start, in your opinion? Since you came from scratch, so to speak, and even learned what it took to learn according to language, what's, in your opinion, was the best place to start? What got you?

One thing I would say about this is that the. When we started writing the book, we had to figure out how to break the language down into kind of an order, sensible order of how to learn things. And if you start really critically analyzing it, you realize that, okay, to understand monad, which is just a type class, you know, it's just a generalization of a pattern. Basically, you realize you need to learn certain things about type classes, certain kinds of type classes.

And then you realize in order to understand type classes, you gotta learn, you know, how types and hassle work. Just normal, concrete types, not just type classes specifically. Right. And if you follow this kind of regression, you'll just land at, okay, what's an expression?

Right. And that's more or less where we started in the book. And we did end up adding a lambda tag to this chapter later on, before expressions in Haskell, but that was the result of having tested the book with learners, and it was us addressing a problem that we observed empirically. Yeah.

All right, so you've been talking about the land of calculus and the various things you talked about in the books. Let's just break that open. There's a process behind this book. You got tons of chapters, a lot of different topics.

What's the process behind this book? How did you actually start the process of writing the book? What's behind this book? What's behind this book?

Well, when he first decided he wanted to write the book, as he mentioned, he wanted to write this book so that he could hopefully, in his work, get people going with Haskell faster. Right. So the first chapter he sent me, actually, that material has now been split across a few different chapters, but it was already talking about algebraic data types, which is. It's in the first half of our book, as it currently is.

But the way then I responded to the algebraic data types material that he sent me was with a lot of questions like, wait, okay, I still don't understand this thing, and I don't understand this thing, and I don't understand this thing. And as I told him all the things that I didn't understand, then he started getting a better idea of how to break down the things that come before algebraic data types and some of the other topics. In fact, we like. We have this section of the book that goes from basic data types to types to type classes.

And originally we didn't have a type classes chapter scheduled. Or I think the types and type classes chapter were both sort of condensed into one originally. But there were so many things that. Well, really, because I'm the beginner, there were so many things that I kept saying, I don't understand this, I don't understand this.

That became two separate chapters. One of the reasons they got split apart is that one of the things that we try to do, kind of like what you said about the changelog itself, is we try to be honest about how we arrived at an understanding of something. And so in the book we include type errors, explanations of the type errors. We try to anticipate what kind of things they're going to trip over in the course of following along with code and exercises in the book.

So a lot of the splitting that happened, types and type classes is, oh, Julie and I tripped over this weird error or whatever in the process doing this. So we don't want to just address that possibility, we don't want to explain it properly, we don't want to just skip over it. So the kind of content inflation that happens through that process is also part of why the underwriting EOS is so hard. Yeah.

Several people have commented, actually on how thorough we are about explaining the type errors that you get from ghc, from the compiler. But it's really important to be able to read them and be able to understand what they're telling you so that you can fix things. Right. So anyway, so it's been through the process of me, mostly me, not entirely me, sometimes I ask a question and Chris is even like, oh, I've never thought of that.

And then he has to investigate it more. But it's really been through that process that we kind of came to the order as it is now. And one thing that I like about it is that then by the time you do get to monad, they don't really. They seem completely obvious.

By the time you get to them, it's like, oh, if you know what a functor, what functors are and what the obligatory type class does, it's like, okay, the monad actually just seems really obvious. And I don't know if I go so far as simple, but yeah, I mean, it's simple not in the sense of easy, but in the sense of not really being that complex. Yes. You finish about when I do that.

I finished. I was gonna say something here is this idea you mentioned, where you began with monads was that, you know, your advice early was that maybe that's not the best place to start. Was the best. The better place to start with something around the types and things like that, to get into it and to.

As part of writing this book, you've. You've found a better way to go about the, the monad situation. I guess coming to it as a learner, rather than being so intimidated by starting there and getting maybe Chris's perspective, which would be several years of false starts and maybe finding a better path into the, into the language rather than the most biggest hill possible, so to speak. Right.

So one of the things that. So I started with Alphabet text because that seemed to be one of the initial constituent points for people. Just kind of observationally because I've. Prior to working on the book, I spent a lot of time working with teaching people one on one.

And I mean I've spent probably hundreds if not over thousands of hours just in IRC the last couple years helping people learn. Hassel and every factor tends to doubt because again, most of the resources didn't really give a super compelling or exercise driven explanation. I'm just kind of showing like, hey, this is how you make a product or what you call a struct in other languages. And then it says, hey, here's how you get some type of what you call like an enum or enumeration or union in other languages.

And then they're like, oh, yep, that's it, okay, we're done, let's move on. And that's pretty broad. So that's why Sudan started there. Breaking down Monad arose again from that one on one teaching process where I.

I wouldn't call it Socratic, but I try to be more inquisitive when teaching somebody in a tutoring environment than most teachers are. So when somebody got confused with something like Monad, it was usually the questions, you know, kind of like Almost like Toyota 5Whys but for education, where you keep asking questions to take it to the root cause. The root cause was never Monad itself. It was this vast sea of other things that nobody bothered to explain to them.

Yeah, that's true. I didn't really understand. Well, we'd already kind of written the type classes chapter. It was almost finished.

But then Chris was already working on the monoid chapter, which is kind of the first one of our big chapters about a specific type class. So he's writing the monoe chapter. And I realized when I was reading his first draft of that that like actually there were still things about type classes I didn't understand. And so we went back then and revised the type class chapter more based on my misunderstandings of type classes.

So that then by the time you do get to Monwe, it's like, okay, this thing is a type class that just does this, right? It just is a way to talk about these functions, basically these operations. I have an anecdote from when I went to Philadelphia for the half I kind of hash school meetup. And one of the this was long.

This was after we already read the mono channel and kind of figured a lot of this out. But I was helping a student at Upenn who was taking the CIS552 class, which sounds grad student Y but really a lot of juniors and seniors take it. And it's kind of an interview at Haskell class, you know, and it goes into monads and monetary forms and that sort of thing. And I'm really teaching people 101.

I have a lot of fun doing it. And so we were towards the end of the mini conference thing. So I end up working with him for about three, three and a half hours and but his original problem was I don't understand monads. And I asked the TA that was working with him if I could try, you know, try doing my thing with them and the ta.

Yeah, I'd love to see how I do it. And the thing is pretty quickly, within the first like 10 minutes, just asking him questions. Monad was not the problem. We had to go all the way back to just how the type system worked because he didn't understand how the polymorphism worked.

And since you know, monad itself is a generalization that uses the polymorphism in the type class to have those generalized operations, how can you possibly understand it? I'll go back to that. I didn't get a mobile with Monad. I got them from types all the way up to Functors, but that was enough.

I talked to him an email couple times after that and once he understood how types and high classes he was good to go. So you guys have this approach to this book which I haven't seen elsewhere, which is you don't just have a professional speaking to a hypothetical audience. You have kind of a beginner professional relationship. You have a mentor, mentee, model.

Tell us how that comes through. Obviously it makes sense to me intuitively that just having the beginner feedback as Chris you write makes tons of sense and makes the book a better product. But how does your co author, so how does Julie's voice, your voice, how does the tone work? You guys actually have like is there a dialogue through this book?

Tell us the style, how it reads and how your guys co authorship plays into that. Let me give you an idea of how we write, how we our process of writing a chapter. So Chris lays down an initial scaffold or skeleton of what's going to be in the chapter so that I can start reading other material. So like I'll go to the other books that exist for Haskell or blog posts or whatever I can find on those topics and start reading them so I get a sense of what's coming.

And then he starts laying Out a bunch of. Usually a bunch of bare code examples. We'll say. And sometimes he makes me just figure out the code by myself, and then I write the prose around it, explain what's going on.

Sometimes he writes a little bit of prose and I just go through and start editing it. But his prose tends to be. His prose tends to be on the dense side, and so it can be a little hard to. And so part of my job is to tease out the things that are.

That we're wanting people to get out of it. So then he. After I've written some stuff, it goes back to him and he starts adding things, adding more examples in places where I had questions, answering my questions and so on. And then it'll come back to me and I'll sort of go through and make everything.

Make sure everything has kind of a coherent flow. And I try to, you know, pre up some of our typos and stuff like that. I do miss some, and we get emails about them. But that's the perspective for the book.

Is it written from Chris's perspective with your influence, or is it both of your voices in the book? Is it Julie and Chris together? Or is it simply Chris with Dewey's influence behind the scenes? I think at this point early in the book, I think it was Chris with just Julie's influence.

I think at this point, though, I think it's really both of us co writing. I mean, you can see there are times when I look at a paragraph from, say, like, the Folds chapter, which I haven't looked at in a while, and if I go back and reread it, I'll look at a paragraph and be like, yeah, Chris wrote that paragraph. I can totally tell it's his voice. But most of it now is not that distinctive.

Like, we kind of converged on, I think, a fairly together writing voice, a co writing voice. I think. Now I would agree with that. I mean, Julius Hopkins picked up relatively early in the book partly out of necessity.

It started with Typosa's chapter, I think, where she started really doing a lot of the original writing explanation herself. And part of the reason for that is that I was very, very quickly about to lose my mind in the Folds chapter. Yeah, he was working on the Folds chapter and he just kind of. He did put some code and a general outline of what needed to be in that class's chapter.

He put that there for me. And then he was like, I have to deal with this Folds stuff. He was trying to explain how Folds evaluate in Haskell and It got into. He sort of started.

Did start losing his mind, and so he just kind of threw me the type class's chapter. That's when I really started to kind of insert my own voice into that, into the book a lot more. But I think by this point, we've really converged on, like, the chapter has a more sort of. You know, each chapter has sort of more unified voice of the two of us writing together.

So I do write. I do write example code for the books, and I write some of the exercises even now, too. Whereas when we first started writing the book together, and I was terrified of putting my own code in the book because I was certain it was gonna be wrong, you know, because I was such a beginner. But he does check them, so he does check my code, but.

And I check his. I make sure it runs. So, Julie, you definitely, as language, bring, I'm sure, excellent pros to the book, as well as the perspective that you have. You're also a homeschooling mom.

So how does that play into your teaching style or is there any influence from your teaching your children into writing the book or vice versa? Well, I was a teacher before I was a. Before I was a mom. Before I was a homeschooler, I was a teacher.

I taught. When I was in graduate school, I was teaching assistants. So I taught composition, and I taught English as a second language. I think actually English as a second langu experience helped quite a bit because there's some overlap between teaching a human language and teaching a programming language, I think.

And so for homeschool, one of the things I really like about homeschool is that I can give my kids a lot of freedom to explore topics that they're interested in and to, you know, we can. We can get off of our home school schedule if there's something that they're. That they take a real interest in, right. And they want to explore it for a few more days.