134 RR Sharktime with Lucas Dohmen

00:00 4716
Download MP3

01:51 - Ruby Rogues T-Shirts!

02:22 - Lucas Dohmen Introduction

11:03 - ArangoDB

12:35 - Graph Databases

17:31 - Computer Science Education

29:18 - The Halting Problem

32:45 - Lucas’ Other Projects & Open Source Code

36:51 - exercism.io and exogenesis

45:46 - Functional Programming

53:28 - Haskell and Functional Programming Resources

Book Club

Functional Programming for the Object-Oriented Programmer by Brian Marick! We will be interviewing Brian on December 18th, and the show will air on Christmas Day. Oh! And here’s a $5.00 off code to get the book:  please_remember_the_starving_artist So, Merry Christmas!

Ruby Rogues Parley

Sign up for our Discourse Discussion Board!

Ruby Rogues T-Shirts!

Support the show! Buy a T-Shirt!

Next Week

HTTP 2.0 with Ilya Grigorik


DAVID:  Okay. So, Charles and James are not going to be joining. So, I'm going to hang up on them. AVDI:  Finally, we get to hang up on those guys. DAVID:   Yeah. We get to do Rogues our way. [Laughter] AVDI:   But I don’t know what my way is. DAVID:   Yeah. [Laughter] DAVID:   Crap! Our way is to have Chuck and Josh and James have a list of questions ready to go. AVDI: [Laughs][Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.] **[This podcast is sponsored by New Relic. To track and optimize your application performance, go to RubyRogues.com/NewRelic.]**[This episode is sponsored by SendGrid, the leader in transactional email and email deliverability. SendGrid helps eliminate the cost and complexity of owning and maintaining your own email infrastructure by handling ISP monitoring, DKIM, SPF, feedback loops, whitelabeling, link customization and more. If you’d rather focus on your business than on scaling your email infrastructure, then visit www.SendGrid.com.]**[This episode is sponsored by Code Climate. Code Climate’s new security monitor alerts you immediately when vulnerabilities are introduced into your Rails app. Sleep better knowing that your data is protected. Try it free at RubyRogues.com/CodeClimate.] **AVDI:  It’s the Ruby Rogues podcast. This is episode 134. Today, we have Katrina Owen. KATRINA:   Hello. AVDI:   And David Brady. DAVID:   I just want to be on the blooper reel. AVDI:   I am Avdi Grimm from RubyTapas.com. And joining us on the panel today, we have Lucas Dohmen. LUCAS:   Hello from Germany. AVDI:   So, I think we have a little tiny bit of business to get out of the way before we get into the episode. DAVID:   Oh, yes! We have some awesome business. AVDI:   Awesome business, yes. We finally have t-shirts. DAVID:   Woot! AVDI:   We've got a limited run of…I think it’s a limited run, right? It’s a limited time thing anyway. T-shirts, you can get them at Booster.com/RubyRogues and they're pretty awesome looking. I think we’re all pretty happy with the design that we wound up with. And yeah, go get them before they run out. So, our guest, as I said, is Lucas Dohmen. And he’s here to talk about a bunch of different stuff. But let’s talk about the backstory here. About, I don’t know, a year or so ago, we had a little contest. David, can you fill us in again on what that contest was? DAVID:   I had this horrible idea, like two years ago, to run a Ruby in a Tweet contest for the Ruby Rogues listeners. I asked all the listeners to write in the coolest thing you could do in Ruby in a single tweet. And it was a horrible idea because we ended up getting a hundred responses and then we had to judge them. Never start a contest if you're not willing to just judge all of the entries because it’s horrible. I know, I know. Cry you a river, right? But some of the responses that we got were just fascinating and we judged on various criteria such as how astonishing was it, how cool of a thing was it, was it really useful. And then, we kind of had a fourth category for just how much surprise and delight was there. And Lucas is @moonbeamlabs on Twitter and he submitted two entries. And one was a complete working To-Do List app which was mind-boggling. And the other one was this little animated ASCII art called Sharktime where this little ASCII shark eats a swimmer. LUCAS:   [Laughs] DAVID:   And it is way more fun than it has any right to be to be point that I keep Sharktime in my bin folder on my workstation so that I can run it any time that I feel like it’s Sharktime. And I run it easily once a month just because something awesome will happen. I'm like, “Wooh! It’s Sharktime! Let’s go!” This has been very happy. You’ve made it into my permanent toolchain. AVDI:   So, yeah. I think [crosstalk] said that whoever won this challenge will get to join us in the show. And so, here we are much belatedly but… DAVID:   So, this was like what? Eighteen months ago? AVDI:   [Laughs] DAVID:   You said it was May of 2012. LUCAS:   Back then, you said that you would judge us in like episode so and so. And then, the episode came and nothing happened. And then we asked over, I think, the Parley was on Google Groups back then and we asked, “Where is the announcement of the winners?” And there was the problem that it wasn’t easy to find all those entries because Twitter had kept all the number of tweets you can find with a certain hash tag. [Laughs] DAVID:   Yes. By the time we got around the judging, Twitter was hiding some of the evidences. So, we had to ask people for links to their own tweets again. [Laughs] LUCAS:   Yeah. It was kind of a little delayed, I think. And the other winner was on, I think, four episodes ago or five episodes ago. DAVID:   Yeah, Erik. LUCAS:   Yes, right. DAVID:   So, actually what really happened there is that behind the scenes, I went to Avdi and Josh and Chuck and James and said, “I think some of the participants are German and they get really wound up about punctuality. So, how about we wait for like eight months before we can [inaudible].” LUCAS:   [Laughs] DAVID:   And they all thought it was just a great idea. LUCAS:   Yeah, sounds like a great idea. DAVID:   Yeah, here we are. Here we are. LUCAS:   [Laughs] So, the Sharktime one, this wasn’t ASCII art. I drew it back in school, then we explored ASCII arts and this was one of the first ASCII arts I drew. And when the golf contest came up, I thought, “Maybe you can animate this.” And the first version, it really didn’t fit into a tweet. So, I golfed it down step by step and after a while, now it works. And now it can swim and eat a swimmer. So, it’s kind of awesome. [Chuckles] DAVID:   It’s kind of fun when you take something that is like, you shrink it down as small as you can and it’s like 400 characters long. And you're like, “There is no way this is going to fit into a tweet.” And then you start using side effects and you start binning things down and you start lowering resolution of your solution and that sort of thing. I remember what inspired me to suggest the golf contest is that I had been at work the previous year and I had been exploring Mandelbrot fractals. And I realized that I had figured out a way to express the Mandelbrot fractal in 300 characters. And I started talking to people about, “How can we shorten this? How can we shorten this?” And I got it down to like 134 characters which was enough to get it into a tweet and I published it. And people ran it. It was just a text version of the Mandelbrot fractal because it was all done in the console. And people started replying to me and said, “Oh, you list this optimization.” And within 24 hours, people had it down to like 108 characters. [Chuckles] LUCAS:   Yeah. At the To-Do List, the version that’s on Twitter, we optimized it on a user group here. We sat down with three people and we shaved off like eight or ten characters from the current version. So right now, it’s even smaller. [Chuckles] I think that there are a lot of dirty areas in Ruby which you can use in such a situation. And in normal situations, you don’t want to use those things because they are kind of ugly and they don’t make your code really beautiful or awesome at all. But if you are to golf, then it’s really nice. I think there's even a program language called Golf Erlang, I think, which is just done for golfing. AVDI:   [Laughs] DAVID:   That’s awesome. AVDI:   Isn’t it called Perl? LUCAS:   [Chuckles] Probably yeah. DAVID:   Or J-Lang? LUCAS:   Yeah. J-Lang is crazy. There was a golfing contest at a conference here, a local conference. And there was a special area for those people doing J programs because they are so ridiculously small because everything is just random characters. [Chuckle] LUCAS:   And no one can read it and it’s kind of short. DAVID:   Everyone else at the golfing contest, they have to fit their submission into a single tweet. Everybody at the J-Lang golfing contest has to fit their submission into a username. [Laughter] LUCAS:   Yeah. That would be fair, I think. DAVID:   [Laughs] AVDI:   Lucas, you're a pretty busy guy, aren’t you? LUCAS:   Yeah. AVDI:   Because I've seen some of the stuff that you're doing. LUCAS:   Yeah. I'm doing kind of a lot of stuff. I don’t think I sleep a lot which is not healthy. I'm working for a company in Cologne which is called triAGENS. And we are doing an open source NoSQL database that’s called ArangoDB. And I'm part of the core team there. That means that I'm doing stuff on the database itself which is mainly in JavaScript for my part because there's a V8 engine running in there and all the stuff I do is in JavaScript. But because I love Ruby, I also do the Ruby driver. So, everything Ruby-related for ArangoDB is done by me. And I'm also studying Computer Science. I'm getting finished with my Master Degree right now. So, [inaudible] most of time consuming things I do right now. KATRINA:   You also mentioned some local activities. You run a user group, did you say? LUCAS:   Oh, no. I'm participating on different user groups but I'm not running any user group. But I run a website for local user groups, so it’s easier for people to find a user group in the city. It’s an open source project that’s community-driven and you can just go to the site and see, “What can I do this evening?” Currently, it’s running in two cities in Germany - in Cologne where I live and in Berlin where a friend of mine lives. And in both cities, if you want to find out what a nerd can do today, you can just to the website and find out. AVDI:   You mentioned you're working on a database. ArangoDB? LUCAS:   Yeah, right. AVDI:   I'm curious about that. I ran across it, mentions of it a few times but I never really dug into it. What are the things that make it stand out from some of the other offerings out there? LUCAS:   The first thing that you will see which is different from other database is that it combines both the document store and the graph database. So, if you take Mongo, for example, and you want to model how people are connected, it will get a little bit awkward because there are no joints there and then you have to work with references and so on. And we decided that it would be a nice combination if you could also do the things that you can do in a graph database because a graph database is really good in connecting certain entities. So, you have documents. For example, you have people and they have certain attributes and they can be nested as in other document stores. But then you can adjust in another collection which can, again, have different attributes. So, they could be -- if the relationships are friendship, then you could set the intensity of the friendships to a certain number, for example, on the edge because it’s a normal document. And then you can model all the things that you could do in a database like [inaudible] and saturate off of the database. DAVID:   So, a graph database sounds -- I haven’t played with them a lot. I’ve touched them a little bit. And the way you’ve just described the graph database, it sounds like it’s a way of doing SQL relationships in a document store right up until you said you could weigh the edges and that makes it sound like you could do a whole lot more. And I'm aware that you can do a whole lot more with a graph database but I kind of want to hand this one over to you. What are some of the crazy awesome cool things that you can do with a graphing database? Or a graph database, sorry. LUCAS:  So, back in university I worked, I did chair there and I worked for people that do network analysis. And they used an Oracle database and DB2 and we had to do graph analysis on those data. So, I have written some crazy SQL statements to analyze graph data that’s stored in a relational database. And it’s not a lot of fun because you have to join a lot and then you have to do recursive joins and so on. And it gets really messy, really fast. And if you look into the source code of those projects we did at the chair then you will see a lot of cursing in the comments at each line because everyone just goes crazy after the third join. And if you have a graph database, there are ways that you can articulate what you want to know from the database in a more distinct way. Because you can, for example, just say, “Okay, I want a path of an arbitrary length between two people,” or, “I want to know which people,” if we take a social network because it’s the most simple example, I think, you can say, “Okay, how many people do I have to ask until I reach David Brady,” because there are friendships in the graph. And then I can ask Tom and then Jerry and then I will reach you. And I have the shortest path to you. And if you managed to do that in an SQL database, it is possible but it’s a lot of pain to implement it. DAVID:  Wouldn’t a good graphing database, if you tried to reach me through the shortest path, wouldn’t it automatically raise an error saying, “Why would you want to do that?” LUCAS:  [Chuckles] Yeah, it probably should. DAVID:  Okay. LUCAS:  It’s dangerous. DAVID:  Yeah. LUCAS:  Yeah, we haven’t implemented that feature yet. Maybe we can add it to the list. DAVID:  [Chuckles] LUCAS:  Thanks for the input. DAVID:  Yeah. To be fair, I don’t like systems that protect the user from hurting themselves. LUCAS:  [Laughs] DAVID:  So, that’s fair. [Chuckles] LUCAS:  Okay. [Laughs] DAVID:  So, you’re getting your Master’s Degree in Computer Science? LUCAS:  Yeah, that’s true. DAVID:  What are you working on? LUCAS:  So, I’m currently not working on my Master’s thesis yet. So this will start in March. Right now, I’m finishing off my last lectures. I haven’t chosen so wisely this semester, I think. DAVID:  [Chuckles] LUCAS:  [Chuckles] You always know that two months in and then you can’t change it anymore. But for my Master’s Degree, I will also do something for ArangoDB. DAVID:  Oh, cool. LUCAS:  So, another thing that I’m working on there is a system to implement APIs directly on top of the database. So, this is a kind of crazy idea and most people that hear it first, they say that doesn’t sound like a good plan. But you can do some nice things if your database has a flexible API that you can redefine and add things to. So, you can use this behind your Ruby application because it shouldn’t communicate so much between those two, between your database and your application layer. But you could, in theory, also communicate directly from the browser, if you’d like to do that. DAVID:  Oh, wow. KATRINA:  So are you talking about an API that talks HTTP? LUCAS:  Yeah, that’s right. KATRINA:  That’s cool. Elasticsearch does that and that creates a lot of joy. LUCAS:  Yeah, I think so too. So, our standard API is also HTTP and it helps a lot because you can just see what you’re doing and you can use all the normal tools that you have in your toolbox for HTTP. So for example, for the gem I wrote that connects you to the database, I can choose from all those fancy HTTP libraries and using Faraday, I can just switch between them. And the user can say, “Okay, I really want this gem to communicate with the database,” and then other user can choose a different one because maybe he or she is using JRuby. KATRINA:  That’s very cool. LUCAS:  So, if this would be a binary protocol, I would have to implement all of this by myself which wouldn’t be a lot of fun, I think. AVDI:  I think we’re kind of in an era where there is a lot of skepticism about the value of a traditional Computer Science education when it comes into going into software engineering. LUCAS:  Yeah, definitely. AVDI:  And I will definitely admit to being the source of some of that skepticism myself. What can you tell us about your experience with Computer Science education? LUCAS:  Yeah, so I have this discussion a lot. And people ask me if I’m crazy because I’m doing computer science. I could just earn money instead. But I think that there are two reasons why this confusion exists. The first reason is that computer science and programming are just two different things. And they are related, but there is a lot of difference between them. So, I’m really interested in the science of computers. So, I learn different things every day. I probably will never use it in my day job. AVDI:  [Chuckles] That’s one of the things I was wondering, is if you found applications for it. LUCAS:  Yes. There are not a lot of things. So, in the first two or three years of my study, I think most of this, what I learned, I can’t apply it in any kind of way. So, for all those lectures I visited, there were only two or three were we did programming at all. And all others, they just assumed that you can program, which is not true for all the students. But [chuckles] from the practical point of view, there’s not a lot that you can take with you. But for example, all the things I learned about graphs I learned at university. And I think that if I just wouldn’t have done my studying, I probably wouldn’t have looked at graphs. So, it gives you the chance to look at things that you probably wouldn’t look at just by yourself. And I think there’s value in that. And maybe not everything needs to be really important for your entire life. But things like regular expressions, understanding the inner workings of a regular expression and what the basis of it is, is quite interesting. And yeah, understanding Turing machines and maybe understanding what a computer can’t do, I think that’s valuable. And I don’t think everyone needs to do that, absolutely not. I think that you can be an excellent programmer without ever studying. But I think it’s interesting and you can learn a lot. Maybe you can use it one day. Maybe you won’t. But yeah, it’s nice to know it. KATRINA:  I can imagine that it opens a lot of doors to interesting problems that you wouldn’t meet if you’re just doing web development. LUCAS:  Yeah, yeah. KATRINA:  I was watching a TED talk the other day and there’s a woman in San Diego who’s developing. She does AI stuff and facial recognition stuff. And there’s another university somewhere in Canada who’s taking the work that she’s doing and then turning it into teaching games for children with autism, to teach them how to recognize facial expressions. LUCAS:  Wow. KATRINA:  And I can only imagine that people who are self-taught Ruby, Rails, they’ll never get into problems like that. You can shovel a website like the best of them, but you will not be creating games to teach social skills to children with autism. LUCAS:  Yeah, I totally agree that they are just, it’s inspiration. So, you can draw your inspiration from different places. And I think there’s a lot to learn from science as well. And there are very interesting things that you can then apply as this beautiful example shows to things that really help other people. I think there’s a lot of value in that. DAVID:  There are a lot of concepts. Like when we talked with -- oh, I’m blanking on his name. Tom, the last book club on understanding computability or ‘Understanding Computation’ rather, he talked a lot about how just knowing whether something is decidable or not is really useful outside of computer science and outside of other things. And so, I think I have to agree with Avdi. I’ve been kind of the source of some of that. I’ve stated publicly several times in the past that the best programmers I’ve ever worked with did not have degrees in Computer Science, that they got a degree in some engineering field and then they went into that engineering field and became programmers. And so, when it came time for them to write a program to manage a frequency modulator, they knew all of the engineering behind modulating frequencies. And all they had to do was learn enough programming to control the thing. And if you sat a computer programmer down, somebody with a Computer Science degree, sure they know about big O notation and they know about how to program in Java and they know a little bit about theory, but they don’t know any of the physics or the engineering behind it. And so, they end up writing very efficient programs that do the wrong thing. LUCAS:  Yeah, definitely. DAVID:  And my experience with everyone I’ve worked with that has gone on to do advanced graduate work in Computer Science has been a fascinating person to sit down and talk with because those are the people that understand. They’ve actually gone out and written a database engine or they’ve gone out and they’ve written engineering code or something. They’ve actually gotten their feet wet and touched some things. And then come back and actually really ground hard on the science and that’s when I think it starts to pay off. I guess what I’m saying is I’ve updated my opinion of Computer Science education, that the breakeven point is somewhere past Bachelor’s Degree, a four-year university education. But then it starts paying off big when somebody’s got a Master’s Degree or a PhD in Computer Science. There are the people that can sit down, they can look at the entire programming team of junior programmers just having a really hard time getting control over this frequency modulation system or whatever and it’s the guy who can sit down and take one look at it and go, “That’s because it’s not a Galois set and you are trying to use Galois transformations.” And he’ll just say, “Fix it this way.” And all the programmers go, “Oh yeah, why didn’t we think of that?” Well, because you don’t have a Doctorate in Computer Science. [Laughs] LUCAS:  [Laughs] Yeah, that’s true. In my Bachelor’s Degree, I think I didn’t learn really a lot that was interesting, just groundwork like math, a lot of math. Really, a lot of math, and I really liked math before I started studying. [Chuckles] And now I don’t. KATRINA:  [Laughs] Sorry. LUCAS:  [Laughs] Yeah. I think it helps you in later topics that you can then probably choose, depending on the university you are at. I think there are a lot of resources right now and we discuss this a lot at university. So, there’s a computer that looks at e-learning and what the consequences would be for the classic university. And I think they will coexist for a long, long time because e-learning is really useful. So, people can learn amazing things from MIT’s AI lecture for example. But for me, at least… AVDI:  Is that a specific lecture or a series of lectures or what? LUCAS:  Yeah. At MIT, they have an excellent lecture about artificial intelligence. I haven’t attended it yet, but I plan to when I’m done with studying. So yeah, just over the air, on the computer because a lot of people say it’s the best AI lecture that exists. So, I think there’s a lot of value in that. But for me, at least, it’s hard to motivate myself to go through an entire lecture when I’m not at university. AVDI:  Right. LUCAS:  [Chuckles] Maybe that’s my personal problem. But yeah, I think university helps a little bit with that. AVDI:  I’ve certainly made some aborted attempts at getting through some of these lecture series that are available online and I never get through. LUCAS:  Yeah. And when I was at a conference this year, there was a guy called Sam Aaron and he does a project called Overtone. Do you know that? AVDI:  It sounds familiar. LUCAS:  That’s an amazing project where you can program music in Clojure. So, he had two talks. In the first talk, he explained what he does and how he configured his Emacs to be a live coding, live music instrument. And the second talk was a concert with his brother-in-law and they played music. And this is actually his work for his Doctor’s Degree. So, he explores how to teach music with coding. And I think it’s a fascinating topic and he’s a fascinating guy and a very nice guy. And I think that those things are very valuable. They fall out of university because you can do stupid things in university and you don’t go broke because you will be paid by university. And there’s a lot of studying that will go nowhere, but maybe it will go somewhere interesting. But if it was just a project paid by a company, the company would maybe not be able to pay that. So, I think that’s one of the values of our current system. AVDI: Are there any ideas you’ve run across during your studies that you just wish more programmers you knew understood? LUCAS:  Yeah. I often face people that they heard about Turing machines and they maybe read a short blog post about it and they think they have understood how the halting problem works, for example. And they will make assumptions based on that which are maybe not entirely correct. And I think that the book from Tom Stuart will help a lot of people. And I think a lot of people that did not do Computer Science studying should probably read this book for some of those interesting basic ideas because I don’t think the way that we do computing will change for some time in this very basic form. So, it probably helps to understand it. DAVID:  I was absolutely one of those people. I had a trivial understanding of Turing completeness and Turing equivalence and Turing machines. And when I went through ‘Understanding Computation’, it really -- I don’t know. I had about 80% of it, but that 20% was based on some incorrect assumptions. And I figured I had a really clever solution to the halting problem, which was just don’t let people write the program that emits the inverse of whatever the previous program wrote. LUCAS:  [Chuckles] DAVID:  And then you’re fine. And that displays a fundamental lack of comprehension of the halting problem. [Laughs] LUCAS:  Yeah. And I think that a lot of people, they just say, “Okay, the problem means that I can’t tell if this program will ever stop but I can see that this program will stop.” And I’m like, “That’s not the halting problem, my friend.” DAVID:   Right. LUCAS:   So, I think that this book helps a lot. KATRINA:  Can you explain what the halting problem is? LUCAS:  [Chuckles] Okay. I wasn’t prepared for that. [Chuckles] So, the halting problem is basically, the question, if you can write a program that can tell you, for every other program including itself, if this program will ever stop its calculations. So there might be programs which can very fast answer, “Okay, what you asked me is true.” But if the answer to the question is, “It is false,” then it will take an indefinite amount of time or it will take a very long amount of time. And you will never know if the program is just running forever or yeah, maybe there is no solution. KATRINA:  Cool, thank you. LUCAS:  No problem. [Chuckles] Yeah, and I think that Tom Stuart did a great job. I haven’t yet had the time to read it entirely. I just flew over the pages and looked at the examples and they were really -- he chose excellently. So, I can just tell everyone read this book because it will probably help in some misunderstandings. AVDI:  So, you program in Ruby and JavaScript. Any other languages that you are interested in? LUCAS:  Yeah, I’m one of those Haskell people. [Chuckles] DAVID:  Oh, I got to go, guys. [Laughter] DAVID:  I got to go count my hair. [Laughter] LUCAS:  No, I’m really interested in a lot of different programming languages. It’s one of those things that are just interesting to me. How do you implement a programming language? How do different programming languages work? And how do they understand? How would you solve this problem in different languages? And one of the first languages that are not like the normal languages like Java, Ruby, and so on, was Haskell for me. And it was really fascinating to see this entirely different view on the world. And in the same way, Prolog, which is like a logic programming language is really fascinating. So, I had a lecture about both Haskell and Prolog where we first learned language. And then the professor told us how the language works and how you would implement it. And in the Haskell lecture, we implemented a subset of Haskell in Haskell. And in Prolog, we implemented a subset of Prolog in Prolog. [Chuckles] And this helps you to just see the world in a different way. And I really like languages which do that. So, I’m also fascinated by Clojure for the same reason. But time is a limited amount and as you… [Chuckles] LUCAS:  Maybe have seen, there are quite a few projects I’m working on right now. [Chuckles] AVDI:  Yeah, I was just looking over your GitHub profile and you do have a lot going on. I was curious if you had anything in Haskell or anything. LUCAS:  No, unfortunately not. They are like mini-programs which are just lying around in my computer. And I one day thought that maybe I will just push up a snippets folder where there are just snippets of code. But hmm, is there a lot of sense to that? I don’t really know. [Chuckles] So, there are mainly Ruby projects and JavaScript projects on my GitHub profile. AVDI:  Let’s talk about some of the other stuff you’re working on. So, we talked about the ArangoDB stuff, but you have a few other projects too, don’t you? LUCAS:  Yeah, right. So, there are two that are directly related, like ashikawa-core which is the groundwork for adaptor to ArangoDB, and guacamole which is ORM or ODM for ArangoDB. And they are both Ruby projects. And then, one of the projects I’m working a lot on is hcking or yeah, it’s unpronounceable unfortunately. AVDI:  [Chuckles] LUCAS:  So, hacking without A. And this is the community project I told you about, the event calendar for nerds. And it’s a Rails project. I sometimes like to do some Rails because I’m not doing a lot of Rails as a Ruby programmer. That’s unusual and I don’t want to lose touch with Rails and still know how it works. So, this is a nice project for that. It’s a little bit chaotic. [Chuckles] So, we’re trying to get it in shape a little bit, so yeah. [Chuckles] There are some parts in there which are not the best code I’ve ever written. DAVID:  [Chuckles] What?! [Laughter] DAVID:  A programmer releasing open source code that isn’t the best ever? LUCAS:  Yeah, right? It’s unimaginable. DAVID:  I actually consider that a fundamental victory of open source, as somebody who spent 15 years working heavily, heavily, heavily in closed source code. When I first got into open source, I had this deep abiding shame about publishing my code before it was perfect. And somebody basically just said, “Just get over yourself and just publish it. And if it’s crap, then somebody else can fix it.” And we’ve got that open source notion of ‘never complain, only fix’, right? And it was so freeing. And suddenly, I was able to move so much faster and get stuff out there that was good enough and leave it behind. And I don’t consider that a defect. I consider that absolutely a feature, when somebody says, “Yeah, this code is not exactly where I want it to be.” Well, great. The whole point of open sourcing, it was so that other people could use it and improve it. LUCAS:  I absolutely agree. If everyone just writes the best open source code there is, everyone will feel bad for their normal code. [Chuckles] So, doesn’t help a lot. DAVID:  Oh yeah, I look at my open source code and I feel fantastic about my good code. [Chuckles] KATRINA:  I feel really bad about my code and I’m terribly embarrassed about it, but then I just tell myself that I have to just ignore that and let it be. But I had one experience this summer that made me really happy that I actually released bad code into the wild. Because a person told me, while I was at a conference, that I would get fired from GitHub on the assumption that I don’t actually ship code, I only care about code being beautiful. So, I would spend all of my time writing emo code and never actually get anything shipped. [Laughter] DAVID:  Wow. LUCAS:  Yeah, that’s true. There’s a lot of danger in that. And I played around with exercism.io which is an excellent project. Thank you for that. And there’s the same thing. If you do this in everyday work, you will never get anywhere. It’s just you will improve your code and improve your code, improve your code, and you will never reach anything. But I think sometimes, it helps to think about a small piece of code which will be the best code you can write. But not every piece of code needs to be the best code you can write. And if you look back half a year, you will always see like, “Aw, I would do this totally different now.” [Chuckles] And if I look back one year, I maybe get sad sometimes about my old code. But I think this is just moving forward, I think. [Chuckles] DAVID:  Yeah. I just started working with exercism this week and it’s kind of fun because we’ve been talking in some recent episodes about how to learn and how to practice and how to get better at things. And we talked about exercism. Katrina, she had it in beta when we were at the Rogues retreat. And we goofed off and I came up with a pretty evil solution. And James came up with a spectacularly evil solution. I still giggle at what he did, to the very first problem. And I sat down this week and I was going to write the evil solution and then I thought, “No, you know what I’m going to do? I’m actually going to try and write the best possible, most perfect code that I could.” And I ended up vastly over-engineering it. And that was fun. I got to learn about it and I got to find that line between writing a klugey hack and over-architecting. You can go either way. You can do something too simple and it can be very simple and appropriate to the problem scope and yet it can be too simple. You know, it can be basically bad code. And so, it needs to be cleaned up and architected a little bit better. But you can go completely off the other end. And so, in theory, I’ve gone through five iterations of the Bob project, which is the very first one. And it’s been really easy and really simple. And I could just say, “Yeah, you know what? I’m done. I’m ready for the next problem.” But I want to do it perfectly just so that I can have had the practice of having done it perfectly. And it’s not work. I’m not getting paid by the hour to do this. So, I can afford to spend 40, 50 hours writing 30 lines of code and agonizing over every single line. And it helps me later because then I go back to work and now I am being paid by the hour. But I’ve had practice throwing out this pattern or favoring this other thing because of this practice. And you get to access that and bring it forward. So, it’s just astonishingly valuable. LUCAS:  Definitely. I was doing something similar. So, I’m working on a little project called exogenesis which should help you build better installers and updaters for your dotfiles. And I ran across this project, I think when you talked about it, like devtools from the DataMapper 2 ROM team. It’s like a collection of tools to measure your code quality and so on. And mutation testing, which was, I think, mentioned in one episode. And I extracted a part of exogenesis, the part that just prints out stuff on the terminal. And I wanted to make it perfectly tested. So, I started up with devtools and mutation testing from day one and I wanted to have 100% mutation testing and all the metrics should be the best they’ve ever been. [Chuckles] I’m not really far into the project because I’m just writing so much code and rethinking and refactoring. And I’m not getting very fast with it but it’s an excellent learning thing. Because it will tell you, like if I delete this line of code, your test will never notice it. So, if I see that in this code then maybe I don’t want to use mutant in all of my projects. But I now know that maybe in my other projects, I have to take a closer look at code like that and see if maybe I do this mistake over and over again and don’t test this special case, for example. DAVID:  Yeah. LUCAS:  And I think yeah, there are a lot of things like just experimenting and things like exercism which will just help you understand code better and maybe write your real code better. DAVID:  Yeah, absolutely. One of my early submissions to the Bob project, I monkey-patched Array. And I modified the delete_at method. So, it’s a true monkey-patch. I am replacing an existing method on Array. And I’m of the opinion, and I argued this, I think successfully on exercism, that what I wanted to do was delete_at and then give a test block that would find the element that I wanted to delete and delete_at takes the index. It does not take a block. Index will take a block and return the index. So, if you want to delete_at a block, what you have to do is Array.delete_at and then you give it Array.index block and that will work. But it’s repetitive and it looks bad. And so, I built a version of delete_at that takes a block and if no block is given, it calls the old version of delete_at. And if a block was given, then it calls index or passes the block to index, gets that number back, and then calls the old version of delete_at. And I argued very passionately that this makes the core API better and that it deserves to be in core. It should not be in a decorator. It should not be in a delegator. It should live in core. It really is. And it should be inheritance either because of the problems. I’ll post the link in the show notes of Steve Klabnik’s, Katrina actually gave me this link, Steve Klabnik wrote a great blog post about don’t subclass core data types because the C code will sometimes make assumptions about the classes. And if you subclass it, you can actually have memory leaks happening because you’re class type has changed and the C code makes assumptions about the classes. But I argued very passionately that this core monkey-patch was valid and was good and that it should live in core. And I am telling the reader, Ruby is wrong and this makes Ruby more right. And I argued that if I were going to put this in a large production suite, I absolutely would not do it without making absolutely certain that everybody on the team knew it was there. And then I would pull the entire test suite out of Ruby for array and put it into the application to test my monkey-patch to assert that arrays still acted 100% like arrays. And the reason why I think of this is that you mentioned mutation testing. And I haven’t played with mutation testing in a long, long time. But now that I think about it, I would throw in mutation testing on a core monkey-patch as well. Basically, this has to have 100% coverage and full mutation testing to guarantee that every line is asserted deliberately and discreetly in the core test suite. Otherwise, you cannot monkey-patch core. You’re not allowed. It’s just too dangerous. We have to have absolute trust that this method works the way we expect it to. LUCAS:  Yeah, definitely. I think that a project like RubySpec helps a lot if you really want to monkey-patch and you think it’s a good idea to check if you don’t break anything really essential, like things that everyone that uses Ruby expects to work. So, probably a good idea. DAVID:  Yeah. Another kudo for exercism, this is turning into the exercism show. [Laughter] DAVID:   Another kudo for exercism was that I finally pulled the monkey-patch out because, I think it was actually Katrina that argued, “Your code isn’t readable.” [Laughs] It’s, “You’ve written an eight-line monkey patch on a core class which makes everybody’s tail go all bushy. And you did it to remove 12 characters off of one line of code. So, readability-wise, you sacrificed eight lines to save 10% on one line.” I’m like, “Eh, this is unreadable.” I had to go sleep on it, though, before I could come back and say, “Okay, okay, okay. I’ll take out my monkey-patch.” LUCAS:  Yeah, I think most people that do their first submission to exercism, they will just fire anything off and say, “Okay, the test passes. It’s okay.” And then they will notice that there are real people that will read their code and try to understand it. And then funny things happen. And you will get into arguments with people and say, “You are so wrong.” DAVID:  Yes. LUCAS:  [Laughs] And I think my Bob code had eight or nine iterations and now I really like the code. So, I could try out a thing that I didn’t try out before like stabby lambdas for case statements. DAVID:  Yeah. LUCAS:  Yeah. I really enjoy just putting a little bit of code somewhere and seeing if it works, if other people understand it. And yeah, push down things that are not so interesting and not so important for the reader to understand your code. DAVID:  Yeah. AVDI:  Lucas, I have a question for you and if you don’t have an answer to this, that’s fine. We’ll just edit it out. Since we brought you on the show, I want to give you a chance to sort of take advantage of the pulpit. Is there anything that Ruby programmers aren’t thinking about that they should be thinking about, in your opinion? LUCAS:  Okay. So, that’s a very general question? AVDI:  Yes. [Chuckles] LUCAS:  Okay. Yeah, I hear a lot of discussions about people that really enjoy functional programming. As I said before, I really enjoy it as well. And they try to use the same techniques in Ruby, which is kind of dangerous because we don’t have tail-call optimization, and other things in the language which are necessary for certain kinds of things that you want to do in a functional programming language. And I think that people should, if they really want to try out functional programming, they should go to a real functional programming language and try it out there. And I think it will help people with misunderstandings about functional programming. I gave a long talk. I think I planned for 20 minutes, but I gave 50 minutes of talk about functional programming at my local Ruby user group. And a lot of people, they said, “Oh, okay. Now I understand what this means.” Because I learned functional programming from the perspective of theoretical computer scientists and I think this perspective is different from people that just want to make their codes run in parallel. And there are other techniques like the ECTA model which can be implemented very nicely in Ruby. And maybe, we shouldn’t just try to copy everything from other languages. [Chuckles] AVDI:  So, it’s not all about just getting… LUCAS:  Does it answer your question or… AVDI:  Yeah. Well no, I think… DAVID:  Yeah, that’s great… AVDI:  And I think that opens up some great follow-ups. LUCAS:  [Chuckles] Okay. AVDI:  So, I guess one of the things, it sounds like you’re saying is functional programming is worth getting into and not just so that you can make code run on multiple cores? LUCAS:  Yeah, definitely. So, when there are problems where I see that they have a mathematical nature, they are not mathematical. I’m not a mathematician and I don’t solve big calculations or something like that or prove some theorems. But there are problems where I see just a parallel to a mathematical problem. And I can express them very well in Haskell. So, I think you can learn to express things differently and this will make you think harder about which is the right tool for the job. So, if for example, you have a problem and it’s better to solve it in Haskell, maybe there’s a situation where you shouldn’t use Ruby. You should maybe use something else even though you really like Ruby like I do. So, changing your perspective always helps. AVDI:  Do you have a specific example of a problem that you’ve found easier to model in Haskell? LUCAS:  Oh. I think it was quite funny. We discussed a problem where a designer asked us for, there was a 200-pixel wide area and we should find the best way to split it in different sections. How wide should those sections be? And we sat down and we tried it in Ruby and it kind of worked. And I was like, “Huh. But this was kind of a lot of code to express that.” And I retried that in Haskell and it was just very natural to express it. And even though most of the people there didn’t know Haskell, they could still understand the code. So, I think we are faced with different problems that have a mathematical nature because computers are things that compute stuff. [Chuckles] So, this sometimes helps. DAVID:  I think now might be a good time for me to point out that I teased you earlier about Haskell. And right now, all of our listeners that do Haskell are kind of bristling at me for having done that. LUCAS:  [Laughs] DAVID:  And I just want to take this opportunity to say I’m glad you feel bad. You know what you did. And, you know…No, in seriousness, Haskell is a language that is very powerful for mathematical computing as well. A friend of mine and I did Project Euler together and I was doing them in Ruby and he was doing them in Haskell. And invariably, his solutions were shorter, more elegant, more to the point. I thought mine were more readable and I kind of like mine more, but that’s because I like Ruby and I’m not adept at Haskell. I tried to learn it and I couldn’t get my head wrapped around monads and that sort of thing. And so, our current Book Club book is ‘Functional Programming for the Object-Oriented Programmer’ by Brian Marick. And it’s being a godsend for somebody who’s rigidly stuck in the OO and procedural thinking. It’s a great book to kind of unhinge your mind a little bit and say, “Okay, here’s how some of the world thinks,” and it’s very different than what you’re used to. LUCAS:  Yeah. I’m looking forward to this. I didn’t read the book yet. I’d planned to. I think there’s also a coupon called. Maybe I should get the book fast. And I’m really interested in that because there are a lot of people that say we should learn from functional programming. They mean a lot of different things because functional programming’s a lot of different things to different people. It’s like NoSQL. It’s just a word that has so many meanings that it doesn’t have a meaning at all. DAVID:  Yeah. LUCAS:  And if I tell you what my definition of functional programming is, there will be 10,000 people who tell me that I’m totally wrong and that doesn’t make any sense. So, it’s more like a way of thinking, probably, and yeah, a set of ideas. DAVID:  Yeah. And there are ideas that transfer really well to Ruby, like making sure your methods don’t have any side-effects is really, really good. Making sure that your methods are, or that your data objects are immutable, little bit harder in Ruby and stresses the Ruby VM a little bit more because you’re creating so many extra copies of things because the language isn’t quite as directly designed for that way of being. But you can do it. And like you said, if you’re going to go overboard with FP, maybe use an FP language, yeah. LUCAS:  Yeah, especially the immutability. I see that there are people who write libraries to emulate immutability in Ruby. And this is nice for understanding of code. But all the performance benefits you get, they don’t work if the language is not designed to work like this. AVDI:  Yeah. Yeah, that’s been a concern of mine as well. It’s having the form but denying the power thereof. DAVID:  [Chuckles] Yes. AVDI:  To get a little biblical. You know, they’re neat exercises. I’ve looked at a lot of these things. They’re really neat exercises and I think they’re cool, as you say, as a means to understand. But you’re not going to reap the benefits. And yeah, it’s not the same as when you actually are forced to just shift over completely to the functional mindset. DAVID:  Yeah. AVDI:  I’m curious if you have an opinion. Let’s say I’m a listener. I’m mainly just working in Ruby and I want to try a functional language. Of course, the Book Club book, as Dave mentioned, is Brian Marick’s book and that one uses Clojure examples. But I’m curious if you have an opinion. What’s a good functional language to get started with? LUCAS:  Yeah. So, I discuss this a lot with people and there are a lot of people that suggest Lisp or Lisp and Scheme and I think that they are not a good way to get started because they are not pure functional programming languages. DAVID:  Right. LUCAS:  And they will not keep you from doing things that are not functional. So, if you want to understand what this means, then you probably should use a language which enforces it. And for me, the strongest one is Haskell but it’s a little bit hard to get into it. I think that Clojure, even though it’s a Lisp, has a lot more of those ideas from functional programming like immutability. AVDI:  It’s a lot closer to Haskell than most Lisps. LUCAS:  Yeah. The thing I’m missing in Clojure is good pattern-matching, which is amazing in Haskell. AVDI:  Yeah. LUCAS:  They are. That’s the reason that the syntax is so simple, that it does really look nice, because Haskell was designed to look good with pattern-matching. And I would just say try out Haskell. But I’m not sure which resource is the best. So you could, for example, do it in exercism. And there are Haskell tracks as well. But if you want to learn the basics, there is this learning -- no, I forgot the name. But there is a very popular book which is free on the internet. AVDI:  Is it ‘Learn You a Haskell for Great Good!’? LUCAS:  Yeah, right, right. And a lot of people really like it. I didn’t like it a lot. I have a book. I will put it in the show notes. I can’t remember the name right now, which I enjoyed a lot. But it’s a little bit more mathematical maybe. But I think it’s an excellent introduction. It’s a short book and you can get through it very fast. It’s, I think, from one of the guys behind Haskell because there are 10 people that are in the Haskell core community from the beginning. AVDI:  Those books always scared me because when I got started with Haskell many years ago, there weren’t as many resources available online. And I got started with ‘The Gentle Introduction to Haskell’. I don’t know if you’ve ever seen that. LUCAS:  I don’t think so. AVDI:  It was not quite a whole book, more of a paper. LUCAS:  Oh, okay. AVDI:  But the name was clearly ironic because it was about as gentle as a kick in the face. [Laughter] AVDI:  I think it was gentle if you happen to already know ML really well. [Laughs] LUCAS:  Yeah. DAVID:  Yeah. LUCAS:  Which are like five people on the [inaudible]. AVDI:  So yeah, some of the earlier books that were more mathematically oriented always scared me. But I’ll have to take a look at the one that you suggest. I know another one that people often talk about is ‘Real World Haskell’. LUCAS:  Yeah. AVDI:  But I think that’s probably another one that’s more focused on getting things done and less focused on understanding the mathematical mindset. LUCAS:  Yeah, I think the thing that this book, which I will put in the show notes, is really good at, is showing you the philosophy and how the programs that you write are more expressive. Practical Haskell or Everyday Haskell, I forgot the name. It tries to start gently and wants to keep monads from you. And I think there are a million ways to explain monads and nobody really understands what the other people are talking about. AVDI:  I hear monads are like a walrus eating a taco. LUCAS:  [Laughs] I heard they are like desks and they are like carpets. AVDI:  [Laughs] LUCAS:  Yeah, I hear 5,000 different ways to explain them. And this book, it will just show you what you have to do to get a side-effect in Haskell. And after that, it will tell you, “By the way, you just used a monad.” And I think this is the least scary way to do it. Because if just the word is so scary, monads, it sounds like something latent and old. DAVID:  I always think of mononucleosis of the gonads. And that’s not… [Laughter] LUCAS:  It’s the first that you thought of thinking about. DAVID:  I know that’s not right. But just listen to what I’m saying. [Laughter] DAVID:  I think dirty things when I hear the word monad. I think that’s part of it. I’m not kidding. I genuinely think that’s part of why I have a hard time wrapping my head around the word and around the concepts. [Laughter] LUCAS:  Yeah, okay. Maybe that doesn’t help a lot if you have such a crazy part in your head. [Laughter] LUCAS:  But I don’t know. This is a tendency of functional programming which doesn’t help in bringing it to more people that they think about different crazy words for everything. And they sound very technical or very mathematical. And basically, they are just simple concepts. And if they had a simpler name, people wouldn’t be so scared about them, I think. DAVID:  Yeah. LUCAS:  And I think if you use Haskell, then a lot of those concepts will come very natural to you. And if someone just comes to you later and says, “Oh by the way, this is a closure,” then you will not be scared because you will understand what the word means and not be scared of just the word. AVDI:  Definitely. And yeah, I definitely agree about learning Haskell to understand that functional mindset. It certainly helped me. LUCAS:  Yeah. And I think if you try Haskell and after that go to Clojure, then you will have a different perspective on it. And maybe it will be easier for you to understand things. And Clojure is probably the more practical tool. So, if you really want to get something done in a functional programming language, you should use Clojure. But if you want to understand the concept, then you should use Haskell because I don’t think there are a lot of companies in the world which use Haskell for something real world. And there are reasons for that, because it gets really messy if the project gets bigger. AVDI:  That’s an interesting point. And yeah, I could see where that would be true. LUCAS:  Yeah. The most complex Haskell program I wrote was the implementation of the subset of Haskell. [Chuckles] And it started to get very messy. And we tried to refactor it, but refactoring in Haskell is not so much fun. AVDI:  Which is weird. LUCAS:  Yeah. AVDI:  I guess it ought to be. It ought to be okay, because it’s a language that is able to know so much about itself at compile time that you ought to be able to have automated tools to really easily do refactoring. But I guess that’s sort of one of the tradeoffs between Haskell and your average Lisp, is that you can write these really quick and dirty tools to refactor in List pretty easily because the representation is the AST. LUCAS:  Yeah. So, this is what is really beautiful about Lisp is that the syntax is so simple and that you can -- if you manipulate the syntax, it will be much more natural than it is probably in Ruby, for example. But yeah, Haskell doesn’t have this kind of features. It’s kind of static and it has types and so on. But it’s a great teacher and it will just let you think more about the code you just wrote. So, I think it’s a valuable lesson for everyone to try it. Not to use it in a real program, but just to write a little program with it and just try for the first time to print something to the console. [Laughter] DAVID:  Which is technically a side-effect, right? LUCAS:  Yeah, right. AVDI:  So technically, it doesn’t matter. [Laughter] LUCAS:  Side-effect is by the way a very awful word, which is misleading in my opinion because it sounds like it doesn’t matter what the side-effect does. AVDI:  [Laughs] DAVID:  Yeah. LUCAS:  Yeah. Side-effect is basically [inaudible]. AVDI:  And coincidentally, this program also launches the measles. But that’s just a side-effect. [Laughter] LUCAS:  Yeah, something like that. Also, what is really interesting about Haskell is the way it handles types. So actually, I started with Flash programming, but the first real programming language was Java for me. And I really started to hate types and typed languages and I thought that all typed languages will be awful. And when I discovered Ruby, I was like, “Yes! This is awesome. I can do whatever I want.” [Chuckles] And when I then discovered Haskell, I saw this different approach to types and how they can actually help you and not just be this thing that you have to write several times like car ca = new car. AVDI:  [Laughs] LUCAS:  What? And because it uses type inference, it’s not more work to write, but it will give you confidence in your code. And also, you will express the things with types instead of the function names. And this is quite interesting and a different approach than you have in other programming languages. AVDI:  Yeah, definitely. And it certainly -- I don’t know. It makes you think a little harder about the data types that you’re using. LUCAS:  Yeah, definitely. AVDI:  And what are their valid ranges and stuff like that. LUCAS:  Yeah. And they have crazy concepts about testing which are different from the way that we do testing in Ruby, for example. Like FastCheck I think is the name of the program, which will… AVDI:  QuickCheck or something. LUCAS:  QuickCheck, right. QuickCheck, which is just a crazy concept and which would never work in a language like Ruby but just to try it out, it’s amazing. And again, it will teach you, like TDD teaches you. It will teach you different things about programming. AVDI:  It always seemed like those tools, like the QuickCheck, kind of were a totally different arena of testing than unit. It seemed like they’re kind of orthogonal almost. LUCAS:  Yeah. AVDI:  I mean it seems to me, unless I’m mistaken, it seems to me they’re only applicable to very functional functions. LUCAS:  [Laughs] AVDI:  [Chuckles] Things that are just like a simple function of inputs to outputs. I don’t know. I look at that sometimes and I think, “Okay, I can definitely see putting some basic functions through their paces with this.” But it’s hard to see how this is going to help me verify my website. LUCAS:  Yeah, that’s true. QuickCheck is only useable if you have functions in the mathematical sense, so you’re mapping something to something else. And nothing is happening while you are doing that. So, no side-effects. And otherwise, it’s kind of awkward to use QuickCheck. But I’ve never written bigger amounts of code and tested them with QuickCheck. But I think it’s interesting. I think this was also ported to Clojure recently or not so recently. Maybe this can work there too for certain functions. AVDI:  Yeah. There’s been a lot of crossover. I know that Clojure is getting some optional types as well. LUCAS:  Yeah. In the beginning, when I heard about Clojure, I was like, “Ah, okay. So, it’s just Common Lisp and it’s running in the JVM. What’s new about that?” So, I ignored it for a while because I thought that it will be as successful as Common Lisp. [Laughter] LUCAS:  But there are really interesting concepts about it like the immutability that make it an interesting language. And the people that are behind Clojure, they are not such deep believers in the purity of the Lisp, like never introduce any syntax at all. They introduced square brackets which is like a deadly sin for Lisp programmers, I think. AVDI:  [Laughs] Yes. LUCAS:  I think this gives a lot of opportunity to… AVDI:  I think they also commit the heresy of not using car and cdr to refer to the first and rest of the list. LUCAS:  Yeah. Are they not available? Or I think they are just an alias or something and people were really mad about that. AVDI:  The funny thing is, even Common Lisp has had first and rest as aliases for car and cdr for a long time. LUCAS:  Yeah. [Chuckles] AVDI:  But nobody actually used them. LUCAS:  Yeah, because you can’t do cadaddadaddr. AVDI:  Cdadddadddr, yeah. [Laughter] AVDI:  It’s like Common Lisp programmers wonder why nobody likes them. [Laughter] DAVID:  You know, if Lisp used first and rest, you’d still have the same problem because people would come in and say, “Yeah, we need to get the firffrrfffrfffr.” [Laughter] AVDI:  At this point, I think we’ve probably lost 95% of the listeners. DAVID:  Yeah, sorry. Sorry. [Laugher] KATRINA:  Picks, maybe? DAVID:  The second item in the list is referred to as the efer. That’s all I’m going to say. [Laughter] AVDI:  Next week, on the polyglot programmer podcast... DAVID:  [Laughs] LUCAS:  I just want to clarify that I don’t dislike Common Lisp. It just has a difficult heritage because there’s more than one way to do it in Ruby that means something entirely different for a Common Lisp programmer because there are a thousand ways to do everything in Common Lisp because they unified, I think, six core standards at the time and added ten more. And therefore for every function, there are ten aliases. And everyone will tell you something different is the one way to do it. So, I think, we, at the Ruby community mostly have two different ways to do something and they have five or six. DAVID:  Yeah. Python says there’s one right way to do it. Ruby says there’s multiple ways to do it but one of them is probably the best for any given situation. Perl says there’s more than one way to skin a cat. And Common Lisp says there’s no wrong way to do it, really. LUCAS:  [Laughs] Yeah, I think that’s a good way to describe it. AVDI:  Alright. So, picks other than Common Lisp. Let’s start with Katrina. KATRINA:  I have so many picks today. Please excuse me. So, my first one. Rich Hickey did a talk called ‘Simple Made Easy’. It’s really, really good. It talks about the difference between simple and simplicity as being a subjective measure and easy as being -- sorry, the opposite. Simple is an objective measure of how interleaved something is or the lack thereof, so it’s the opposite of complexity. Whereas easy is a subject of measure that can be anything from “It’s close at hand,” or “It’s familiar to me.” And because we talked about readability a couple of times during the show, I felt that this was very relevant. We talked about Ruby versus Haskell being used to solve Euler project problems. And David said that he found that the Ruby was more readable. And I would argue that that’s a function of familiarity more than anything else. DAVID:  Oh, absolutely. Absolutely. KATRINA:  So, that was Rich Hickey’s ‘Simple Made Easy’. The second thing. I was talking to a friend about certain things that we both find complicated or awkward. And this really funny thing came up. We both find that this whole concept of eye contact during a conversation is difficult for completely different reasons. And I found a website that will teach you social skills. Among them, how to make eye contact. So the website is ImproveYourSocialSkills.com and I’ll put a link to that in the show notes. My third pick is Temple Grandin who is a real person but there’s a movie from 2010 that is really, really, really good. It’s biographical. It’s beautiful. It’s funny. It’s inspiring. It’s poignant. And it just, I don’t know. I love the movie but I also love this person, Temple Grandin. She has a PhD in Animal Science. She lives out here in Colorado, I think. And she has high-functioning autism and she’s a visual thinker. So, she has this completely different way of processing the world and it’s absolutely fascinating. And the follow-on pick to that is a TED talk that she did called ‘Different kinds of minds’ that is also just really interesting. And that’s what I have. DAVID:  Cool. LUCAS:  I will just throw something in there. So, there’s an excellent blog post from The Changelog which lists a few more of Rich Hickey’s talks including this one. And it’s a really amazing list. So, you should maybe watch some other talks as well. AVDI:  David, what are your picks? DAVID:  I’ve just got two today. TinyHabits.com. I thought I had picked this months ago when I picked Charles Duhigg’s book ‘The Power of Habit’. And I didn’t. So, I’m picking it now. So, TinyHabits.com. What this is, is a website that will walk you through establishing a tiny little micro-habit. His entire premise is basically if you want to establish a habit like brushing your teeth, you set a trigger event that will happen immediately before you need to do the habit. You make the habit as small and painless as possible. Like you just say, “I’m just going to brush one tooth. That’s all I have to do and I get credit for having done it.” And then you immediately give yourself a small immediate reward after having done it, whether it’s go play ukulele for 15 minutes or whether it’s just look at yourself in the mirror and say, “You’re awesome. You finally did it.” And what you do is you go out to this website every week before, I think, Sunday afternoon. It might be Saturday afternoon. And you sign up. And it puts you on the mailing list for seven days. And what he does is he lets you write down the three habits that you want to do and he helps you make sure that they’re small and that they have a specific trigger and that they have a good reward afterwards. And then, he emails you every single day and says, “Did you do it? Or didn’t you do it?” And you write back and you respond to the email with YYY or YNY or NNN. And he actually reads all of the mails coming back. And so, if you write back YNY, he’ll come back and talk to you about your second habit and converse with you about how to help you establish a better habit and how to improve yourself. And it’s fantastic for forming a new habit. Because you stay on the mailing list for seven days and then he stops bothering you. And you can reenlist for another week or you can just let it go. So, TinyHabits.com is my first pick. It’s a lot of fun. My second pick is much more involved and complicated but we spent half the show talking about it. I cannot believe that exercism.io has not been picked on the show before. Katrina, you’ve really just got to learn to be absolutely shameless about plugging your own stuff because exercism is fantastic. So, doggone it! If you won’t pick it, I will. [Chuckles] DAVID:  And so, exercism.io. It’s my pick for today. It’s exercism spelled with an E-X-E, like exercise. But other than that, it looks like exorcism and the icon even has horns. It’s a fantastic place to go practice your good coding skills or your bad coding skills and be shamed by your friends. [Chuckles] AVDI:  My picks today turned out to be kind of topical to the conversation that we had. So, I’m picking a couple of blog posts from a former guest on the show, Jessica Kerr or Kerr. I don’t remember how the last name is pronounced. But she’s got some blog posts on functional programming. Particularly, there’s this one called ‘From lists to trains to functors’. And then another one called ‘Trains within trains’. And they’re beautifully illustrated. They have these great illustrations of how mapping works and how lazy lists work and stuff like that. And I can’t really do them justice because they’re visual. But I’ve been really enjoying them. Lucas, what are your picks? LUCAS:  To improve my word as a computer science nerd, I will pick a paper. [Chuckles] So, there is this excellent paper called ‘An Eye Tracking Study on camelCase and under_score Identifier Styles’. DAVID:  Ooh.. LUCAS:  [Chuckles] As someone who switches between Ruby and JavaScript very often, and JavaScript is using camel case and Ruby’s using underscore and I’m always complaining about, “This is so stupid, camel case. I hate camel case.” And now, there is proof that the underscore syntax is better than the camel case syntax. DAVID:  Yes! LUCAS:  So, it’s much easier to read. So, if you just want to, from an eye tracking point of view, it’s much faster to read the methods in an underscore syntax. So, if you ever have this argument, you can throw papers at people. AVDI:  If only somebody would come up with a study that proves that dashes are better than underscores. LUCAS:  [Laughs] I think they are. Yeah, they have some similarities in the eye tracking area. And I found them quite nice because in the Lisp world, everyone is using dashes. And I find it some -- I really enjoy it. But underscores are excellent. As long as you don’t use camel case, everything’s alright. So, my second pick is teaching kids. So, what I’ve done recently is helping organize Coder Dojo. And this is a place for kids to learn about programming and about other computer-related stuff and maybe just build stuff. And it’s a lot of fun. And in the vein of the things that we talked about today, it’s really nice to change your perspective, to see the world from a kid’s point of view. The kid may not care about if you adjust your dos and ends. It will just have fun drawing stuff on the screen and building robots. And everyone should try it and teach a kid to program. And my third pick is a game. This is a game that I’m playing right now in my iPhone because it’s a lot of fun. It’s called Super Spell Boy and I will put a link into the show notes. It’s just a good game. If you have some minutes to spare, if you’re waiting for a bus or if you just come home from a long day and just want to shut your brain down for a minute or two. So yeah, that’s my pick. AVDI:  Alright, cool. Well, I think that’s about it. Just a reminder before we go, our next Book Club book is ‘Functional Programming for the Object-Oriented Programmer’ by Brian Marick. KATRINA:  And go buy t-shirts. DAVID:  Go buy t-shirts. AVDI:  Yeah. I just wanted to say you still have a little bit of time to get that book and read it before we air the show on Christmas. And if you do, there’s a $5-off code which is ‘please_remember_the_starving_artist’, all lowercase with underscores, not camel case. [Laughter] DAVID:  So, it’s readable. AVDI:  That’s right. And yes, buy t-shirts. Booster.com/RubyRogues. Buy one for everyone in your family, except don’t buy too many because I still need to buy some for my family. [Laughter] AVDI:  No, seriously. Go buy them. DAVID:  There’s 24 orders placed right now and I’m pretty sure 20 of those are us Rogues. [Laughter] AVDI:  Alright. Well, Lucas, thank you very much for coming on the show. DAVID:  Yes, this was awesome. Thanks for coming. KATRINA:  Yeah, thank you. This was fun. LUCAS:  I was happy to have joined you. I’m listening to the podcast every week. So, thank you. DAVID:  Awesome. AVDI:  Alright, bye- bye.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.