The Changelog: Software Development, Open Source - Haskell Programming (Interview)

Episode Date: March 26, 2016

Chris Allen and Julie Moronuki joined the show to talk about Haskell, their book "Haskell Programming", learning to program, their book writing process, and more.

I'm Christopher Allen. And I'm Julie Moronicki. And you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adams Dekowiak. This is episode 198. Got a great show lined up today talking about Haskell, the programming language. We talked to Chris Allen and Julie Moron 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, OpBeat, and TruSight Pulse. Our first sponsor for the show today is our friends at TopTal. Now, if you're new to the show, let me tell you, we love TopTal.

If you've been listening for a while now, you know that we love TopTile. TopTile is an exclusive network of top freelance software developers and designers. Top companies every single day rely on TopTile freelancers for their most mission-critical projects. And one of the things we love about TopTile is that it's this worldwide community of engineers and designers that just love to enrich the community. As a TopTile engineer or designer, you'll have the flexibility to travel the world, be able to blog on their blog, be able to apply for open source grants and contribute back to things you really care about. Head to TopTile.com to learn more. That's T-O-P-T-A-L.com to learn more or for a more personal introduction, email me, adam at

changelaw.com. I'd love to help you take your first step with TopTal. And now onto the show. Everyone, we got an awesome show today. Jared, this one started off as many shows i said this the last couple shows but it started off with an issue uh i think the issue number was 384 from uh zacky i think uh manny and i'm i'm not really sure if that's exactly but we got chris allen here and we got julie more nicky here talking about haskell programming a book a obviously, and a lot of fun for beginners. But Jerry, what do you think about issues always spawning 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 that our audience is interested in and um we've had Haskell brought up a couple of times um as requests and we just have never had an opportunity to discuss the language specifically and this particular issue

wasn't open too long ago it was like January 31st but there was like three or four immediate thumbs ups and and testimonies that um 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 a little easy here because you got a man and a woman, but for separation of voices, let's get a couple of introductions out of the way, Chris, maybe give us a brief introduction to who you are and,

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 Julie, what about you? Well, my name is Julie Moranuki and I am not a working programmer, or at least I wasn't before I met Chris 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 start would be to just kind of pry a bit more out 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 here today for the listeners, we're going to talk about Haskell, obviously. Also this book they've written together called Haskell Programming. And just in general, the path to becoming a programmer, going from beginner, going from the background, Julie, you've had to being a beginner programmer.

Right. And this path you've taken. But this book, as you've said, and 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've got this, I just put it in parentheses here for us behind the scenes, but I put Julie, you the beginner, and I put Chris the professional because you both say those things in your about section for the book.

But 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 programming, what got you into being a developer? Okay, I'll start because mine is the most recent development. I was never really interested in programming at all. 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 just starting, but at our school, there was starting to be a lot of interest in computational linguistics. And people tried to

get me interested in programming. And I just was always really resistant to it. I'm not sure why exactly, but then in, um, a couple of years ago in 2014, I met Chris on Twitter and, um, Chris was really excited about the fact that I have a background in linguistics and tried to, well, did not tried. He did, he did persuade me to learn Haskell, um, because he wanted me to, 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 anyway, as I started to get some familiarity with Haskell and then it started to become exciting like it started to become exciting for um for me to be able to do

all kinds of things like I just started my blog with Hackle now and so I had to learn about how to get things on a server and stuff like that. And it was all really exciting for me. And I know that sounds sort of, sort of, Oh, hackle is a, hackle is a, it's, it's a static site generator. It's the name is actually a riff off of Jekyll. So that makes sense. Yeah. Yeah. It's a, it's a site generator written in Haskell. And so it's anyway, I just started using that for my blog. So I had to learn what a server was and stuff like that. And being able to do those things now is really exciting for me. But, um, really five years ago, if you'd asked me if I was ever interested in, you know, learning about servers, I would have said absolutely not so um i have to be honest with you i i talked 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 uh you know they they look at me and they say what's a server like what does a server do and i just i fumble with even trying to tell them exactly what a server does like it's server serves it's i feel like uh right the guy in pink panther you know you're the trainer who trains like trainers train and a server serve but well i'm with you on the whole deploying to a server it seems like this black box it does and you know like chris last week last weekend he was helping me get this started and um you know he okay, so we're going to 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. And Nginx is your server. And I was like, well, 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'd mentioned that you're, you've been professionally 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 in software development and programming what was it for you that got you in there

well i mean technology is super early my i don't know if you remember but do you remember those arcade style joysticks for the nes yeah oh yeah um those were a lot easier for a three-year-old to use that's how my dad got me started on on the nintendo um so technology started then programming started later i basically ran out of games to play i'm 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 in this really thick AT&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 adventure game

is kind of boring because you already know all the puzzle answers so that was kind of a problem yeah gotta play somebody else's game yeah yeah yeah exactly only you know i'd had a modem maybe i could have found a game but um that that's where that started uh 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 when I was in middle school. And I learned a lot about Linux, didn't 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 like learning how to program. I was thinking about that because, you know, we ask a lot of people what they got, how they got into programming, who come on the show and a surprising amount. It starts with video games. I was going to say that, yeah. It's like some sort of game got them in there, some sort of hackability to it that made them want to push the boundaries. And I noted in your about, Julie, that you actually said you were never really into games.

No, 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 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 have anything against them. I don't want people to think I'm like judging them for playing video games. Cause 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, I have some free time. Like, so I should, I really want to play this game.

That's just never really happened to me. I don't know why, but like for my son, you know, I'm teaching my son haskell 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 it started for him too so um so uh after i got out of high school and started working as a programmer my first job was actually using c-sharp.net to recover old uh database file formats from mainframes and get imported over to you know pretty standard whitebox.net setup eventually i ended up in new york and started uh using python and django to you know make a content management system because what programmer hasn't worked 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 CommonList was open source. The community was by and large on IRC and mailing lists, and I couldn't have become a programmer without, you know, these hundreds and thousands of people ready to help me and write all this stuff that I could use for free. What was the, the, the moment where you found joy? You know, 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, some level of confidence i think the first thing for me was i wrote a very um a very dumb text-based uh file format for storing data from one of my common list programs because i didn't understand how to use databases or anything yet and um the first time i had a program that could persist its data without relying on common list image format thing 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 um because then it felt like I could actually write

programs that did you know whatever I wanted or previously they had 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 pique her interest, to teach her what you have about Haskell? Well, to start with the language, that was kind of a winnowing process. So Python was kind of like, okay, I'd rather be using CommonList, but I understand this thing

is more popular and it captures most, I'm sure an actual, you know, somebody who still uses CommonList would crucify me for this, but it captures most of the benefits that most people would care about, um, in terms of, you know, being able to do runtime metaprogramming and having a functional ish kind of base. Um, but I eventually moved on to closure because I needed, um, something with a more mature runtime that had threading, uh, that sort of thing. And being able to go back to a Lisp was just kind of a plus, right? That was nice. It was nice to have macros and stuff again.

But I kept running into these problems. Problems that, because I had used a bit of OCaml and a bit of Haskell, just a teensy tiny bit before, I knew that these problems weren't really necessary. These problems didn't need to happen, right? I knew that, you know, everything that, and not everything, but the vast majority of errors I was having at 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 meetup, like let's hack on, you know, everybody breaks up in these teams and hacks on a problem together. I ended up having a runtime error that would have been prevented in Haskell

and very easily found, but in closure, the vectors are actually functions. You can just use like a piece of data as if it was a function, apply it to an argument. And when you do that, you're using it like an index. And the problem is, is that the, are you guys familiar with like the concept of like a source to sync distance not me okay so if you ever work in like static analysis or on like uh like you know something kind of like code climate or one of those like kind of static analysis linkers typers kind of things you're trying to keep your source to 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 it to just kind of pin it on the nose. The problem is that people think that, you know, runtime errors can help shrink that distance, but in many cases, you can actually make it much worse. And 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 debugged it. I put print lines all over the entire program, and it was still a massive pain.

And I realized that if I had been using Haskell 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, you know, other things about Clojure, like having, you know, software transactional memory and other things like that. So that narrowed it down to OCaml and Haskell. And then concurrency and laziness, a few other things, kind of decided it 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 there you go with haskell right so i realized that i had to take responsibility for um increasing the size of the community more generally but also specifically i needed a path or a means of like saying to three co-workers okay do this this this and this and then we'll start pair programming to get you going. Right. So that's what led to the guide that I wrote.

It's bite my app slash learn Haskell on GitHub. It has over 3000 stars now. That guide was basically a recommended order of free resources to get going with Haskell as quickly as possible. And it was that desire to be able to tell, you know, my manager with a straight face that, yes, I can get people going with it. And that's also when I realized that I just had to get better at teaching in order for that not to be a super messy and painful process. Um, that all kind of culminated in me deciding, okay, I just need to write a book because I couldn't figure out how to kind of fit the Lego pieces of existing free resources together in a way that would really satisfy me.

Around the time I decided I was going to write a book, a few months prior to that, Julie and I had become friends via Twitter for reasons just, you know, totally unrelated to programming. Yeah, just some shared interests. Yeah, we were talking, it was actually, we first met in a thread about history, some kind of historical topic that we were both engaged with i don't remember exactly what it was but that it had nothing to do with programming sounds right yeah and uh 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 Haskell

was kind of exciting because there is some good kit in Haskell for NLP, but it's not as mature as, you know, like say the Stanford NLP stuff for Java and all that, right? So I thought maybe it could be fun to learn NLP side-by-side with a linguist. And since I already had this book that I was going to work on it would be kind of nice to have a beginner vet the material as I'm writing it um of course she had you know upgraded from you know somebody

vetting the material to a co-author yes yes I did very cool I think that sets a good stage we're going to take 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. Yes. And just have some more questions about the programming language itself. But I think this is a really nice setup for this book, which people people are finding quite useful is the idea of let's write a book not just a professional talking as if some sort of a hypothetical

beginners out there but let's actually have a beginner alongside helping write the book i think that's a i don't know if it's a unique take but it's an interesting one to say the least so we'll pause here take a break and we'll be right back. Our friends at Linode offer a pretty cool service I wanted to tell you about today. It's called Professional Services. This is something where you can hire them to take care of set migrations, one-off system admin tasks, server installs, or anything else you can think of. They offer this as an add-on to their 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 prompt, diagnose, troubleshoot, configure their Linode to meet the needs of their application. So our team here is diverse and, you know, we specialize in, you know, multiple areas. We've been in, you know, the hosting industry for many years now. We specialize in Linux, so that's our forte. So we have excellent people here that are skilled and experienced in multiple areas of Linux. So they can typically execute these projects or solutions efficiently for these customers that need our assistance.

Well, Dave, now that we know more about Linode's professional services, talk us through getting started. What's that process like? Existing and prospective 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 if everything looks good, then 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 of what happens next. We have implementation specialists here that get assigned your 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, you know, 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, if it's in the project and we're handling it, we'll do the DNS cutover as well. All right. That was Dave Messina, product manager for Linode's Professional Services. As you can see, if you've got a need, Linode's got your back. Head to Linode.com slash pro services.

Once again, Linode.com slash pro services 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 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 the logic of 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 I'll talk about that in just a second. And so with Haskell, the connection is with generative syntax. What you're trying to do is find the rules that can produce all the legal or grammatical sentences for a language and not produce or allow any illegal or ungrammatical sentences. Right. So a lot of linguists, not all, because Chomsky is a little bit controversial sometimes, but a lot of linguists think that we have these kind of internalized rules of syntax 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 generative syntax. And 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 Haskell. I was listening to a talk. I think it was from Strange Loop. And I think it was Paul Snively and Amanda. I'm not sure how to pronounce her last name. Locker. Locker. Something like that. And I believe it was in one of their talks. 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 then 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 Haskell-er 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.

And so the function is a verb. And then the arguments that it takes in the language would be the subject and the object and any prepositional phrases, for example, that it takes as 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 did. So the type system is obviously a big piece of how Haskell works. And it's something that people either love or hate. You know, dynamic, static, strong, loose typing is one of

those age-old flame wars. If we're not arguing about Vim versus Emacs, it's dynamic versus static type systems. Yes. Here's a 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. 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's type system and why it's so interesting? Haskell's type system is nice, but it is kind of an instrumental thing for me. I like it because it's relatively small and easy to understand compared to languages that are trying to blend multiple paradigms. Part of the appeal of, say, something like Python is that, you know, there's pretty common patterns to the 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 a line of code in Python as compared to, say, Ruby or Perl. No offense to users of those languages. Tons of Ruby and Perl users in the Haskell community. But I don't think a lot of people would debate that. So in Haskell, the nice thing about the type system is it's actually very compact. The semantics of the language are pretty alien to people, but the type system is it's actually very compact. The semantics of the 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 that you might want to use. Type classes are one of those things. And one of the advantages of that is it just makes the results more predictable. You don't have to guess how a piece of code, what its type will be inferred as. So for me as a working programmer, Haskell's type system is 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 type checker happy because it really only disallows stuff that I would never want to do anyway. And I know a lot of people who don't have a lot of experience with stack type systems aren't going to believe me on that point.

But it legitimately is the case, at least for me. It does take some time to kind of remold your brain to think in those terms but it does happen so from there i mean the basic idea of the type system um in haskell is that you have these types that enumerate uh possible valid kind of you know we call them inhabitants but we're really just talking about like okay this is a valid value that inhabits this type right um so bool is a type in haskell it's not just an alias for for an integer like it is in like c that kind of thing um it just has two values or two data constructors they're called in haskell but they're just two kind of nullary values and they're just true and false so that has two things that are a valid bool and then that's'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 a valid bool. We don't have that. It's just true and false. So that's the basics of it. And then 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 plus and then plus dot for ins and floats and that sort of thing. It also means you can extend other types to implement the numType class if you so desire. But there are some constraints. 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. It's basically how you encode the principle of least surprise on a per-type class basis. Then from there, contrary to popular belief, the Haskell type system has some escape hatchets. For example, you can put an error value in the definition of a function if you want to say it has a type, but you don't have time to implement it right now. And this actually turns 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 REPL, my read-avail print loop, what type would it be if I compose functions F, G, and H? Given that I've only defined their types, I haven't actually implemented them, evaluating would actually produce a runtime error, tell me what would happen. And then I can figure out if I'm actually figuring out the right design or combination

of functions that achieves what I want before I've really done any real work. I just wanted to say here about this, what 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, um, 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, you know, kind of way to step away from the specifics so that you can make certain you're even thinking the right thoughts before you do all the work up front. So just as a, as a way of getting a little bit 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 to mind for me is Perl, which was created, you know, as an extract. Now I'm forgetting what the acronym is. It's for text extraction. And what's Perl's acronym? Help me out here. No help Googling.

I'm not actually sure. It's for text processing. Practical extraction and report language. Yeah, text extraction. Practical extraction and report language. Yeah, so its whole purpose was for manipulating and performing reports on text. And so it's designed like that. Where did Haskell come from?

What problems was it set out to solve? And why is it designed in such a way that you just described it, Chris? And then as a follow-up to 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 it 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 in the 1980s. Haskell descends from the ML family of languages. ML started in 1973, and it was kind of descended from Landon's Ice Swim 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 evaluated. They're evaluated immediately whenever you bind them, right? The research that was going on in the 1980s was to figure out a lazy functional programming language. And Haskell was this collection point of, OK, 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 programming 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 that a 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, you know, maybe an experienced programmer could even say naive code. But because you're not doing any of the work immediately upon binding, it leads to the situation where you can have code that looks nice and looks naive, but actually optimizes to what you would actually want it to execute as. So a good example is when you map, you know, say a function F, G, and H over a list, right?

The non-naive way to do it is to compose all the functions that you're going to map over that list all at once so that 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? Well, Haskell, it doesn't.

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 up front all at once immediately but also because of the it knows where effects could happen so it knows when it can move certain bits of code around it means it's actually free free to reorder your code because it knows where that is and is not allowable. The purity fell out of the 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 OCaml does, and it means you can't have a language that has an imperative kind of sub language like OCaml

does. And it means you can't have effects be implicit. When you perform effects, you know, whether that be talking over a network socket or printing or whatever, it shows up in your types 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 it to do things in the right order as you intended was a nightmare and I think that particular scheme implementation was a cruel joke on some grad students

but the point is it basically laziness forced purity but then later on people realized that purity was really quite valuable in its own right purity and sense of being a pure lambda calculus people get really hung up on that word and 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 as a follow-up to that was kind of where do we see haskell getting used out there in the wild? It has crossed my radar a few times 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 is being used to solve cool problems. To compare it to some 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, Prolog. So that kind of spans basically pretty much anything you use the garbage collected language for.

It leans more on the side of, say, like Go, OCaml, Java, Scala, 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 to JS now. So you can use it for a front-end web app if that's your cup of tea. There's

a Haskell-like not exactly the same thing, but a Haskell-like compile to 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 PeerScript recently be compared to Elm. Is that right? Yeah. So, I mean, they kind of exist on the same continuum, but PeerScript's a lot closer to Haskell. It's not identical and you still lose some stuff going to PeerScript from

Haskell, especially if you've been using any of the advanced features, but there, but I mean, for example, like peer script has type classes, uh, Elm doesn't, and Elm is kind of,

uh, uh, stripping the shit there and an attempt to attract more people who haven't necessarily used a functional language or, or a type functional language before. Gotcha. PureScript is trying to kind of inhabit a, it's kind of a Haskell that's been redesigned with the needs of front-end

DOM manipulation in mind. Yeah, somebody just requested a show on PureScript in ping. I don't know if it was last week. Just while you're talking, Chris, as a proxy for success, I've searched the most starred GitHub repos with the Haskell language. Number one is Postgres,

which was a REST API for any Postgres database, which seems pretty cool. Also, Elm's compiler is written Haskell. As you mentioned, PureScript is a top five. Just to give people a taste of what people are 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 LambdaConf

called how to learn Haskell in less than five, which seems like a long time, but can you share more? And why does it take five years to learn? Aside from the dreaded monad concept, which we've all but skirted so far in this show, what makes Haskell so hard to pick up? 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 think probably, I don't know, once or twice a year for those five years. This isn't five years of steady learning. This is five years of, okay, I'm going to try to pick this up again. Nope, still can't write a web app. Okay, I'm out. So you weren't actually trying for five years. It was sort of over a span of five years.

Yeah, no no it wasn't consistent effort but right but yeah but each false start was you know at least like a week or two right um and like kind of alternating with that i'd also play with ok ml because it was kind of scratching some of the same itches right and um and i realized the problem was was that the the 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 know how to program. Why don't you tell me how Haskell?

And it turns out doing that is much faster. I can get somebody going with Haskell in weeks easily, especially if I have some pair programming time with them. If I toss them our book and pair program with them, I can get them going in like two weeks hacking on a web app in Haskell. It doesn't have to be hard. It's just that the existing resources were a bit rough and Haskellers 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 you know python ruby js you can use just how well designed the landing page for a library is to gauge how much the maintainer cares about and how much effort they're putting in right those cues Those cues, those social cues, they don't exist in Haskell.

The best library for something, it's going to have the same hackage, boring landing page that everything else has. So that's another problem is that newbies will get 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 a good way to discriminate. Let's really tease up the learning path for us.

Chris, I know it's taking you five years to false start your way into Haskell and still be a professional at the same time. Julie, it seems like you've got a much faster path. So let's take a break. And when we come back from this break, we'll kind of dive a little bit more into the book, the learning process. And maybe, Julie, you can share how you got there so quickly versus Chris's five years of all starts. We'll break here and be right back.

I'm here with Thomas Watson of Opbeat. And as listeners of the show, you know that we love 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 op beat is doing some really interesting things around application performance monitoring specifically around node.js and thomas has an interesting story on how he got started with op beat and also starting off their node support so thomas say hello hey hello everybody thomas you got an interesting story here with how you came to be at upbeat it seems like the the node support is kind of in thanks to you so what what's the backstory on that yeah so i've been doing node.js

for almost five years and i i found upbeat and they were doing uh they were doing application performance monitoring 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, we would 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 Upbeat, being the Node.js lead. And I'm now responsible for this agent that I started back in the days as an open source project. I'm now responsible for that at Upbeat. And that's the one you install on your production servers to monitor the health and performance of your application. And so that module is Opbeat Node.

And so things began with that open source repo. Is that how things began for you with this? Yeah, I started it under my own GitHub account and just did it for myself and my own projects. And then people started using it and the Opbeat guys were really happy with it. And then when we decided to join forces, and then people started using it and the upbeat guys were really happy with it uh and then we when we decided to to uh to join forces um we moved it to the upbeat org on github so now it resides on

github.com slash upbeat slash uh upbeat node that's really interesting to 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 uh you know language platform like node and then a service like oppie to get that application performance monitoring into your own apps you were like hey you don't have it but i can write this and and now you actually work there and you're building it out yeah that's the beauty of open source uh it connects you with a lot of people and you can basically do what you want for yourself. And then if people like it, you see where it takes you. In this case, it took me to 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're just going out of beta soon. You can go to upbeat.com slash Node.js and sign up for the beta if you want to try out the stuff. So the Upbeat Node module, can you talk a bit about what it does? So basically it sits on your server inside your Node.js app. You require

it at the top of your main program and it just monitors the overall health of your application on a request basis. So incoming HTTP requests to your node server figures out what's slow, what's performing badly, what should you take a look at to optimize. Maybe it's a database thing,

maybe it's a Reddish cache or something else. And it also monitors errors happening in production. So we will break down the error, figure out who made that code, when was it committed to Git, when was it pushed to production. So we can auto-assign errors as well to the developers who actually

is responsible for the code that is breaking. So obviously your passion for open source and your passion for giving back got you to doing some of this stuff with Opbeat and what we just described there with your Node support and whatnot. Can you talk a bit about your work at Node School, the open source you've written, just some of your passions around open source and kind of how you think about open source? Yeah, I really love open source and I've been a big open source software user for over 20 years. So when I joined the Node.js community five years ago and finding such a big open source spirit in the community, it was really exciting.

So I've now gone from an open source user to an open source developer. I love to teach. That's one of my passions. And especially, of course, I love to teach programming. So there's something called a Node School 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, you know, on the web, you know, kind of remotely, so to speak, but 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 and you can you can take some courses online but you can also join some of the the regional chapters and you can meet up at a city uh there'll be a node school event where we will have tutors who can help you out with your your note questions and you can actually do some of

these online courses you can do them in in person in real life with people who who know node really well and i try to do that as much as i can. I've been organizing one here in Copenhagen where I'm from. Well, cool. If you want to follow up with Thomas, you can check him out at github.com slash Watson. That's his last name, W-A-T-S-O-N. If you want to sign up for the Opbeat Node.js beta, you can do so at opbeat.com slash Node.js.

And now back to 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 we got to hear your five year fall starts and the deeper story behind that for you and Julie you come from a background of linguistics and philosophy and you were roped into this gig so to speak from

Chris's 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 of learning Haskell. Well, I mean, everybody says, or 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 they've people who already know some other languages have to kind of

clear out what they already know about programming to 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 of other programming languages now I can see why people. I mean, you do have to, from what little I know of other programming languages now, I can see why people say that. I mean, you definitely have to think differently about how you're 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 like real world haskell the book um not to you know disrespect it or anything like that but um they explain a lot of things in terms of c which i don't know and um so things like that were really hard. Um, 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 an imperative language. So, um, that was one of the hurdles. The other hurdle for me was that, um, 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 Haskell. And so the first few months of Haskell were just like really rough because um rather than learning the programming language or 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 um 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, these things are not obvious. So, um, so those were the two biggest hurdles for me. Um,

Haskell itself, I don't think, um, for me, it hasn't been, I mean, there are difficult things about it for sure. Um, but I really think that a lot of it just 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 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 going to learn Haskell, I have to learn about monads. And 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 is going to be too hard.

And yeah. On that note, then what's the, what's the best place to start in your opinion then, since you came from scratch, so to speak, and you even learned what it took to, to learn a programming language,

what's in your opinion, what's the best place to start? What's the, what got you? One thing I would say about this is that when we started writing the book, we had to figure out how to break the language down into kind of an order, a sensible order of how to learn things. And if you start really critically analyzing it, you realize, okay, to understand monad, which is just a type class, you know, it's just a generalization of a pattern, basically. You realize that 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've got to learn, you know, how types in Haskell work, you know, just normal concrete types, not just type classes specifically. Right.

And if you follow this kind of regression, you'll just land it. 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 calculus 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.

So you've been talking about the Land of Calculus and the various things you've talked about in the book. So let's just break that open. There's a process behind this book. You've got tons of chapters'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.

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 they 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 the code and exercises in the book. So a lot of the splitting that happened in types and type classes is, oh, Julie and I tripped over this weird error or whatever in the process of doing this.

So we don't want to just address that that's a possibility. We want to explain it properly. We don't want to just skip over it. So the kind of content inflation that happened through that process is also part of why they underwent meiosis and split apart. Yeah. Several people have commented actually on how thorough we are about explaining the type errors that you get from the, 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, and 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'd 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 what what the applicative type class does it's like okay the monad actually just seems really obvious and i don't know if i'd 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 oh i just you can finish your thought when i do that i'm just i finished go okay voice trip i was gonna say something here is is the is this idea you

mentioned where you began with monads was that you know your advice early julie was that maybe that's not the best place to start was the the best the better place to start would be something around the types and things like that to to get into it. And as part of writing this book, you've found a better way to go about the Monad situation, I guess, coming to it as a learner rather than being so intimidated by it starting there and getting maybe Chris's perspective, which was the several years of false starts, and maybe finding a better path into the language rather than the the most biggest hill possible so to speak right so um one of the things that so i started with algebraic data types because that seemed to be one of the initial kind of sticking 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 um i mean i've spent probably hundreds if not over a thousand hours just in irc uh the last couple years helping people learn haskell and algebraic data type just kind of stood out because again most of the resources didn't really give a super compelling or exercise driven explanation of them they just kind of show you like hey this is how you make a product or what you would call a struct in other languages. And then it says, hey, here's how you make a sum type or what you would call like an enum or a numeration or a 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 abrupt. So that's why it stood out and I started there. Breaking down Monad arose again from that one-on-one teaching process where 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 a Toyota five wise,

but for education where you keep asking a question until you get to the root cause. The root cause was never Monad itself. It was this vast sea of other things that nobody had bothered to explain to them. Yeah, that's true. I didn't really understand. Well, we had already kind of written the type classes chapter and 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 monoid 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 classes chapter more based on my misunderstandings of type classes. So that then by the time you do get to monoid, 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 Hack-Fi kind of Haskell meetup. And one of the, this was long, this was after we had already written the Monad chapter and kind of figured a lot of this out, but I was helping a student at UPenn who was taking the CIS 552 class, which sounds grad student-y,

but really like a lot of juniors and seniors take it. And it's kind of an intermediate Haskell class. You know, and it goes into monads and monad transformers and that sort of thing. And I really like teaching people one-on-one. I have a lot of fun doing it. And so we were towards the end of the little meetup or mini conference thing.

So I ended 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 then the TA said, yeah, I'd love to see how you do it. And, but the thing is, is pretty quickly within the first like 10 minutes of just asking them questions, monad was not the problem. We had to go all the way back just to how the type system worked because he didn't understand how the, how 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 if you don't roll back to that i didn't get them all the way the monad i got them from types all the way up to functors but that was enough he i talked to him and emailed a couple times after that and once he understood higher kind of types and type classes he was good to go so you guys have this this approach to this, 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 the 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 it makes a book a better product, but how does your,

your coauthoring it? So how does the Julie's voice and 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, and how your guys' coauthorship plays into that.

Let me give you an idea of how we write, how we, our process of writing a chapter. Um, so Chris lays down an initial, an initial scaffold or skeleton of what's going to be in the chapter so that I can start reading other materials. 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 explaining 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, um, his prose tends to be on the dense side. And so, um, it can be a little hard to,

and so part of my job is to tease out the, 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, and, um, I try to, you know, pretty up some of our typos and stuff like that. I do miss some and we get emails about them, but that's kind of perspective for the, 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 Julie's influence behind the scenes? I think at this point early in the book, I think it was Chris with just Julie's influence. Um, I think at this point though, um, 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 you can see. There are times when I 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, yep, Chris wrote that paragraph. Like, I can totally tell that's his voice, but most of it now is not that distinctive.

Like we've kind of converged on I think a, a fairly together writing voice, a co-writing voice. I think now. I would agree with that. And I mean, Julie's confidence picked up relatively early in the book, partly out of necessity. It started with the type classes chapter, I think. Yes. 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 when it was and he just kind of he he did put some some code and a general outline of what needed to be in the type classes chapter he put that there for me and then he was like i have to deal with this fold stuff he was trying to explain how folds evaluate in haskell and um it got into it he he sort of started did start sort of start losing his mind um and so he just kind of threw me the type classes chapter and that's when I really started to um kind of insert my own voice into that into the book a lot more but I think by this point we've we've really converged on like the chapter has a more sort of you know each chapter has sort of a 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, I mean, I was terrified of putting any of my own code in the book because I was certain it was going to be wrong, you know, because I was such a beginner. But he does check them. So he does check my code. And I check his. I make sure it runs. So, Julie, you definitely, as a linguist, bring, I'm sure, excellent prose 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 mom, before I was a homeschooler. I was a teacher. I taught when I was in graduate school. I was a teaching assistant. So I taught composition and I taught English as a second language. I think actually the English as a second language 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 get off of our homeschool schedule if there's something

that they're, that they've taken a real interest in. Right. And, and they want to explore it for a few more days. Right. And we go through this almost every spring when they discover some new type of insect and they just want to, I have boys, I have two boys and they'll find, you know, some new kind of insect. And we spent like a week talking about nothing but roly polies and how they're not actually insects one time.

And so we have the freedom to do that. And I think to a certain extent that has informed the way we've written the book, because we really encourage people to take like some example in the book and some example code or some concept in the book and just play with it. And like, well, what's going to happen if you change it to do this? And what's going to happen if you change, you know, the type signature to this and just play with it, you know, just explore this and see, because you're going to learn a lot by doing that and not only doing just exactly what we tell you, right? Another thing we do in the book to try to encourage people to explore and kind of, you know, dig as deep as is going to satisfy them is beginning. Even with the initial Lambda calculus chapter,

we put follow-up reading at the end of pretty much every chapter. There may be one we don't, but there's for the most part, decent list of follow-up reading in every chapter. And one of the things we do with that list of follow-up reading is we try to order it by both what's going to be easiest for them to understand and also what's nearest to hand or nearest to their experience. So the more theoretical stuff will come later, even if it's not necessarily harder. And a fair number of our readers have really appreciated that because some of them are

more theoretically inclined. Some of them just want to dig more into operational and technical details, but that's available for them, even if we don't really have time in the book to talk about it. And then they have kind of a recommended list of materials that we've vetted and checked out for ourselves and kind of ranked in that little listing. Yeah. So, and then of course, now I'm, as part of homeschool, I'm actually testing the book with my 10 year old son, soon to be 11. He'll be 11 in two weeks. And I was really surprised because when he first started the book, we didn't have a Lambda calculus chapter yet. And then a whole bunch of crazy things happened in our life. And so he wasn't able to, to keep doing Haskell like over the summer and stuff. And so when he came back to the book, I said, well, now we've added this chapter on the Lambda calculus and I want to see if you can do it fully expecting that a 10 year

old would have a really hard time with the Lambda calculus. Cause it's something I learned about in college, you know, and, um, he read the chapter. There were some terms that he didn't understand very well. And so he gave us some that gave us some ideas of how we could revise it so that it's the terms are a little more clear to people who maybe don't have some of that vocabulary already. And but he he read the Lambda Calculus chapter. He did the exercises. He really liked it. He thought it was really cool. And that was exciting for me to be able to introduce that to, to him, you know, and,

and find that he enjoyed it. So there was only that one exercise he got stuck on. He was able to do all the others by himself, wasn't he? Yeah. Yeah. The last exercise of the, of the reduction. Yeah. The hardest one.

Yeah. The hardest one he got kind of stuck on because he lost track of some of the reduction yeah the hardest one yeah the hardest one he got kind of stuck on because he lost track of some of his variables there's some tricky stuff with alpha renaming in that one yeah so i just kind of got him over that hump like we traced his steps back to where he got confused and then and then he was able to figure it out and i was that was really exciting for me to to share that with him and so now he's in chapter uh four i think and um going strong so he occasionally occasionally stuff that he stumbles over we find a place where we need to you know go back and so writing the book informs my homeschool to a certain extent and then homeschool informs the writing the book

and it's all kind of a nice synthesis just say for the listeners julie's been writing about the process of teaching Haskell to her 10-year-old on her blog. We will link that up in the show notes. Wanted to point out this quote because I just loved it where he gives you an ultimatum. I think you're quoting yourself

on Twitter here where your son said, well, I'm going to keep learning JavaScript until you teach me Haskell and hashtag the ultimatum. So it seems like he was ready to go and he was ready to use JavaScript against you. Yeah, well, he,

JavaScript was the first sort of experimenting he did, I think with Khan Academy. I think it might, it's Khan Academy. They have like an hour of code every winter, I think it is. And so they have this little JavaScript program that the kids can do to make like a Christmas card is what he made. And he had a really good time with that. But a lot of the things that he was doing with the JavaScript were really

opaque to him. He didn't really understand what he was doing. And then after that, he was taking this class learning how to make Minecraft mods. And I think there was a lot of good stuff in the class. And he was really excited, of course, to be making his own mod, and making his own weapons for Minecraft and stuff. But that's, of course, Java. And he, again, he didn't understand a lot of what was going on with the actual Java. A lot of it was like kind of copying and pasting. And when he started learning Haskell, I think he felt more like, oh, now I actually understand what's happening. So even though it's taking me a little bit longer to learn, like I'm not just copying and pasting things, I'm actually understanding what I'm doing.

And that was really exciting for him. I think the counterintuitive takeaway from this experience is that I think that having graphics or something interactive can definitely help get kids interested. But I think that we undervalue the intrinsic motivation that comes with actually understanding what you're doing instead of copying and pasting. And I mean, our book basically starts with arithmetic, you know, but that's still enough, you know, and I think that the times the interaction is to peak curiosity, right? It's to get them interested, but get them interested without the interaction. There's more substance, uh, than a lot of the, um, other ways of doing it. I've, I've gone through and I love, I love what they have up on the code.org with the, uh, the different things for kids to get into it and just to get them interested. And then the idea is like, that's, that's a, to whet your appetite and now take you somewhere else um and in my experience with my kids i my oldest is seven so a little bit younger but it's it's very much the end of of the road of the road

unfortunately at least for now um yeah because there's not much beyond it's like there's it's like we were saying earlier how um you know a lot of people came to programming because they were interested in video games, right programming to kids and stuff is that kids are really a lot smarter than we often give them credit for. They're not the same as adults. And obviously they don't have the same vocabulary as a lot of adults, but they're really a lot smarter and more capable of figuring things out than a lot of people want to give them credit for. And so I try to do that. And I guess the attitude has also kind of informed the book like

we don't want to we want to make haskell accessible but without like ever talking down to our readers or assuming they're not capable of learning things you know yeah this was actually an issue we had we we're publishing this book independently right now and making it available independently but we actually had a publisher before that we separated from and one of the one of the many points of disagreement we had with them was so the big scary sequence of chapters in the book that begin the second half are monoid functors applicative and monad you don't know what those words mean that's fine you don't have to we'll explain it but one of the issues is that they didn't want to send him the chapters after what the chapters

were about because people were afraid of the names the words and part of the way we write and the way we talk to our readers is we say all right suspend your fear for a bit we will get you where you need to go but you can't you can't just permanently hide stuff like that one of the problems with renaming things you know like mono and monad is that you're essentially taking control over their education because if you use some other term for monad like say computation expression are they going to be able to find all the research and all the writing about monad no you're now fracturing quite a bit too, by just creating confusion. Yeah.

Yeah. And the thing is really what we would rather do is get people to a place where they're no longer afraid of things that they don't understand and instead react to those experiences with curiosity and more of an open, like, okay, this is a thing I don't know. Why don't you explain it to me? Right. And, you know, the honest you explain it to me right and you know the honest is on us to actually make it understandable and that's our responsibility but i don't think you do anyone any favors by just fragmenting the the you know vocabulary

and calling the chapter functor and keeping that word in there instead of trying to rename it to something else gave me a chance to talk about rudolph karnap so um you know very close to my heart oh yeah it's good excuse well julie you've gotten me interested on two points first of all uh you said rolling poise aren't insects and so i'm over here i'm just gonna i'm just gonna teach myself that one with google and then i don't know who that fellow is he just mentioned but maybe you can tell me off rudolph karnap was a large logician. And he, as far as I can tell, he's the first one who used the word functor. He is actually using the word functor to in a work of that he wrote about language.

So it was a philosophy of language book. And that's why I was familiar with it. So he describes a functor as being a sentence level sort of operation. So it lifts a sentence up into a different, up into this new sort of semantic category. So like negation is a functor in his philosophy of language, because once you've negated a sentence, like that negation applies to like the whole sentence. Right. So it lifts the whole sentence into the realm of negation. Right. And so that's a functor for car now. So we,

there's a paragraph in the introduction to the chapter where it's I got to indulge my, my love of linguistics. We can, we can, we can definitely detect. Yes. Great name to wrote Rudolph car nap. Just fun to say. Yeah, it is. Well, let's pause here for our final break and we come back.

We're going to talk to you guys a little bit more about the book, the process, where it's at, where you think it's going to be. It's probably going to be about 1300 pages. So there's going to be a lot in there. We'll talk about what's in there, the process you guys to write it, and then we'll close off with our closing question. So stay tuned. We'll be right back. We're working with our friends at BMC to spread the word about TrueSight Pulse, the real-time monitoring service for apps and infrastructure. I talked to Mike Moran, the senior architect, about the idea of dev teams

out there rolling their own monitoring system using something that's open source or building their own from scratch. And he had this to say. I think if you want to roll your own and spend the dev effort of having to build that internally, that's great. My only question to you is if you spend your time doing that, are you providing value to your customer and are you actually moving your product forward or are you holding your product back? I think a lot of what something like TrueSight Pulse offers you is we take a lot of that on for you so you can provide that value to your customer on your product instead. So we have plugins for, I think there's 30 plugins for different parts of your

infrastructure. We have an agent that's been running for three years written in C that takes a very small amount of your resources. As you add more servers, you're not going to have to worry about the scalability as much. And we've written the chef and the puppet scripts for you. So that's all taken care of. It's letting us worry about it so you can focus on your customers. That's kind of the value that TruSight Pulse adds, as opposed to you having to do it yourself. We've all been in organizations where we've joined and had to rewrite the entire monitoring stack. And that's just something we didn't want to have to do.

We want to come in. We want that taken care of. And then that way we can focus on the things that are going to matter to our customers. So, of course, you want to focus on what matters to your customers. That's the whole point. But I had to press Mike further about these teams out there that just have to roll their own things. They get attracted by shiny objects. They love to tinker. And his advice on remaining focused on delivering customer value and how

TruSight Pulse enables that is just awesome. Developers have this innate ability to want to tinker and to want to build their own and to want to customize something exactly as they need it. And that's in our DNA. It's what makes products great. It makes why customers come back. I think sometimes we get a little distracted and sometimes it's either the new shiny toy or something I read on Hacker News. And that's where my focus gets deviated into. And I think monitoring is one of those perfect examples because it's something that everybody wants to work exactly the way they think they want it to. When if they take a step back, they don't actually need maybe some of that customization they're going to do. And it took them a large amount of time.

And in the end, they didn't deliver any extra customer value. If they took that effort instead, would be building on their product, they'd be more successful. And I think that's a lot of what we're trying to do at TruSight Pulse, which is to kind of give you that level up, so you have that already. You have the infrastructure monitoring, you have the plugins, you have the alerting, you have that whole workflow, so you can focus on your customers.

It's fun to tinker and we support that fully. All of our plugins are open source, they're on GitHub, so you can create new ones or you can extend those. We have actions that we can do. We can pull in more things for hooks and triggers. But the core value is your product and it's how you deliver that to your customers. And that's what we want to help you focus on. So we can take some of that load away from you. We think you can do better from a product point of view and you can deliver more value. That was Mike Moran, Senior Architect at Truesight Pulse. To learn more about Truesight Pulse and how it helps you deliver more value to your customers,

head to bmc.com slash Truesight Pulse, all one word, and tell them Adam from the Chainslog sent you. All right, we're back. We're ready to close up this conversation all about Haskell, learning Haskell, teaching other people Haskell. And we focused on the book that you two are co-authoring. You told us kind of your process of tag teaming the authorship still sounds like you have a singular voice coming through, but the perspective of both a professional with the beginners helping guide the content. Can you tell us more about the book, kind of where it stands in its completion? The new thing these days is to have books out there that people read and participate in,

but they're not finished yet. Where is your guys' book at? And give us just more information about it. So a common misconception about the book is that it's only a beginner's book. That's one of the reasons it's over a thousand pages right now is that we actually, our goals were based on a functional objective, non-specific topics we wanted to cover. And basically the goal was teach them enough Haskell that they can either know or learn on their own everything they would want to know in order to use Haskell for pretty typical projects, like a web API or something. Right now, the book, 90% of the content that we're going to write is already out for release.

That's 29 out of 32 chapters. We have the final three chapters about half done, and we expect to be content complete by the beginning of April. And in April, we are going to do our final editing pass. And we hope to have, you know, what software would call a release candidate by the beginning of May. Pretty close then. Yes. I mean, based on the site, it says you're 90% through the book, 50% through the last 10% remaining. Yep.

Yep. Something else that is kind of interesting that I took note of was the code to learn to learn to code. And we mentioned in the breaks, which is sad because our listeners don't get to hear the breaks. Jared and I are actually laughing behind the scenes that we might actually release a show called Just Breaks and just put the breaks in the break show. But we'll see about that one because sometimes it's off air stuff. But nonetheless, the length of the book is also attributed to the code examples.

And it's loaded, as you say, each chapter is loaded with examples and exercises so that it can follow along with what you just said there, Chris, which is learning Haskell to a point where you can actually use it. Can you talk a bit about this idea of and why it's so important for both of you to code to learn, to learn to code? So one of the things we do that we think sets the book apart is we try not to make assertions that aren't somehow provably or observably true. Basically, if you make an assertion about how the language works, well, I mean, if you can't actually demonstrate it, then how would it ever make a difference in how their code works? Right. Seems to make sense. Well, the thing is, is that that basically means you're writing a lot of examples each and every time you describe some facet or feature of the language. And that's where really where most of the, the book's length comes from

is the fact that we, you know, we make an assertion and then Julie, you know, says, Hey, you said this, show me, you know, it's Missouri all the way through. And, uh, that's where most of the length comes from. Um, our readers have actually told us it's a, it's a pretty breezy read. Some of them have blasted through the book pretty quickly. So it's not really super prose heavy and it's not, it doesn't feel dense. It's just code takes up a lot of room in a book. That's just how it is. There's nothing we can do about that.

But we think it really, really benefits from that. Yeah, it needs to be there. And then the code to learn thing is just that we try to get them working through the book and the exercise and examples in a way that translates fairly naturally natively to how they would actually work in Haskell. So to that end, we teach and show them how to use the GHCI redevelop print loop. If you're using Python, the equivalent would be like IPython or IRB, if you're a Ruby user, that kind of thing, right? And then learning how to kind of interact and talk to your code and types through the book gets you the practice you need to be able to figure out things when you're on your own. So I've made a note here that we've gone this entire show without mentioning, I'm not sure if you'd actually said the name of the book or the URL. So as part of segueing into our closing questions,

let's talk about the URL. It's Haskell book.com. And is it called Haskell programming? Is that the official name of the book? Yeah, it's Haskell programming from first principles. So, or Haskell programming,

but a lot of people just call it Haskell book because that's the name of the URL. So just wasn't sure on that. So I guess at this point we can probably tail in some closing questions. Definitely, you know, loved learning all about the process of this book and even the perspective you two add to it. The one way we like to close this show out

is by asking some questions more or less around heroes and also things that are on your radar. So do you have a programming hero? Yeah, we were talking about this before the show. I would go with, I'm going to go with Simon Peyton Jones because not only is he obviously really important in the history of Haskell and the development of Haskell, but, um, he also just every, every time you see a talk from him or people that I know who've met him, they say he's just really super friendly and, and likes to engage with, um, you know, conversation with people, even if they disagree with him. And I think that's really admirable. And I also like, um, he's been involved with getting computer science education into schools for kids and i really like his perspective about um how to teach fundamentals of technology to kids instead of just making them consumers of

technology like how to actually make them creators of technology and i really like things he has to say about that uh mine would be uh grace hopper because uh well for a few reasons. Because she's everybody's. Grace Hopper essentially invented the compiler prior to her work on that. Nobody even thought that was impossible. They thought they had to talk to the machine purely in terms that the machine understood. And, you know, with, you know, what we would call assembler these days. And her colleagues in the Navy even told her, like, oh, that's not possible. It actually was.

So in a sort of proof by construction method, she made a working compiler, and then the language that she wrote eventually became COBOL. And one of my pet peeves is people attributing COBOL to her. No, no, no no that was the committee that picked up her work afterward that wasn't her fault so but yeah she invented

the compiler um much like simon peyton jones she was a very very charming personality there's some really funny and awesome interviews that you can find on youtube with her and um i just i don't think you could really hope for much more out of a pioneering contributor to CS. I mean, she did really great, important work that got us started on the right track in terms of, you know, designing and building programming languages instead of just, you know, not abstracting with machine. And she happened to be what seems to be a really lovely person too. Very good. So second question and final question for the day is what is on your open source radar?

So things that you may or may not have even played with, but has your interest peaked? If you had a free weekend, perhaps you'd go get clone this and check it out or read more on it. Maybe we start with Julie this time. What's on your open source radar? Well, I've been trying to make a Twitter bot

that does some really basic language analysis. And so analyzing people's tweets. And so I've been looking at the Chatter library in Haskell for, it's a, what? Sorry, it's fine. Go ahead. I was going to talk about chatter. That's why. Oh, you mean both of you guys have the same answer? He's well, he's helping me write the Twitter bot.

And so, um, because there's a lot about streaming that I don't know that I need to know for writing the Twitter bot. And so he's what? It's fine. It's fine. I'm. And so he's, so we both, so we've both been looking at chatter and really excited about, about that project.

Should we take that from the top? I think it's great having that, that kind of, I mean, unless it's a true fight, then I think it's cool. No, it's just,

I make facial expressions that throws her off. And I'm just like rubbing my forehead. Cause it's like, now I'm just going to talk about something really silly. Keep it. It's, it's just I make facial expressions and it throws her off. And I'm just like rubbing my forehead because it's like now I'm just going to talk about something really silly. I love it. Keep it. It's good stuff. She's on your radar, man. You guys just happen to have the same radar.

It makes sense. You guys are working on the same Twitter bot. Right. Well, that's why he got. I mean, that all goes back to why he brought me into Haskell in the first place is because we were both interested in natural language processing. And so now we're interested in this Haskell natural language processing library. I mean, it makes sense, right? It makes sense. Yeah. And specifically, so the Chatter library is on Hackage and it's by Rogan Kuesrich. And it's pretty cool. It seems to be the most kind of complete parts of speech analysis analysis library for haskell it has some pretty

good stuff in it um i have an interest in parsers too so one thing i thought i might do is uh use a different kind of back-end parser for it um another project i'm interested in i i may get the name wrong here and if so i apologize but there was a recent plotting library for haskell that was posted to the haskell subreddit recently called quick plot i think and um it really appealed to me because it kind of had the uh kind of the immediate satisfaction of using like gg plot 2 and r that kind of thing and um that would be something i'd like to hack on is get a chance to extend it maybe to using, um, Cairo like R does instead of, uh, instead of like a web app thing. Well, cool. That, uh, that is the, the tail end of the show here. It's been a fun time to take this journey with you. I feel like, uh, Jared and I in some

way have, have joined your effort to a degree with, uh, just talking through all this with you. It's certainly interesting to, to hear your dynamic between one another and then also just to kind of see this veil be pulled back to see how it is to learn Haskell, but also just to take a beginner's approach to learning programming, period, to see the pros and cons and all the ins and outs and the hurdles that can come up as part of that. But is there anything you guys want to mention as we close out the shows?

Anything else you want to, uh, quickly mention? Well, um, we are going to be at LambdaConf this year, which is in May towards the end of May. And it's in Boulder, Colorado.

Uh, we're actually going to be gold sponsors for it this year. Nice. And, uh, we actually kind of launched the book for last year's LambdaConf. So it's kind of nice to have that continuity. It's like a full circle, yeah. Yeah. And we're also sponsoring the childcare at LambdaConf because, you know,

I mean, Julie's a mother of two, homeschooling mother of two, and we feel pretty strongly about, you know, I mean, Julie's a mother of two, homeschooling mother of two, and we feel pretty strongly about, you know, primary carers of children being able to participate and be part of an open source community as well. Yes. And can I say something exciting? Yes. So I had asked the LambdaConf organizers if they had ever thought about having children's workshops with the conference since the kids are already there in child care and um and they agreed to do it so i am coordinating some children's workshops that'll be about um we're going to have a workshop for kids learning how to do sorting algorithms and some other exciting

things so i'm really really excited about it in addition uh for two days prior to LambdaConf, we're going to be offering commercial Haskell training because it's something that a lot of people have asked for some one-on-one time with us. It's beginner and intermediate commercial Haskell training for two days. And there's also, if you're only paying for yourself, if you don't have an employer covering it, we actually have a self-pay discount for that as well. What's the best way to get in touch if someone out there is like, hey, I wouldn't mind helping out with the child care part of that, Julie? How do they get in touch? If they want to help, you mean support it? Support it. Like if they have questions and you're organizing, how can people get in touch if they have some questions like how they participate, if they want to influence it, if they're going to be coming to the conference and they want to have their child go into that?

What's the process of interacting with you around what it is? Right. The best way is probably to initially send questions through the LambdaConf website. And then if there are specific things that need to get to me, then the organizers will send it to me. You can, I mean, anybody's free to reach me on, I need to have a public email address, don't I? Yeah. Anybody's free to reach me on Twitter,

but if you're not on Twitter, then through the LambdaConf is probably currently the best way to reach me. And then Courtney Degose, who's one of the organizers, will follow any questions that need to come to me to me. Good deal. I just want to make sure we give people a way to get in touch or at least mention something that makes some sense as a lead. So we have people out there listening like, hey, I've got some questions. Do you want to get in touch?

Yeah. as a lead so we have people out there listening like hey i you know i've got some questions they want to get in touch yeah put both of your github profiles and twitter profiles in the show notes this is episode 198 so for listeners listening to this this is episode 198 so go to changelog.com slash 198 or open up or look back at your phone if you're listening to this on your phone in a podcast app or something like that go Go to the show notes. We put all that stuff in there. Heroes, all the links we talked about in this show will be there. Again, episode 198. But Julie, Chris, it's been an absolute pleasure having you on the show today. Getting to learn all

this stuff we have with you. So everyone else listening, stay tuned. We have a ton of great shows coming up on the schedule. Some upcoming shows. We've mentioned schedule. Some upcoming shows. We've mentioned this one a couple of times. 20 Years of Ruby with Mats. We do have that scheduled.

It's a little further out than I thought we would have had. So we're really hoping it can be episode 200, but I don't think it's going to be. We also have a show scheduled with Andrew Contino on Huggin and also Raquel Velez talking about NPM, JavaScript and a bunch of fun stuff. So those are some of our upcoming shows. We also have a further out scheduled show with Jewelbots.

That's Sarah J. Chips and George Stocker. Great show there coming up talking about, yet again, kids in programming and influencing girls into programming. So, and also women into programming with girls because they do grow up, of course. But that has been the show. So everybody and also women into programming with girls. They do grow up, of course. Uh,

but that has been the show. So everybody let's say goodbye. Thanks for having us. Thank you for having us. Bye. Thanks for coming. Bye. We'll see you next time.