Marco Sampellegrini, Author of The Simple Haskell Handbook: Learn how to build Haskell applications

Len: Hi I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast I'll be interviewing Marco Sampellegrini.

Based in Milan, Marco is a software engineering consultant who works with startups and founders on everything from product development to cloud infrastructure.

You can follow him on Twitter @_alpacaaa and check out his website at marcosampellegrini.com.

Marco is the author of the Leanpub book The Simple Haskell Handbook: Learn how to build Haskell applications.

In the book, rather than focusing on theory or formally teaching the programming language, Marco takes readers through the process of building something practical in Haskell from scratch.

In this interview, we’re going to talk about Marco's background and career, professional interests, his book, and at the end we'll talk about his experience using writing and self-publishing a book.

So, thank you Marco for being on the Leanpub Frontmatter Podcast.

Marco: And thanks for having me.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you first found yourself becoming interested in computers and programming and software?

Marco: Sure. I was born in a town near Milan in Italy. I come from a working-class family. So there wasn't a lot of tech going on in my home. And one thing that I specifically missed in my teens was an internet connection.

I remember going through high school with all of my peers, chatting and spending their time in whichever social website was popular at the time, and I felt left out. I felt like this great invention that was he internet, was kind of not available to me, and that really felt bad.

Eventually when I was 17, we got an internet connection, and that's when I started going down the rabbit hole. My interest wasn't specifically in programming initially. I was explicitly fascinated about the internet and the fact that we had this global worldwide network full of things, full of interesting things. But you couldn't point at exactly one place where those things lived. To me, that sounded completely crazy, and I wanted to find out more about it.

I started building little static websites with - I think it was FrontPage and Dreamweaver, those kind of programs back then. There was free website hosting back then. The one I used offered like 20 megabytes of space, or something like that. So that's where I started publishing my first toy websites.

The thing I realized is that - static websites are cool, but I want to do dynamic stuff. I want to build a forum. I want to know how people deal with users posting messages, and users logging in and sending emails, and all of that stuff. That's what triggered my interest in programming, really.

That free webhosting offered support for PHP. That's the language I eventually got to learn. I loved PHP, I loved dynamic typing. I felt like I had superpowers. It was really, really fun.

When I finished high school, it was kind of a no-brainer for me to get a job and do this kind of stuff full time. I wanted to get my hands dirty and learn as much as I could about programming.

I've done a few years in web agencies. I would take on projects that would last maybe a month, maybe three months. And, yeah it was really, really fun.

After that, I was kind of craving for being part of a team. During my time in agencies, I would be the only developer on the team. Or it was not common for me to share a codebase with another developer. I really wanted to know what it was like to work with other people, and I wanted to learn from them as well. That's when I started looking into startups, and maybe working on a product in more of a long-term fashion.

In agencies, products came and go - came and went. It was great, because every time I could start fresh, and I could apply the knowledge that I gathered from the previous project. But it also meant that I never faced the problems that you face when you have to maintain an application for years, and there is a team working on it, you're not the only person working on it.

I joined a startup. It was a pretty big startup in Milan. It had a pretty big team. In fact, there were multiple teams within the company. And, yeah - that taught me a lot. It showed me that maybe PHP and dynamic typing isn't the end of it all? It became apparent to me that, even if you had a lot of tests, things break all the time anyway.

That's when I first got a hunch that maybe there was something to static typing, and maybe languages such as Java weren't all that bad. Up to that point, I absolutely hated stuff like Java, because of the verbosity and the types. I couldn't understand why people would go through all of that added noise, when you could just do the thing you wanted to do in languages such as PHP. And, yeah - I could go on, if this isn't too boring.

Len: No, no - it's very interesting. Actually just before you go on, I was wondering if you wouldn't mind explaining the difference between static and dynamic typing. Because the non-programmers listening might think we're talking about like keyboard typing.

Marco: Sure. in a dynamically typed language such as PHP or JavaScript, you go about writing your code, and you don't know whether it's going to work or not. You can't prove anything about the code you've just written, until you run it. The usual workflow is that you start your application, and you refresh the page or you run your test, and you find out if there is anything wrong with it.

Whereas, with a statically typed language such as Java or Haskell - there is a compiler. You get an extra check for a program that tells you, "Hey, this thing you wrote here doesn't really make sense." It could be a dumb error like using a string where an int should have been used. Those errors are really trivial, but it's still useful that a compiler catches them for you.

But in Haskell in particular, the compiler gives you a lot of room to express your domain and your problem in a particularly explicit way. When you get down to modeling your domain using union types and stuff like that, you get more guarantees about how your program is going to behave, and whether it is correct or not, even before you actually run it.

Len: It's really interesting. It sounds like there's a sort of correspondence in your path, and the kinds of programming languages that you use. Because - I didn't know your origin story before you just told it now. But you were very independent, it sounds like. Not only in your choice to be interested in the internet and in programming and things like that, but you just started creating your own web pages; without going to university or anything like that, you just got jobs. then those jobs were alone. You got to be what many people would've loved to be, having the privilege of doing things on your own for so long.

But eventually, realizing that actually maybe working with other people - or I imagine - things like legacy code and things like that, start to become more important.

I wanted to ask you a question. This comes up on this podcast relatively frequently, where I ask people - if you could've gone another way, would you have preferred to have gone that way on the path towards the same career? For example, and I'm sure you get this question from time to time - do you regret not studying Computer Science formally in university for a few years?

Marco: Yeah, so - I don't regret it. As I said, my family wouldn't have had the means to support me in such an endeavor. Which meant I would have had to get a job anyway. Now at that point, I think I would have just burned out after not even a year. Most importantly, I didn't find it interesting. And this is something - I was very stubborn at the time, and naïve. I still am, to a certain extent. I thought I knew better, and I could learn the stuff that I cared about on my own, or with the help of forums and strangers on the internet.

But at some point- one thing I think is really - going to university really helps you if you want to move abroad, specifically in the US. At some point, I tried to get a visa. It wasn't even a long-term staying visa - it was a two years, I think, visa. It got rejected specifically because the officer didn't think I had the skills needed to perform the job, which came down to not having a degree. That was the first time I realized, "Maybe it would've been worth spending the three years or five years to get a Computer Science degree?"

But other than that, in the last couple of years - in the last three years, I'm realizing that - how helpful a Computer Science - sometimes I'm lacking the foundations, I feel like. All of the stuff that I skipped over and glanced over in the beginning - it started to come out as I approached more and more complex projects. It's not like it's a big gap. I feel I can fill in the gaps as I go through. But it would've been fairly interesting to study, maybe, distributed systems, or studying compilers, early on in my career.

I don't regret not going to university. Especially, I don't regret because if I went in university in Milan, I wouldn't have learned those topics anyway. It's not like going to MIT. It is what it is. I, overall, I don't regret it, now.

Len: Thanks very much for sharing that. I always find it very interesting to hear about people's decisions that they made along the way. Of course when you're young, what do you know? There's always a little bit of accident to everything that happens. To hear people talk about whether or not they would've wanted to do it differently, is always just really fascinating. Usually the answer's like, "Of course not, I'd be someone else if I'd done things differently."

So, there you found yourself going from being very independent all the way along. As you said, it sounds like you learned a lot just by getting Dreamweaver and using it, and banging away and being stubborn - then meeting people online in forums and things like that. But so - then you found yourself at this - it sounds like a relatively well-funded, big startup. You had to work with teams, and basically writing code that other people would be using and sharing. I was wondering if you could pick up the narrative again from there?

Marco: Yeah - so I wasn't ready to give up on dynamically typed languages yet. But at that point I started to have a feeling that maybe there was something to statically typed languages. With that being said, I switched off from PHP, but I landed on JavaScript, so it was pretty much the same deal in terms of typing. That was about the time when JS was starting to get big, and React entered the scene and was becoming big as well. And, again - using React and Redux in particular -

Again, I was confronted with things and concepts that I heard through over the years, but I didn't really investigate. Immutability, or the fact that in Redux you have to have a single source of truth. All the flow of your application must go through a funnel, if you like? All of this data's centralized in a single place. That was a way of thinking about my application that I never had before.

It didn't occur to me that you could model things this way. It didn't occur to me that you could do useful stuff with an immutable language, which JavaScript obviously is not. This all felt like playing with a toy, but not getting the actual good stuff. So if you add that to the statically typed fonts that I had before, I started really looking for a language that could check all of those boxes.

Haskell came up. I couldn't understand any of it. It was full of strange stuff, strange operators and greater than equal signs everywhere. It didn't make any sense. Even reading a few pages of tutorials over at blog posts, they were full of terms I never heard of. So I felt really dumb at that point.

But I wasn't ready to give up. Fortunately, I came upon Elm, which is the language that inspired Redux, I think? It was related to the React world. Elm clicked. Elm was really very simple. It didn't have all of the big terms that I read about when looking into Haskell. It was a slow process, but I managed to pick it up. I felt like it was a really great choice, and it was great to deal with - it was great to finally experience what it meant to work with a language with these features. '

So, I managed to land an Elm job. I would do Elm most of the time, and a little bit of Elixir as well. I was the person that knew Elm better in the company. This was a company that was really willing to bet on Elm, and Elixir as well. But I was interested in the Elm part.

So we started building a lot of applications. We started to become more proficient with it, and to understand more about static typing, and how to model our domain correctly.

All the while, I kept an eye on Haskell. I wasn't willing to give up on it.

I picked up some books, and slowly but surely I finally could understand a little bit of it, and write little programs with it. As long as I kept my programs looking more like Elm, than they did Haskell - they seemed to work properly, and I seemed to be able to understand them.

After this experience with Elm, I wanted to replicate it with Haskell. I would just get a job where I'd get to write Haskell full time, and I'm sure I can get better at it.

I moved to London and worked for Habito for a couple of years. That's where my brain really exploded. That's where I managed to learn a ton about functional programming and Haskell, and all the math behind it as well. That's something that I ignored completely up to that point. I met some exceptional people. I want to conferences. It was really, really great.

Len: Thanks very much for that. It's funny - long time listeners of the show are going to know that my next question is going to be selfish, and it's going to be - where did you live when you were in London? I lived there for a few years myself, and I lived in a few different neighborhoods. One time I actually had a guest on, who was at that very moment, living in the first neighborhood I lived in when I moved -

Marco: Oh wow.

Len: In Balham.

Marco: Nice.

Len: I was wondering if you wouldn't mind taking a moment talking about that? Because that's something that actually quite a few people who've been on the podcast, have had that experience of moving from somewhere to London.

Marco: Yeah. My neighborhood of choice in London is Wapping, which is just next to Tower Bridge. I love it. It's a very quiet area. There is a nice canal in the middle of it. A lot of people that I met completely disliked it, because there is nothing to do there. But I loved it precisely because there is nothing to do there. It's quiet, there is the nice river walk. It was close to work. I could get to work in less than 15 minutes on foot, which was great.

Len: Yeah. Ultimately I ended up making that decision for my last job in London - the most important thing to me became being within - yeah, about 15 minutes walking distance. I'd just had too much of the Northern Line. Which I gather is a lot better now than in my days. And of course walking in London is just a pleasure in itself.

Marco: It is.

Len: So you found yourself in London. Then, I guess you eventually returned to Milan?

Marco: I did. That was just before the pandemic. you mentioned for sure that you wanted to get into this.

Len: Yeah.

Marco: Maybe this is a good time.

Len: Yeah.

Marco: It's February, 2020. I hand my resignation for the job London. I plan to take six months off, maybe travel to South America, and take some time for myself. I still have my apartment in London until the end of February. My plan was to come back home in Milan for a bit, and then depart to wherever I decided to go. But I come back at the end of February, and some big family issue came up, which meant I wouldn't be able to leave soon, because I have to take care of this.

But also, a week later - ten days later, at the beginning of March - Lombardy, my region here in Italy - gets the worst outbreak after what happened in China. So it was really crazy. I was pumped to live and I was pumped to take some time for myself and travel around and backpacking, and be done with technology for a while. But I seem to have left just before all of this broke off.

Len: You would've been like severely locked down for quite some time.

Marco: Yeah, exactly. Milan wasn't in great shape, especially during the first lockdown. I think as developers we have - and I'm talking to developers in the audience, maybe there are other people as well - but as developers, we are quite accustomed to being in a closed space and closed environment for hours on end. It didn't affect me too much. I could still walk outside because I'm - as I said, I'm not exactly in Milan, I'm in a small town near it. There wasn't exactly police going door to door, making sure that you wouldn't go out. So the occasional walk around was allowed here, because there's nobody to get in contact with.

But yeah - it was tough. It was tough seeing other people being affected drastically by this. But somehow - now the situation is pretty good, as it is in a lot of countries around the world. We're getting our shot, like our jab of vaccine, and restaurants have opened up. I think this week gyms and cinemas have opened up as well. There is an atmosphere of optimism, for sure.

Len: So you suddenly found yourself with a lot of time in an enclosed space on your hands that you weren't expecting. What did you end up doing with your time?

Marco: I almost forgot to mention - I ended up writing a book. That wasn't even my initial plan. My initial plan was to record a screencast or some video course. Because I think the book that I ended up writing would have been much better suited in a video format. But as a non-native speaker and as a person that hasn't ever recorded anything in their life, I realized that it would've taken me - it would actually take me three hours between recording and editing, to produce three minutes of decent quality video. That was just too much effort for me.

At one point I thought, "Well, maybe if I have a script that I could follow, then the process would shorten a bit. It would be easier to record these videos." I started writing the script for my videos and including the snippets of code that I would have to write in the live-coding recording session.

That didn't really help. It still took me forever to record short bits of video. But looking at the script, like and reading through it - I realized that, "This could work on its own. Maybe if I package it nicely and I format it nicely, it could be its own thing?" I also really enjoyed writing it. I enjoyed writing the script much more than reading it out loud, and typing out the stuff that I wrote.

So the script became really the book. It was the seed for what became the book. I'm really glad I spent that time working on a personal project. It was - in the past few years, I had in the back of my mind that I wanted to produce something that I could call my own. I wanted to work on my own product, be it a software-as-a-service business, or an actual product, like a book or a video course. I wanted to make something of my own. I'm really glad, in a sense, that the pandemic forced me in front of a screen, and allowed me to complete this project.

Len: That's such an amazing, an interesting story. It's funny, in the publishing world, there's been this phenomenon of COVID books, basically. Not about the pandemic, but as a result of it. To the point where even more than usual, publishers are like, "Ah, enough. We've got enough submissions," and stuff like that.

But it does take a lot of time to do a book, and it does - just to talk for a moment about videos. That's actually come up on this podcast in the past, because so many of our guests are content creators themselves. Definitely, it can take three hours to produce three minutes of good video. People do talk about - if you want to produce an hour-long thing, you might want to have a week available to do that - especially if you're doing your own editing and all that stuff.

In particular, another issue with videos, is editing them later on, if something changes. It's really impossible. Because recreating the space you were in, the moment you were in - if you're recording yourself, what you look like. Things like that. If all of a sudden for 30 seconds, you're tanned it's echo-y, people can tell that you spliced it in. So, although videos are amazing resources for training and things like that, they really are a ton of work.

I think it's funny. A lot of people will probably be like, "Well, a book doesn't sound so easy either." It's not. But it is definitely the case that - editing a typo in a book, or changing a sentence in a paragraph, is a lot easier than doing it in a video.

Moving onto the subject of your book The Simple Haskell Handbook Just before we dive into the book itself and the concept of Simple Haskell, which actually - it is a concept unto itself. It doesn't just mean like "Simple Haskell" literally.

I was wondering if you could talk a little bit about what Haskell is. I watched a couple of talks that you gave preparing for this, and I've had a few Haskellers on in the past. You talk about how Haskell was designed for three purposes. One was to teach functional programming. One was to experiment with basically Computer Science concepts. The other one was to build things.

Marco: Yeah.

Len: I was wondering if you could talk a little bit about its history, and then move into what your concept of Simple Haskell is.

Marco: Sure. First of all, Haskell) is a fairly old programming language, compared to other mainstream languages. It is, I think, 31 years old this year. So it is natural for it to have accumulated a ton of stuff, just because it has existed for this long.

It was born in an academia setting. It's purpose was to - as you said - teach functional programming to students, but also to advance state-of-the-art language research. It was really meant to be used as a tool or as a playground for language researchers to explore new avenues and come up with new ideas, new techniques in the programming language space.

Which meant that the compiler is really a very complicated beast, because of this. Because when a researcher or a - somebody doing their Ph.D. dissertation - they would hack in the compiler and create their own extension, to suit their needs. To introduce this new, novel concept that they're working on, or that they're studying - so that the compiler can be able to understand it and work with it.

But even before going there - Haskell is unique, in terms of programming languages, because it's pure and lazy. We don't necessarily have to get into what that means. But you have to rewire your brain a bit in order to use it, if you're accustomed to traditional programming languages. It's functional, opposed to object-oriented - which most other programming languages are. It's lazy in the sense that it will refuse to do anything until it is strictly necessary for it to do it.

This comes with great benefits in terms of being able to express things such as infinite lists, which can't exist in traditional languages. Because you can't - we don't have infinite memory. So a traditional programming language would just go out of memory, if given an infinite list.

But it also comes with its own set of problems, because it is sometimes difficult to predict how a Haskell program is going to behave, performance-wise. You often hear people complaining about space leaks, which means - you were expecting this tiny little program to use a constant amount of memory, and instead it's growing exponentially for some unknown reason.

So, yeah - Haskell is very old. It's more than 30 years old, and has been used successfully by language researchers. But at some point through its history, it also has picked up interest in industry. People who build real-world applications wanted to use it to build their software. It is amazing that it managed to serve both crowds equally well. Language researchers haven't stopped using it to push the envelope forward. The industry hasn't stopped either.

More and more companies are getting on board and using Haskell in one way or another. This is great. Except that as I was saying in the beginning, we have a very complex beast in our hands.

It might seem like you have to know everything. You have to know all of the extensions that are in the compiler, even though some of them haven't been touched forr ten years, or maybe have been introduced 15 years ago, never to be spoken of again.

But they're there. As a beginner, you don't know whether they're going to be useful to you or not.

The other issue with extensions is that it's very difficult to predict how they're going to interact with one another. You can pick and choose which extensions you want to enable in your program. But you might have bad surprises, because the compiler is going to break in unpleasant ways, can I just say that? you will come up with errors that are not really helpful, and nasty stuff like that.

My aim with Simple Haskell was to say, "Look, if you're a beginner or an intermediate developer looking into Haskell, there's only a subset of core stuff and features that you have to care about. If you want to use other stuff, that's fine. You can read about it on your own, and it's all good. If you understand it, then by all means bring it in and use it. But if you have no clue where to start - this is the core set of features that I think is very productive, and I think can be a good jumping point for teams that have little experience with functional programming, to start using Haskell successfully."

Len: Yeah, and it's a really interesting thing - convincing a team to take up a new language is a very difficult thing. Because there's so much risk involved, right? In fact, most programmers will probably enjoy the challenge. "Oh wow, isn't that great, I get to learn something new. It's going to make me a better programmer." But there's often someone sitting on top of it, with a responsibility to deliver. You have to explain to them, "There's going to be a bit of a lag in our productivity while we take this on." Then, actually we're steering our ship in a totally new direction software-wise. That can be a really big challenge - being able to explain,not only how Haskell is going to be beneficial, but how you're going to be able to train people up in it - is really important.

Marco: Exactly. This goes both ways. One big part of my argument was - I was actually arguing for the opposite. I think a lot of Haskell applications, we see a lot of complex code and fancy types. I like to call them that, because they're fancy and they make you look smart - but they don't necessarily bring a lot of benefits to the application.

This is subjective, and a lot of people will hate me for saying this. But a big part of my argument is that these advanced features are giving you only marginal benefits, compared to the simpler version of the same program. They are actually building up a huge wall between you and the rest of the team. Because you might be able to understand that stuff - but you're cutting off the junior developer, or even the experienced developer that has years of experience in another language, but couldn't translate that in Haskell, because you have decided to buy into all of these advanced features.

Len: You're also presumably locking in the company you're working for - assuming you're working for a company - to only being able to hire people with that level -

Marco: Exactly.

Len: Of understanding going forward.

As you say, there's a bit of subjectivity to it. That's not necessarily proof that you shouldn't go down that path. But that you should understand that there's a cost to adopting what you call "fancy types," and being aware of what that is. That reminds me actually - you've got a project, I think it's your project? Called Zero Bullshit Haskell.

Marco: Yes.

Len: Which is a bit more aggressive than saying, "Simple Haskell." But it's funny, because it reminded me actually of something. There's a philosopher named Jerry Cohen, who I happened to meet years and years ago. He had a project called, "Marxism Without The Bullshit." I don't know how familiar you are with Marxism. But basically the suspicion was that what he was really after, and his fellows were after, was Marxism without the Hegel. I mean it just - there's just a bit of a correspondence I saw between like getting rid of the philosophy and the obscure terminology, and just boiling it down to "What are the actual like analytical purposes for which we're adopting this, in this one ideology?"

Marco: Yeah, and again - I think this - it's important to say that this is only the first stepping stone. It's only to get your feet wet. It's not like you can't - you can go your whole career without studying the theory, and without getting into the more advanced stuff. But it's really helpful, I think - especially for a person like me.

As I said, I've always been very practical, and I never had time to read big explanations and read huge chunks of documentation. I wanted to be shown early on why something was the way it was, and why it worked, and why I needed it. So my effort with No Bullshit Haskell was that, like, "Show me why I care? Why should I care?"

Len: As a pedagogical approach, I couldn't agree more. It is true that often people have a difficultly - unfortunately some people's mindsets just have difficulty understanding that things are going to be expressed differently, given the stage of the intended recipient, right?

My brother's got a joke, that - when people always say, "Oh, that's economics 101." iI's like, well you don't have to actually teach at a university for long, before you realize that everything in 101 is a lie. Because it's the first stage along the way, right? You can't give them the end result, which is, "Everything's up in the air and contested." In 101, you're going to learn, "Everything works this way. We've got it figured out. Here are the simple rules." It's like, "Ah." But you have to go through, you have to go through that.

Marco: Exactly.

Len: Typically you have to go through that. It's just a stage along the way.

So, specifically - you've written a book for people at the first stage with Simple Haskell. This isn't necessarily people who have never programmed before, or something like that. It's people who it's like, "You want to get to know Haskell, here's step one - read my book." If I gathered correctly what your purpose was.

I was wondering if you could talk a little bit about how you structured the book, and what someone can expect to gain from it if they read it?

Marco: The book is very hands-on. It's based around building a real-world application. In the book, we get to build a continuous integration server. Which, for the non-technical people - it's something that as developers, we use every day. It's meant to build our projects, and get them from our local machine to production, if you will? It isn't going to be a fully-featured, fully-fledged continuous integration server - but it's going to have quite a few features that I think are interesting, and it has an interesting architecture as well. With a client server architecture and main server, and multiple agents deal as well. It's built around Docker, and it's inspired by Drone - which is a very popular CI server, and hence the name "Quad," as a tribute.

What people can expect from the book, I think is - to see like firsthand what it's like to think in Haskell, to think functionally about a problem. How to model a domain in a functional way. How you get from zero lines of code to a working application - without involving a ton of theory, and a ton of big terminology. In fact, I tried really hard to not put crazy terms in the book, like monads and stuff like that. Even though they're not -

Len: I was timing it. It took us about 45 minutes to get to the "m" word in a Haskell podcast.

Marco: I wish I didn't say it now. But yeah, those are things that you get to use, but you don't necessarily need to know you're using them to be proficient with it. It's like putting a label on a pattern that you've been using on and on again.

I think it's more you're supposed to know - deep down, you have the pattern down. You know that this is an abstraction that comes back over and over again. It's not necessarily useful to label it as a monad. That's going to just carry you, and make you realize that you don't know the actual definition of what a monad is, and which laws it should abide, and stuff like that.

I tried really hard to keep the theory out. There are great books out there if you care about that stuff. if you want to learn Haskell from first principles, that's the main book people are referring to when somebody wants to get into Haskell. I read it myself. It was 1,200 pages long when I got it, and it was incomplete. Maybe right now it is even longer.

It's a great book. I remember the part I liked the most in that book, it was a little section in the middle of the book - where the author went through building a small application from scratch. There was this little chapter building - I think it was a URL shortener, so a very tiny project - but still incredibly enlightening for somebody like me, who wanted to know, "Okay, now how do I use all of this stuff you've been telling me about for 600 pages?"

So, you can think of my book like that section expanded to a fully-fledged book. I like to think that all the theory is nailed in other books, in other resources. But then when it gets to the practical stuff, you can refer to my book to actually see the workflow, and the tiny tips and tricks that a Haskell developer would use on a daily basis, to build a real world application.

Len: Just moving onto the last part of the interview, where we talk about your experience writing a book and things like that. I guess my first question would be - why did you decide to choose Leanpub as the platform to publish the book in the end?

Marco: I saw different options. I'm not sure if I'm allowed to name other competitors, similar platforms. But like -

Len: Totally. Although, just - the only qualification I would say is we try to be nice about everybody. But it's okay to say whatever you want.

Marco: Cool, cool. Yeah, so my initial thought was go with Gumroad, and just host the landing page or the book page on my website, and just have a tiny button that would go to Gumroad, and have readers purchase it there. But then I realized that there's a friction in the buying process. So I personally don't have a Gumroad account, and I personally would be at least a little bit skeptical in putting my card details in their thing. Not because it's a bad service, but at least here in Europe, it's not that common to buy stuff off of it. It might be different in North America. I think it's more widespread over there.

But the biggest reason is that it seemed Leanpub had a big section on Haskell books. So I thought, "Most people who are going to be interested in my book, probably already have a Leanpub account and they already have their card details linked up. So, the purchase is going to be much - there's going to be much less friction in purchasing it." Yeah, just leveraging the network effect, I think of a platform like Leanpub, where there seem to be quite a lot of quality Haskell books.

I realize that it might not be the answer you were looking for. I used very few features of the platform itself. Although, if I were to do it again, I would probably leverage the platform a bit more. I would collect email addresses and use the discussion forum, for sure - to share the early drafts of the book.

But I didn't use any of that. I came to Leanpub with a almost finished product. I'm glad I went with Leanpub, because it turned out to be a great platform.

Len: Thanks very much for that. One thing I should say is that - and I'm actually looking forward to asking you specifically how you created your PDF file. Because that's something that - we save this for the end, so people who aren't interested in learning about self-publishing don't need to listen to it. But people who are interested, really like to hear about the details of how people went about doing it.

Your book is very nice, so I'm curious to hear about that. One thing I should mention though is that we actually don't save payment details on Leanpub. But one of the advantages for people with Leanpub accounts, is that you've got a Leanpub library, right? So there's one place to go for at least one collection of books that you've bought. So, maybe yours is next to Sandy Maguire's or Chris Penner's, or something like that. That's actually one of the things that's really, that is actually really handy.

The other thing is that Leanpub makes it really easy to update the book. Regardless of whether you're using it - as you are - as you mentioned, you're using our bring your own book writing flow.

You're not writing your book using Leanpub tools, you're writing it using your own tools. But you can then still easily update. If it's a major update, you can send a message to anyone who's opted in to hear about major updates. We've got coupons and you can add arbitrary digital content like code and things like that. There are a lot of things. If you're writing - basically if you're writing a technical programming book, we've just got a lot of extra things around it. But yeah, we don't save payment details.

Marco: Yeah.

Len: And so how did you make your book? Did you use Word and play around with formatting? Did you use something else?

Marco: I used Vim, which is -

Len: Okay.

Marco: Yeah, for non-technical people, it's one of those weird 80s-looking editors that you use from the terminal of your computer. So, my book is really a huge Markdown file, which I then turn into a PDF through a set of somewhat complex phases. There's a lot of scripting involved. I couldn't explain, to be honest, what the whole process was. But there's a lot of parsing Markdown to understand what the headings are, in order to create the Table of Contents. There's a script to stitch together the different parts of the book - the cover, the table of contents. Then there's the introduction, which is a separate Markdown file for some reason. There's yet other scripts to format the chunks of code in a nice way. There is quite a bit of CSS to render the page nicely.

Then, at the end, there's something that turns this giant HTML file into a PDF. I've got to say, I'm pretty happy with how it turned out. It took me quite a bit of time to nail this pipeline of glue code and scripts, and put them together. Maybe it would have been wiser to just stick it into Leanpub, and have you guys generate it. It would have been certainly less effort.

Len: Thank you very much for that. It's really interesting actually. You're not the first Leanpub author to have devised their own process. A lot of the way Leanpub works is actually - from over the years, from talking to people just about exactly what you just described - and learning from authors how they solve their own problems, and then trying to bake that in, to some extent, to the way Leanpub works. But, yeah - using someone else's process, there's always a bit of a trade-off, right? if you really want to get things exactly the way you want, you do it your own way.

Typically, like Leanpub model would be - while you're writing, try not to worry about formatting. It's impossible, at least if you have a mindset like mine. But like, try not to worry about it.

Then, when you're done writing, you do your formatting. That's actually one of the reasons that we have the "bring your own book" writing mode - is that you can actually write in a Leanpub mode, and then when you're done, if you want to, you can actually hand it off to a professional book designer or something like that. Then you can upload the resulting files, but professionally designed, and things like that.

But, thanks very much for sharing that process. If you ever wrote a blog post about it, I bet you'd get a lot of people interested in hearing about what you did.

Well, Marco, actually - I guess it's been close to an hour that we've been talking, so just to wrap things up. The last question I always like to ask, if the guest has published something on Leanpub is, if there was one magical feature we could build for you, or one terribly annoying thing about Leanpub that we could fix for you - can you think of anything you would ask us? Other than storing payment information, can you think of anything you could ask us to do?

Marco: I actually consider that a feature - I've worked at places where payment information wasn't exactly stored in a sensible way. I'm glad to see companies not doing that, because then there's no way of screwing up. But yeah, I don't have any major complaints.

One thing I remember annoyed me just a tiny bit was the embed feature. You guys give a chunk of HTML that you can copy/paste on your website, and then a widget comes up with information about the book and about how to buy it. I remember being annoyed, because it had a single layout. It has a vertical layout, if I remember correctly. I wanted it to be horizontal. I think a vertical layout is really difficult to fit in a traditional webpage. If it had been horizontal, I would probably have put it on my website page. This is very, very minor and there are ways to work around it. But I think it's a nice improvement for little effort.

Len: That's very interesting. I'll make a task and we'll discuss it, probably actually just later today in our next development meeting. Because - no promises or anything like that. But actually, the moment you mentioned it - yeah, the vertical embed thing just does seem really old school. That's a bit anachronistic now, and people like their 16 x 9 type -

Marco: Exactly.

Len: ...things. I'll talk about that with the team today.

Well, thanks very much Marco, for taking the time of what I'm sure was a beautiful evening in a small town near Milan. Thanks very much for being on the podcast.

Marco: Thanks for having me, it's been great fun.

Len: Thanks.

as always, thanks to you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.