In this book club episode, the Rogues talk to Conrad Barski about his book, Land of Lisp.

Special Guest: Conrad Barski.

 
CHUCK:

I did finally figure out how to get the chat log to show up with the call going at the same time.

That is quite a trick.

That's what causing the echo. Chuck, you fool!

This podcast is brought to you by New Relic. To track and optimize your application performance, go to rubyrogues.com/newrelic. Hey everybody and welcome to Episode 43 of the Ruby Rogues Podcast. This week we are going to be talking about Land of Lisp with Conrad Barski. And so obviously on this week’s panel, we have Conrad Barski.

Hello!

You wanna introduce yourself really quickly?

Yeah so I work mainly as a Medical Software Developer. I’ve been working for a company called Walters Kluwer for a over a decade. It’s a big international conglomerate and nobody is ever heard of it. And they produce various types of hospital software systems. Before that I did way back in the day, a little work as a Atari programmer and also went to medical school. So I have kind of a strange route into programming. For some reason a few years ago or many years at this point although that doesn’t seem so long ago, I created a little cartoon tutorial online on Lisp programming called Casting SPELs. And one of the editors at No Starch Press liked it and they wanna do a Lisp book and so they contacted me and even though I'm completely unqualified to write any sort of academic subject like Lisp, they agree to help me write a book. That basically I got started on it. Lisp is kind of weird. They are really interesting stuff about Lisp is the more advanced stuff so I realized if I write a book on Lisp, it’s going to have to cover some advanced subjects or it will be kind of pointless because we’d read the book and it’s like what is the big deal. So I started on the book and then every time I finish a chapter, I would send it to my editor at No Starch and he would say, oh, no, you can’t move this quickly. You’re going to have to change this chapter and break it down into three separate chapters. So I thought like the Greek fable from (I don’t know what it’s called) where the guy is trying to catch the turtle and the turtle always lose half the distance again, away from him and so he never reaches it. I kind of felt like that with this book where the more I wrote the book, the further the end of the book would move away from me because my editor kept forcing me to make it simpler and simpler and slower and slower. And so it took me forever to finish it, but eventually it get to the end and ended up with the relatively fine book for programming book. But in the end it turned out well. People seemed to enjoy it.

So basically every time you would submit the book, you would had a function or a defun that actually submit the book with the cdr as the book and your editor would return a whole new car and the original cdr unchanged.

Something like that yes. So that's sort of, what's it called, “race condition”.

Yes. And for all the Ruby programmer out there who have no idea what I just said and think Conrad just made a racist joke, tune in next week.

Yeah I got to cdr the rest of our background.

Are we still doing intros?

Yeah I think we are, we’ll introduce the rest of the panel and then well start talking about the book.

So on our panel we have David Brady.

Hi this is David Brady. I don’t normally do intro. I just say hey, this is David Brady. But last week my stealth start up came out of stealth and I am co-founding Slide Rule Labs with JT Zemp. We are going to do a little consulting. A little product development and hopefully a little bit of corporate training.

Cool. We also have Josh Susser.

Hey good morning everyone. From now on we are going to call David Slipstick Brady.

Hehehe. Wait. What?

That's awesome.

Yeah the cdr of that one is “lipstick”.

Car is “s”. Slipstick, it makes me think of a Roman trying to put on makeup in the movie airplane.

Go read some Robert Heinlen.

Okay.

We also have James Edward Gray.

I'm being lazily evaluated for this podcast.

And I'm Charles Max Wood from teachmetocode.com and yeah, it’s kind of interesting to hear about how the book came about. I guess it’s a little bit different process from just writing from on a blog to write a book. A lot feedback, a lot of input.

Yeah. I was really happy with No Starch. I’ve never done anything like that before, I worked with an editor. It was kind of the right mix of letting me do what I thought was necessary, but also giving me some guidance. I thought it worked out really well. The main thing I wanted to do with the book is, it’s very easy if you are writing a book on a certain subject to just take whatever the specification is of that programming language or whatever and then say okay I’m going to take every paragraph out of kind of Lisp fancy spec and turn into a chapter or whatever and just kind of write top to bottom. And there are some Lisp books out there that I like and they are definitely useful as reference material. But what I really instead did was more difficult and hard to get right, is that I guess I tried to think my way from the beginning all the way through Lisp and just kind of free associated a little bit and tried to throw in some interesting aside and just try to sort of go naturally through all the material. A couple of people said that they thought it was a good page turner which I’ve felt proud of because that’s kind of what I wanted to do, just make it a fun to read and to figure out what is going to happen next.

I actually wanna comment on that page turner. It just so happens that I was reading two books at the same time and one of which being the Land of Lisp and the other one being a very dry manual. And I mean they are almost exact opposites of each other in that like Land of Lisp has the nice big font. It has comics, it’s entertaining and fun. This other book I swear it’s written in 3-pt font. The goal is to cram every single word on every page. It takes me like an hour to read a two-page spread and it was just so funny that I was reading both these at the same time because it was very, very big opposites. I’ve really enjoyed how easy it is to get into the Land of Lisp.

I have to second that. Conrad you don’t had no idea of this but, for me, the people who didn’t read the book and the discount code that we gave out at No Starch is still valid for a couple of months isn’t it?

Yeah, through June I think.

Seriously, if you haven’t read the book this is the best ad we can give you for the book. The subtitle is learn to program Lisp one game at a time. The book was a page turner for me because the very first programming book I ever bought, is still on my shelf it’s called Creating Adventure Games on Your Computer by Tim Hartnell and it was for the TI-99/4A computer.

(Woohoo!)

Oh yeah and the other program was also for a Commodore 64. It was back in the days when you had to target like three or four different basics and this took me right back. I was like, oh! Yey! I played where you fight the bandits. I played that way past the point of interest. Like my wife was like, aren’t you bored with this yet? I’m like, No. shut up this is my childhood.

Yeah it’s really weird because I initially started off the project by trying to figure out what the games would be that would be on the book. And the first game that I really wanted to do, as a kid a was a really huge Ultima fanatic, so I wanted to make a ASCII so the Ultima clone which I guess will be more described as a Rogue clone for most people. I started down that road and now I realized that there was a problem which is that, to have a sort of minimally viable NetHack or Roguelike, requires a lot of programming, enough going on that you can’t really break it into little chunks. I’ve seen a lot of books and what I don’t like is when they have a big program in the end and it made me go through six chapters or something and they say, okay, by the end of the sixth chapter you’ll be able to run the program. To me that doesn’t sound like fun. What I want to do is have the first chapter to already have some kind of fun result. Then second chapter should build-up that and I realize it isn’t possible with the Roguelike, so I had to come up with other game ideas. For instance at the end I have sorted a simple board game and now I painstakingly to figure out how to break into very small chunks where each chapter that discusses it ends up with a workable game at the end that just improves incrementally. And that was kind of a pain.

I liked the way that you also started into the description of the Lisp language in a way that gives people something interesting right up front. Just like what you did with the games. And I’ve been on a little bit of a kick lately looking at training materials for Ruby and object-oriented languages and it seems like most of them shy away from talking about objects and methods and classes until they have gone into all the procedural parts of the language and I find out it’s a little annoying. Like if you are going to talk about object-oriented programming you should start about objects and I liked that in talking about Lisp, you start with functions, which is the obvious place to start right?

Right. Although there has been some kind of criticism about that because the first example I give for game is you know, the old school guess my number game where the computer tries to guess your number. When I created that program, I actually used dynamic variables (which is essentially you can think of global variables) and they get modified as the game runs and of course that is a big no-no for functional programming. So why am I starting a Lisp book by having mutating state. But the problem is that I wasn’t really expecting with this book that complete novice would be reading it. What I expected is that people who have some familiarity with other languages are reading it. So if I get a simple en example, I have to give something that people are familiar with at some level and starting with just pure functional programming is kind of daunting for somebody. So it’s a difficult trade off and you kind of have to make a lot of weird decisions when you edit book in this type of style. Where you kind of have to decide, well, do you force people to you know, eat their vegetables or do you have something fun instead that maybe doesn’t teach the material as the direct a matter as you would like.

Well you can’t teach them everything at the start. You got to start somewhere. I think that your approach is just fine.

I actually kind of wondered if it wasn’t deliberate. It’s like, that's not a good functional programming! This is a Lisp book guys try to keep up. This is your cow, this is my altar, we are having sacred hamburgers.

That's definitely one advantage I had being that I have kind of an autodidact with this stuff is it’s not like if I write a crappy book like I would lose like ten year or something, because I have some credibility as an academic software developer or something. It’s like I could take some risks and do something that maybe people would think would be bad practice just because I thought that's how I would want to learn it.

There’s a really interesting you do in the book and it may have backfired or maybe it’s a testament to the fact that I actually took you so much at your word. But I actually put your book down and stopped reading at page 16. I was one of the people that lobbied for this book. I’ve owned my copy pretty much since you launched the website. I think I did the pre-order. On page 16 you have three little drawings. You have a drawing of rabid dog and you basically say this is Common Lisp, it has all the power and it will poop on the carpet. Then you have this fluffy little sheep and you say, this is Scheme and it’s pretty and it’s kind of like Dave Brady, can’t shut up right? It’s long big babbly rumbly bits and to be syntactically correct and then the third one is the picture of the rabid dog wrapped in the sheep’s fur like Hannibal Lecter.

(I loved that picture.)

And you are like, if you want all the power but the syntactical sugar, maybe you should learn Haskell. And I took you at your word, I put the book down and I spent like a week trying to learn Haskell and I’m like, this sucks! I'm going back to Lisp.

Well you know, there’s sort of one message that I would tell people listening to this podcast, it’s that it’s very easy to think if you’ve been doing programming in Java or Ruby or one of the mainstream languages. It’s very easy to think that you kind of know a lot of what is going on with programming and I used to be on that same boat. But then you find out things like Lisp and Haskell and you know there are other things like Erlang that are also interesting. But these languages, they really have completely new ideas that you would never think even about if you are using more traditional programming languages. If you can just spend a couple of weeks with Haskell or with Lisp, it really pays off and you will lean that even though Lisp is 50 years old, you will learn really mind blowing things that you would never would have thought of without having spent some time off with these languages. And the thing with Lisp was, because it was used for decades as a practical tool for programming and stuff back in the 80’s and 90’s. Common Lisp, (my main dialect of Lisp) carries a lot of baggage with it and it basically lets you program it in any way that you want to, because it’s very much a multi-paradigm language.

I was actually going to ask you some things about that. So, you chose Common Lisp as your dialect, how do you feel about there being so many different dialects of Lisp. Like they are all a little different, like David mentions Scheme which is basically the pure Lisp. Common Lisp is I think of it as kind of the gem thrower with absolutely everything you could ever want. While I was reading Land of Lisp, I’m was also messing around with Emacs quite a bit lately so I'm learning a fair bit amount of Emacs Lisp which is different still. I did translate some of the examples from the book. I didn’t have the time to get through all of them, but how do you feel about all the different dialects of Lisp?

The reason I point out Haskell is because it really is the extreme version. There is no compromise in the Haskell language. So if you wanna learn functional programming, it forces you to do it the right way, whereas with Common Lisp, you can get away with basically writing a Java program if you want. In terms of all the various Lisp dialects, the weird thing about Lisp is that, most programming languages was sort of built around the idea of a Von Neumann architecture back in the early days of any stuff. People were trying to figure out, well how can we make a computer do something useful and make it a little easier to program than just typing in all numbers. The weird thing about Lisp is that it basically came out of Mathematics because these guys, in particular John McCarthy was playing around with this thing called “Lambda Calculus” which is sort of a form of algebra where you have certain substitution rules. And with the Lambda Calculus, if you use the substitution rules, you can do something that are sort of basically very primitive programming. And he thought and then of course the obvious next step is, if you can have a primitive programming language, well, how hard it would be to write the Lambda Calculus in itself. And it turns out that was actually very difficult. So John McCarthy sat down and he said, well lets create a new language that is based on the Lambda Calculus that it has a few more bells and whistles and it makes it really easy to write an interpreter for itself in the actual language. So, basically Lisp is just a pure mathematical game when it first came out; a play using the rules of Math, its timeless. And because of that also, you can have many dialects of Lisp. And they are also Lisp, because if you use parenthesis in a way that all Lisp languages use parenthesis (which basically is a form of simplifying the syntax of the language making it easier to read the text of the language and figure out how to interpret it or compile it) if you have that, then you are a Lisp. So all these different dialects like Common Lisp, Arc, Clojure, Scheme, they are all basically the same language when it really comes down to it with only sort of minor differences and they are all Lisp. I'm definitely somebody who prefers things are a bit more elegant and take into account all the modern thinking in programming and so Common Lisp, because the design of Lisp in general is so flexible, you can actually do pretty much everything in Common Lisp that that you could do it with any of the other Lisps. But Common Lisp just has a million different features and a lot of them extremely obscure. There was never an attempt really to make it elegant. But then, specific people came around and decided, well let’s try to make something elegant out of it and the first successful attempt of that is Scheme, which is basically simplifies a lot of what happening in Lisp. And then the more recent, very popular take on that is Clojure. Personally my favorite Lisp right now is Clojure and it’s definitely a much more elegant than Common Lisp.

Am I understanding correctly that basically, you defined Lisp as anything where you write the abstract syntax tree the compiler?

Well yeah. I mean, it’s kind of hard to say exactly what Lisp is. But the thing that all Lisp languages have in common is, whenever you write a compiler or interpreter for a programming language, there’s going to be some kind of parsing process where the compiler or interpreter patches in the text of the program. Basically figures out what its internal structure is and basically the way that it’s usually done is that parser will generate an abstract syntax tree which is then turned into machine code or byte or something else down the road. What the Lisp languages has all have in common is that the parser is very simple; the reader as they call it. It basically just uses all parenthesis to figure out how the code is organized. And it has certain advantages, because you can it gives you an opportunity to under the hood of your interpreter or complier and there’s ways in Lisp to basically make changes to the abstract syntax tree at a very low level before it gets turned into byte code or compiled code. So that’s one of the subjects I covered towards the end of the book which is the macro system in Lisp.

I love that you said Lisp is kind of hard to say what Lisp is. I was totally expecting you to follow that up with Lisp is like I obscenity, know it when I see it.

Yeah kind of like that. I mean the weird thing is that you have things like Dylan which was a language applet created a couple decades ago and it looks just like a more common programming language, it doesn’t have a bunch of parenthesis. But it’s basically just Lisp under the hood, so the question is you call that a Lisp. And then you have of course there’s JavaScript which kind of odd because a lot of JavaScript is actually very similar to Lisp. I actually really enjoy JavaScript programming, I use CoffeScript on top of it but you can basically do what you do in the Lisp in JavaScript with some exceptions like macros. Although with enough effort you can do that too, but it’s not that practical.

So Conrad what did you think of Dylan? I'm curious because I got to --- on that project when I was at Apple and we basically looked at it as the Common Lisp object system sitting on top of Scheme.

Yeah, it kind of predates me a bit because I only really got into Lisp about 10 years ago. I had some glancing familiarity with it at the time but I’ve never written a Dylan program and I haven’t heard anyone say that, oh I should go back and do some Dylan programming. So I can’t really have an informed opinion on it. I think I certainly think that there’s room for that type of language.

Some kind of Lisp with a different syntax. Yeah, I don’t know.

Okay.

So Conrad I wanted to ask, you mentioned that to you, JavaScript feels like Lisp in many ways when I was reading through your book I actually I was struck by how you would refer to things and explain why they exist and I would see the influences that Matz would later take when he built Ruby in a lot of ways. I was surprised by how many things I saw in Lisp that made me feel that they definitely inspired Ruby. I think it’s Paul Graham that has the essay about how to use Lisp or how to get Lisp in somewhere that comes down to and if you can’t get them to use Lisp, use Ruby because it’s acceptable Lisp or something like that. Have you ever used Ruby?

Yeah actually I am part of the start-up called sypnosis.com that does the online medical visits. I was a cofounder on it although I'm not heavily involved on it at this time it’s still a company that's doing quite well. Its build on Ruby on Rails. In fact just before this call, we had an emergency where I had to figure out how load the file for database for Ruby on Rails project. So I have done some Ruby it’s one of those things. I kind of agree with Paul Graham. Let’s talk a little bit about what is it that Lisp innovated that other languages have borrowed. It comes down to a long list and of course some of these are also invented independently by other parties, but for instance the whole idea of being able to call functions within the function itself, (so having the recursive functions) came out of Lisp. Then you have things like Linked Lists, which are essentially the core of how you program in Common Lisp with the List functions is basically came out of lisp. And there are things like Dynamically Allocated Memory, Garbage Collection, was originally started in Lisp, then you have Functional Programming aspect. All unit Programming, Generic Functions, Dynamic Dispatch, Lexical Closures. There’s a bunch of things. You can even argue that XML is basically kind of stolen from Lisp because it works very similar to the way the actual syntax expression work in Lisp. So there are a lot of different things. One thing that comes to mind with Ruby, is that Ruby I believe has a concept of a symbol, where you can have a variable that evaluates to itself and that is something that also came out of Lisp originally. It’s kind of strange thing to think about why people find the set of syntax of Lisp with all the parenthesis so uncomfortable, because clearly there are people like myself that kind of like that syntax. But then for some reason that is always stopped the Lisp from hitting mainstream in a big way.

So Conrad, one of the ways I think about the difference between Math and Physics is that Math is discovered but Physics was invented. I sort of think of the same thing about Lisp. I think Lisp is more discovered than invented. Something like Java or object-oriented programming is probably more on the invented side of things. Just to hear you talk about all the things that came out of the efforts to create lisp, it’s like you are taking a deep dive into the mathematics of computation and discovering this whole field of things that are interesting there.

Right I mean another way you can put it is that, it’s the difference between simple and easy. So Rich Hickey who is creator of the Clojure programming language, he recently put together a presentation and you can look up online it’s called “Simple Made Easy”. He talks about how this two ideas are different and you know the basic gist of it is, something can be hard to learn but simple. When you use the word easy, you basically mean that it’s easy to learn, but that doesn’t mean necessarily that if you look under the covers that it’s all that simple. When you compare Rails or Ruby in general and you compare that against Lisp, I think that kind of applies in my mind at least that what Lisp does it is a little harder to use and to learn, but it’s actually pretty simple whereas the way Ruby works is that everything is designed to make things easy to learn and easy to use. So if you look for instance the web frameworks, Rails you have this idea of convention versus configuration. So the idea basically is, if you install Ruby on Rails on your machine, you pretty much have everything you need to create a website. And it’s very easy to create models and views and controllers to build a larger program out of it. But if you look under the covers and you try to understand how does Rails really work, there’s a lot of kind of ugly stuff going on under the hood. But that doesn’t necessarily mean that Ruby and Rails isn’t a great choice, but probably a better choice for some types of projects. And as I said from my own work I have used Ruby on Rails because if somebody is paying you to create an interactive website and you wanna get it done in the shortest amount possible, Ruby in Rails is a great tool to use. But Lisp and Clojure as specific example, the web frameworks that come with Clojure, they are much, much simpler than what you will find in Rails in terms of you can read the source code. If you are an experienced Clojure programmer, they are very simple and the number of lines of code is in order of magnitude smaller. That doesn’t have all the functionality that you get with Rails but it all makes sense if you look under the hood. It all is designed in a very clean, elegant way and everything is designed to just be simple and everything is set in the right way. No compromises are made to make it easier or to make it look easy from the outside.

Hey guys, this guy is officially the most dangerous guest we’ve ever had on.

Does Skype let you view other people?

I'm thinking about learning Clojure now.

We won’t be having any listeners tonight they will all be learning Clojure.

Yeah, ClojureCast.

Conrad were you saying Lisp is like Go? Go is simple, but not easy.

Yeah I mean it’s one of those things. I mean general relativity is simple but you know, it’s not easy. Go is kind of different because it being that its design to be a systems programming language. A lot of the stuff and functionality in Go is designed to help performance. They don’t have as many sort of high level constructs in there. I guess that kind of applies yeah I mean Go is based on a few fundamental principles that the designers wanted to have in their language and they were pretty ruthless about designing the entire language around those concepts. So once you learn how it works it’s all elegant as long as you accept the initial principles of the language.

So I have two listener questions that I wanna ask. Incidentally they are both from the same person here. The first one came in over Twitter and it says “It’s hard to modify Lisp code. I have to rewrite functions because I wind up in the wrong nesting level.”

I assume he’s talking about the issue of having so many darn parenthesis and if you use Emacs, there is something called “paren-mode” which is a mode that prevents you from deleting an open parenthesis without also deleting the closing parenthesis. And basically it does that for all possible operations so you always have matching parenthesis and then as functions basically for increasing or decreasing the depth of a form within those parenthesis. So that's a problem it’s very easy to get confused and get the parenthesis in the wrong place, but I guess the tip will be to learn parenmode. It actually works pretty well and it make sure you never screw up your parenthesis.

Yeah it seems like white space depending on how you use it might help a little there too.

Yeah I mean each of the Lisp dialects of course has certain indenting style. But the weird thing being at its Lisp, is that white space or new lines don’t really have any meaning. They do limit the tokens in your program but you can put new lines anywhere in a function that you want and it wouldn’t affect out runs, which is different in Ruby which is indentation delineated language.

You are thinking of Python man. Python’s indentation delineate. Ruby is not usually white space sensitive although there are some cases.

But the new line isn’t completely agnostic either. I'm not sure if I'm saying that right.

Yeah it’s used to end statements generally unless followed by certain operator and stuff.

I guess I tried to format Ruby in enough weird ways to fully know the answer to that but yeah I think you are right. Python is being more along the lines of what I'm thinking.

Dave Thomas has a good example of, you say it’s not white space sensitive but he does show a few instances where--

I love that talk.

Yeah it’s really kind of a fun one.

He basically goes into like Ruby and if I put a space here all of a sudden it’s a syntax error!

Well Ruby lets you use optional parenthesis and I believe that's where all the white space sensitivity comes from.

Yeah it will also let you prefix a number with a + so 2*3, new line, + 4 returns 4.

Alright so the next question is also from the same person, and he emailed me this question. It said, “Hey Chuck, I love the podcast and I really enjoy this Land of Lisp edition of the book club. It turned out to be one of my all-time favorite programming books” (I just wanna put that in there because someone else appreciates the book too.)

Awesome.

He says, “How to deal with complex data structures? I mean I get that there are lists and hashes and associative arrays and even objects via defstruct and that they are flexible and awesome. I guess what I'm driving at is domain models. For example the Dice of Doom game, code dealing with the game tree is constantly carring and cdring or some variation thereof. The same parts of the tree representing the player or the board or follow it’s moves. It’s difficult to keep track of what each of these represent, especially after jumping to another project for Chapter Two. I'm curious if this is something Lispers adjust to or whether they deal with this by leveraging defstruct a little more or if there is some other trick they use. I mean something like tree moves tree seems better than cdr-tree to me from a maintainability stand point.”

This raises a whole bunch of questions so the first thing one of the innovations initially of Lisp is that is has a equivalence of print and read. That means in Common Lisp if you use the correct print and read functions you can basically print out a data structure and then paste it back in and read it and it will be able to read it back in directly. Basically all the data structures or most of them are serializeable. Now the problem of course is when you start getting into structures or objects basically. You start losing some of that you know, because basically an object has a type, so that means if you print it out, the printer has to say oh, this is a point or whatever. Then if you load it in again, it will have to be smart enough to know that that's a point and order it in the right way. With record syntax, Common Lisp can actually handle but that it falls apart. The more types you give your data. So if you use full CLOS object-oriented programming, I don’t think it can print and read it anymore. So yeah, there’s a trade-off of what I'm saying is that the more heavily you type your data structures, that means essentially you are adding data to your data just what types are and that meta data, if you wanna print put you data structures, save them to a file and then load them back in again, that can get in the way. But on the other hand, it’s great to have perhaps types because then if you, like functions, then you can basically have it throw errors if you try to use the wrong function with the type that that function isn’t looking for. So with Common Lisp, that's definitely a criticism because with Common Lisp, a lot of the code is written off and just with straight lists. Then of course you have this extremely complicated data structures and in Dice of Doom that would be one example. I have a very complicated data structure that is actually infinite in length. And all you have are car and cdr to break it apart and it’s very easy to lose track of what piece you are breaking apart and wouldn’t make much sense to use an object in there. So yeah, I kind of agree with that criticism and I think that, if you do a lot of functional programming, which what I do in that Dice of Doom example at the end, it uses pure functional programming. Then, what you find is it’s very easy to break functions into smaller functions. Often that is not the case if you are not --programming often you end up with large objects that have a lot of functions and its harder to break them in smaller chunks. So, with functions it’s always easy to break them into smaller functions if you just make your data structures more complicated because you can always write a smaller function to pull out a little bit on the data structure. But what happens is that you are basically are cheating by hiding all of the complexity inside of large data structures. So, I think that's a valid criticism for my Dice of Doom is, yeah it’s great to have short functions and stuff but doesn’t it really matter if you can’t make the sense of the data structures anymore. And I certainly struggle with that when I do my own functional programming. Because you know, the traditional way to write a functional programming, you don’t wanna have to have a lot of mutable state around. What you usually have is you usually have this variable called the world or whatever that has all the mutable state in it in one very complicated data structure and you just kind of pass that around everybody. And that's sort of how you keep stake from ending up anywhere in our program but then of course the world ends up to being really, really complicated as a data structure.

So I got to say, as much as I like the book, my main take away about the book is that I really prefer object-oriented programming. There’s a lot of beauty in functional programming and I know that it applies to a lot problems pretty nicely but mostly when I'm modelling the real world object-oriented programming is just a better approach for me.

Well I think it’s true. In many cases like take a person for instance right? So if I have a person and lets say I wanna change their last name because I got married. The way I basically do it is create a new person that has a different last name and then I kind of swap the one out for the other. You can argue that's not really how the real world works. In the real world you only have one person. So wouldn’t it make much more sense to go in and then modify that person’s last name as an object? I think in a lot of cases, you can make that argument. A lot of things in the real world very neatly thought of as independent objects that have state in them. One big example of that is UI programming. So if you have a Lisp box it’s very easy to think of the Lisp box as being an object that has a list of items in it and functions that lets you work on that list of items and events that let you work with that list of items. And that's definitely an object-oriented programming idea and I'm doing some JavaScript programming right now where I'm dealing with list of items and I'm writing the JavaScript program entirely in a functional style. So I really have no concept as a Lisp box objects. The code that deals with that Lisp box is fed over several areas of my program because there is no central home where I say this is where the Lisp box code is and there plusses and minuses to that type of approach.

Yeah I tend to find it in the long run that its more minuses because of my history and all that. I'm not going to say that other people can’t make that work for them that's fine.

This feels so weird in backwards to have maybe saying this but Josh, be nice.

You are right that was very awkward.

We’ve entered bizzaro world now. We’re restraining Josh.

Conrad, I would try to redirect to a different area here. So we know that you know Lisp, Common Lisp, Clojure all that. You mentioned you are using JavaScript to Ruby. I believe you mentioned Java in your music video for your books. So, it’s clear you have all this language training and yet its Conrad Barski M.D. am I correct?

That is correct.

I’m sure that's a wonderful story.

It’s really quite simple. I did well academically in high school and college. As I said back in the day I was a working for a contractor for Atari if anyone remembers the Atari Jaguar. I was a developer for a game for that called Flip Out If you go to YouTube you can see some Flip Out videos for the Atari Jaguar. It’s not that impressive now looking back at it. So you know, at some point I faced this choice. It’s like, okay am I just going to be a computer programmer? or do I wanna sit in the cubicle all day and program or do I want to do something that is a little more exciting maybe? And go on medicine where you do kind of a larger variety of things than just always sitting in the cubicle and I liked that idea and so I went to medical school. There are certain things that you don’t really learn about things like medical school without having gone through it. So what I found out is that just in terms of my temperament, I don’t really make a very good doctor because I tend to be somebody, I like to be able to think through. I want to be able to sleep through a problem and then fix it the next day. Even though medicine is definitely something that for a lot of areas of medicine that you kind of have to be able to think on your feet very quickly, which isn’t really my temperament. Also the thing you will find out about medicine it is actually frightening how little we understand about how the human body works. A lot of the things in medicine are really not thought well backed by science. Its more tradition and you learn everything is kind of figured out empirically and you basically have to memorize ridiculous numbers of things to be a good doctor. I'm somebody, when I was in college and I took Physics, I would just look at few of the basic formulas before the test and it’s like, Oh, I can sort of see the big picture here and see how all this fits together and all this other formulas. Obviously this derived trivially from the main five formulas here and I don’t have to memorize all the other ones. They are obvious. Medicine is exactly opposite to that. Every little in fact has no real logical reason why it’s true. So we’re all at memorisations. So, I just found out at the end of the day that I really like programming and just now I think I'm starting to get back in medicine because of we are working a product for my day job detecting sepsis in hospitals. Doing early sepsis detection. So now I'm kind of getting into reading up on what's known about sepsis and try to understanding the medicine behind it. One of the things that makes us all programmers is that we are all probably very good at obsessing about some problem where are working on and I

always had that with computer programming and just now I'm starting to get that a little bit with medicine where I can obsess over particular medical puzzle and if you don’t have that, if you can’t get obsessed with things like that you are never going to be as good.

So yeah it sounds like you used your medicine in your programming several places. Like I know you mentioned earlier some kind of medical tracking thing that you'd worked on and I believe in the description in the book that mentions you working on cardiographic software or something like that I think.

Yeah Cardiology Software. It’s kind of interesting that what you find as a cardiologist after they do a heart operation, it’s really hard to describe heart operations in words, so what they actually do is they photocopy pictures of the heart and they stick them in the patient’s chart and then they draw on colored pencils to explain what they did. So part of the system I worked on is basically coming up with the drawing program for cardiologist. So, I can kind of draw it in my video game experience to work on some of that. But that was pretty fun.

Well we need to get into the picks.

Hang on Chuck, I got one more really important question.

Yes sir.

The most important question we’ve asked the entire episode. Conrad, did you purposely name the book so that it shortens to LOL?

No it was just something I realized afterwards.

A happy incident.

Wait we got to ask Avdi’s question for him.

I don’t know how to ask Avdi’s question.

So Conrad, Avdi has a funny question and has a real point, just put something in the Skype chat window and Avdi wants to know how to pronounce that and for the listeners ill spell it its “c-a-d-d-ad-a-a-a-d-d-a-d-a-a-d-d-r”.

So I have no idea. Until the podcast, I didn’t even know how to pronounce cdr.

I remember hearing the word cdrdar a lot

Yeah I’ve heard that one. But for those people who don’t know, essentially what you are doing with Common Lisp you are essentially working with something that's link list and it might be a link list where basically you are having little boxes and each little box has basically two pointers in it. One pointer of that points to the next piece of the list and the other pointer that points to the chunk of data that represents the data that's in that part of the list. So, Common Lisp that actually defines up to five or six levels deep, all these weird functions that basically, get the second item out of the list that's stored in the third item on the list. So those kinds of operation, getting the first amount of console which is what this little box is called the car and getting the second item, which usually points to another list is in the cdr. They string together this weird functions where they have a’s and d’s in their long list in order to extract some deep piece of data.

I think this comes from contents of address register and contents of data register which instructions on the machine that they were building Lisp on at the time.

Yeah although I also had heard that somebody else thought that that was too convenient an answer and that the truth was somehow more complicated than nobody really knows where the names came from.

I first heard that story many years ago.

Yeah I heard that described as being myth but I don’t know.

So Avdi’s point behind this question really was teaching Lisp using all of the weird little crafty names of things that have aggregated, what is it, accreted over the years, he was saying that he likes the perspective of you teaching Lisp using semantic words that are understandable like first and rest, you’re talking about a list. I guess if you are programming in Common Lisp, you need to have the actual names. But, did you think about that when you are writing the book about how obscure some of the names were versus how approachable they were?

I thought about that endlessly. One good example is, actually in the first and second chapter, I used a function I believe that's called “ash” which is I think it’s a right shift function and I keep having people ask me why in the world did you use this function and not even the most Common Lisp programmer have ever heard. And the rationale for this is actually really mundane, which is the obvious way (because I'm doing something that is sort of like binary search, where I always have to take the distance between two numbers and have it and come up with an average), so the obvious way to come up with an average of course is to just add the numbers, divide by two and then round it off or do a for operation. But the problem is, the round and for functions in Common Lisp are really helpful because they actually return two values. They return your rounded number and they return what the remainder was. If you try to divide the number three by two in Common Lisp and then round it, it will actually in the console will print two numbers. The first one is the rounded number and the other one is the remainder of one, which is perfectly fine because then you pass that result to another function, they will actually just discard the second value. It’s called “multiple values”. Common Lisp supports multiple values. If the function is not aware of multiple values, you will just not even notice that the extra values exist, but the problem is if I get that in the programming example, you are going to see all this weird stuff showing up in the console as your developing the game (because I do everything interactively in the console) and so it will be very confusing to see that. So, I used this shift operation which shifts the bits over and basically that does an averaging and a rounding at the same time. But it also has a nice effect that it doesn’t return multiple values and then multiple values are covered in some later chapter. But I didn’t wanna cover those in Chapter Two. There are all kinds of excruciating decisions I have to make like arguably, you can argue I’ve made a weird choice but it’s my book, if you didn’t like the choices I make then write your own book.

Go ahead. I dare you.

-- slightly vindicated though because I had to fire up Emacs and use the function look up to figure out what the ash function did so, yeah.

It’s an arithmetic shift right? It comes right at the ash.

Yeah that makes sense.

It’s actually interesting that Common Lisp and Scheme both give you the four levels deep of cdaar, cardadr and cddarddar and the first 2 or 3 times I tried to learn Lisp for Scheme, I thought four levels is not enough. So I would write this file called caddadaaaddadaaddr that had all the combination all the way up to 10 levels deep and I basically ended up with kind of without the same level of depth understanding, that you reach with Dice and Doom with all the using caddadaaaddadaaddr to get to things, instead of writing functions instead of saying hey I actually want to get the die roll of this land piece of this here. After about 2 or 3 attempts of this I finally concluded that if you need more levels than four of caddadaaaddadaaddr , you are doing it wrong and you need to start putting some semantic meaning on what you are doing. I like when you put it when you put semantic meaning on it, you are kind of freezing your data structure a little bit.

If you Structure and Interpretation of Computer Programs, SICP which arguably one of the better Lisp book than mine, it talks about that very question and what they suggest is that you can always, when you have any kind of data structure, you should always write functions that operate on that data structures and then use those functions and never use data structures in their raw form. That way if you ever later on want to change the data structure, you don’t have to search through your whole program. It’s kind of a crude form of encapsulation like you would have with object-oriented programming. You can certainly do that. I don’t know if you remember these old books 101 Basic Programming Games or whatever back in the day which is kind of what my book is inspired, but of course if you write like a chess program in a hundred lines of basic you are not going to be able to on those hundred lines. It’s going to be gobbledygook. But you type those in and you can enjoy that experience of playing chess in your computer. That is kind of how I read this book and that I wanted to make sure at the end of each chapter there some fun little game that you actually program that was reasonable in size, maybe only 50 lines of codes or something that you can play around with. I do some compromises to make that possible by not using the most elegant programming techniques. And I would say that there's definitely things in my book that are bad programming practice if you are writing real software, lots and lots of them. I mean, typical example is there is a case I used eval and what eval lets you do is it basically lets you run a piece of data as if it’s a piece of Lisp program. Of course, anyone who is familiar with the internet security knows how dangerous it is. Like when folks try to do SQL injection attacks on databases online where they put in a bit of SQL code inside of a username or something. You never want to take the user’s input and evaluate it as a program. But you can sure make some nice games if you take advantage of those kinds of features.

I would say in defence of your horrible programming practices that I own a copy of Land of Lisp and I own a copy of the SICP book and I have not finished the SICP book.

Alright. Well that being said, I think we really need to get into the picks because we are over an hour now. So we’ll go ahead and get started so Dave what are your picks?

I had a pick an d I mentioned in in the pregame everyone screamed and I don’t know if I should just use a different pick or just go ahead and with it. I’ll tell you what I'm going to do. I’ll give you my pick but I'm not going to explain it. A friend of mine and also a listener of the podcast sent me a book called “The Kama Pootra” 52 mind blowing ways to poop and I have been convulsing with laughter looking through this book it’s basically a whole bunch of pictures of ways you can get on the toilet inventively (I said I wasn’t going to explain it and here we are). That's my pick.

So let me get this straight. People send me the hate mail and you get gifts?

I'm not sure that's true. No seriously this book has positions with partners, position with toys. The cell phone poop is in here so there is a proper technique. Oh and as my second pick, Conrad I need you to settle an argument between me and James that isn’t really an argument. The function to iterate over a list of pairs and select one based on the first one, this is an associative array, the function, I pronounce it as “ass-ock “ and James pronounce it as “as-osh” how do you pronounce it?

Again I have never in my life heard anybody that ever say that function out loud so I have no idea.

You just program in silence!

But I’ve definitely pronounced it “ass-ock”

Woohoo!

(Nooooo…)

I have to say “as-osh” sounds a little more of a sensible now in hind sight.

What did you say Josh you have another one?

I put the --- on the second syllable.

So Conrad, don’t say any of this out loud. Do you treat Lisp like the names of god? Like take the vowels out of things when you write them?

Well I guess you know as I said I'm kind of a lone wolf. Nobody in my company is really into this kind of stuff so I don’t really spend that much time conversing with other Lisp programmers. So I don’t know how things are pronounced necessarily.

That's awesome.

That means you get to make it up. Assoc, its pronounced “lisp”. Alright James what are your picks?

I'm all business this time around. First, I have this Inventing on Principle video which I assume basically every programmer in the world has seen at this point. But if you have not then you are absolutely bound to go watch it. It’s some of the most amazing rethinking of computer interfacing ever. So you absolutely have to watch it because it makes you dream of the commuters of tomorrow. So that's cool stuff. Last week I took Marc-André Cournoyer’s class on writing your own programming language and he's really great. Really, really great. Its two days he really starts down on the basics. Writing up lexers all the way up to runtime, interpreter, compiler. You learn about garbage collectors, compilation, I mean there’s exercises. He does his presentation there with other people and working together it’s just a total blast if you are into that kind of thing at all. So I couldn’t recommend that class enough. There’s another class called “Owning Rails” where basically starts from building Rails from scratch to teach you parts of Rails and I probably would take that one in the future because I enjoyed the first one so much. Mark, if you don’t know him he is the guy that wrote tinyrb and he has a book “How to Create Your Own Programming Language” but he’s probably best known for “Thin”. He made the Thin web server for Lisp. Anyways those classes are awesome and I can’t recommend them enough. My final recommendation is, I’ve been needing some themes just websites designs and I didn’t wanna go through a designer this time. It’s not that important to have a designer on every single project I don’t think. (I'm sure I’ll get hate mail for that too). There’s nothing wrong with using a stock design and if you want a stock design, the best place in the world to get it is ThemeForest. They have tons of stock designs that usually has lots of elements in them, so you can pretty much take them and customize them as you need to. It’s like this super handy resource when you need to put together a webpage. So those are my picks.

Alright. Josh what are your picks?

Okay I'm going to be rather practical this week. I got an email from Paulo San Gregorio. (Hey I’ve done the podcast achievement of mispronouncing someone’s name on air. Cool.)

Is there a Facebook badge for that?

Yeah. So I got an email from him telling me about their new applications for the iPhone and iPad which I checked them out and they are pretty cool. There are two apps; one is for Ruby and the other is for Rails and they are basically taking the documentation, the online documentation for these and packaging them up as apps. So it’s nice if you are not connected to the internet, you can read the stuff and navigate around in it. I think they are going to have to evolve the UI just a little bit. Some of it is a little clunky for iOS but it’s a really good start and it’s nice to have this stuff in your pocket sometimes. You know for bar conversations about just what the active record API is.

Cool.

So there’s apps.pandalab.it and we’ll have the link in the show notes.

How many bar bets have you won using that?

Josh wins all bar bets.

I don’t need these apps to win bar bets.

That’s right.

I’m saying for other people.

These apps are the referee. Oh yeah? Well it’s this. You wanna look it up? Check it out.

Okay, I’m done.

Alright, so my picks, I have two picks. The first one is Appsumo, they have all kinds of deals. It’s kind of like Groupon except it’s for web people. So they have stuff for coders, stuff for designers, and all kinds of stuff. They have information on SEO, I mean, I’ve seen all stuff come through and I bought some of those stuff, gotten some deals on books, just stuff like that. So, that is my first pick. And my second pick is something that I have been involved in for a little while now and what it is, is a community around marketing and it is something that I have really benefitted from as far as kind of beefing up my marketing as I go. The thing that I am focusing on lately is actually been my email newsletters and the group are called “The Third Tribe” and they just reopened registrations again last month. (They closed it for like 6 months or something and anyway they have twice weekly Q&A webinars that you can just call in to and listen to and then on top of that, they also have a forum where you can put questions in and get answers to and interact with other people. And like every month they have one or two sessions that you can get on and they talk about a particular topic. So the last one was actually on building your mailing list, you know, getting people in, building things out so people are getting what they want from that, getting them involved and then using it as a marketing tool for your products. That has been really educational and helpful, so if you are looking at running your own business or looking at building products and selling them, this is really a super way of getting involved and getting that going. They just give you a ton of information and you almost kind of have to pair it down so that you only focus on one thing at a time and that’s kind of what I do. So, lately it’s been that email stuff and then I’ll probably get in to some of the other topics that they have there and you can go and get their entire backlog of recorded sessions so you can go back a year or two and listen to all of their Q&A stuff and apply that to what you are doing. Anyway, both pretty handy, one has saved me money; well I don’t know if Appsumo has really saved me money. I might have spent more money than I would have spent otherwise but you know just handy stuff there. So if you are looking for stuff like that then go check them out. Conrad, did we warn you about picks? Do you have anything you wanna share?

You sure did. My programming pick, so anyone who’s written any migrations in Rails, I’m sure they’ve had the thought at some point in their head where they think, hmm, basically the forward and backward migrations are the same thing except that they work in reverse. Couldn’t you create some kind of program that just generates the backwards migration from the forward migration? And of course in certain cases that wouldn’t work. If the forward migration that deletes rows then obviously you can’t recreate them in the other direction but not surprisingly, computer scientists have thought about this problem and there are actually certain types of programming languages called “Bi-directional” programming languages. And I recommend reading up on the bi-directional programming languages. One example is this language called “Boomerang”. And so basically the example program that they used, they convert browser bookmarks from one format to another and they actually just write the program once and it just converts from format A to format B and when they are done they could just push a button and it can automatically go to the other direction too and create format A from format B. So I think that is really cool and I can see a lot more happening in that direction, because to me it makes sense in terms of user interface. You know, when you are talking about a view in a model in MVC architecture, in a way the view is just a transformation of the data inside of the model. So wouldn’t it be great if you can just write codes that generates the view of your model and then if the user interacts with it, the program just automatically figures out what change will be necessary in the model to have that happen. So I think there’s probably stuff happening with that kind of idea in the future. For my non-programming pick, I’m going to recommend a book. So I don’t really read a lot of non-fiction and I’d say mainly that is because I tend to like fiction that has sort of a science fiction or sort of fantasy stuff in it. But I also don’t like reading things that are really realistically written because I just can’t get that suspension of disbelief unless somebody really took the time and makes the characters believable. One book that I have been recently reading falls into that category is called “1Q84” by Haruki Murakami. So it’s a Japanese book and it’s basically sort of a magical realism book with really great character development, very realistic and believable. It’s over a thousand pages and I’ve been cheating. I’ve been doing the audiobook actually, so for you podcast listeners, if you wanna add that to your Audible.com reading/listening, you can pod your podcast with extra material that way. So that’s something I definitely would pick. And one thing I was really impressed with, with the audiobook was the effort that the narrators use. There is one page in the book where there is basically a whole text about where a person sings a Bach sonata or something and they had to hold German text, so it’s like a page long and the narrator actually goes and he actually sings the entire like, sonata in German at that point in the book. Those are my picks.

(Awesome.)

All right.

That is way cool.

You know what, nobody does programming audiobooks.

Oh, Yeah.

Wouldn’t it be great, you get in the car and there is like def foo receives x,y.

Car accident ratio would go up Dave.

Yeah I was thinking about that with JavaScript and it will be like function foo (a,b) {

Is this the audio version of literate programming?

Have you guys seen that hilarious video where there is a guy I think he is programming a Perl using like Dragon Naturally Speaking or something like that? It’s hilarious.

I just realized Conrad is probably old enough to remember sitting at an old 8-bit computer and typing while your friend reads to you from Byte Magazine.

(That’s awesome.)

I don’t know if I ever done it with two people, but I could certainly see how I could have save some time with that approach.

Well it does not save time.

That is my problem. I didn’t have the friends.

Alright, well let’s wrap this up real quick. A couple of business items, first off you can get the show notes at rubyrogues.com. You can find us in iTunes. Please leave us a review or rating, or both and that should be it. We’ll catch you next week!

Can we mention the next book club?

(Do we know what we’re--)

Yes we do; the one that won second place in the last vote. It’s “Crafting Rails Applications” by Jose Valim, right?

Yup. Do we know when we are doing that yet?

No we still have to pick a date but it’s about a month from now.

Yeah, a month or two.

Yeah we need to coordinate that particular date with Jose.

Okay. So we’ll figure that out and we’ll let you know.