 This is a bit of an interactive presentation, so I'm gonna ask for some of your help. But we'll get to that in a minute. I am here to talk about polyglot. How many of you have heard this term before? All right, cool. Jim gave away half of my presentation during his keynote, so I'd like to extend a thank you to him. So we'll cut this a little bit shorter. Can you guys hear me okay? This is not the right, you know what? All right. So, polyglot, I am going to hurt some of your feelings. There will be a lot of NIRC as I'm talking. This guy's an idiot. What is he talking about? So, but anyway. So you can follow me on Twitter. I'm B. Miseraini. I'm on GitHub under the same username. And as Josh mentioned, I work at Heroku. How many of you know who Heroku is? How many of you have apps deployed on Heroku? All right. And yes, we have read-only file system. So, I'm here to talk about how to be a polyglot. How many of you know what the definition of a polyglot is? Okay, so cool for the term on the definition. So a polyglot is a person who speaks several languages. So you can kind of get a sense of what I'm about to talk about. But I'm going to elaborate on this definition just a little bit more because we're all engineers here and it needs to be elaborated on in order to make sense for what I'm going to talk about. I'm going to amend it with a person or machine who speaks several languages. But I wanna focus also on the word several. And I think all my life I've struggled with the difference between a few and several and the definition. So I actually looked it up, defined it, and several means more than two or three. So let's break that down. There it is. Let me give you a real world example of polyglot. All right, as you can see this fine specimen, it's part Ewok, part Great Dane, and part Jedi. Ladies and gentlemen, I give you the rare and elusive Jadena Walk. That's polyglot. Okay, this is the interactive session. Every time you see this slide, I need everyone to yell polyglot. So Unix itself, Unix is, how many of you do Unix here? On Max, previous to you, whatever, Unix. Okay, so Unix is polyglot. You are all in this audience, except for you in the back with the Java one polo. Polyglot. Or I'm sorry, except a polyglot. Damn it, I moved the slide. That was polyglot. All right, okay, that was the slide I missed. All right, so that, this is, let me give you a more complete example. This is polyglot. How many languages do you see here? Three. All right, I'm gonna break it down for you. There are actually four. All right, so let's take a look. First, we have an interactive bash. So here we have bash, right? Most people don't realize or remember that when you're in a console, you're programming. You're doing it interactively, but you're programming. We have Perl. How many of you use ACK? For those of you who don't know about, yes, it's amazing. Any of you don't know about ACK, go to betterthangrep.org and blow your mind. That's actually the URL. That's where you find it. Ruby, this is Ruby meta. I'm using a Perl script in bash to look for Ruby code and vi. I use vi, vi is written in C and it also runs Vim script, right? So we have five languages here that are running all together to produce a result, to work out problem for me. Let's take that, flip it and reverse it and go from the inside out. So we just went from the outside in, let's go from the inside out. Now for a general purpose programming language, if you're going to do polyglot, a very simple basic example of polyglot is something like Ruby, where I can take input from a stream, massage it, manipulate it, do things with it, run calculations, all right? And then I can print it back out and then something on the business end of my application can take that, massage it and move it back out again until it's all complete and then it eventually ends up somewhere but usually on standard out or on a web server or whatever. So with all that being said, this isn't hard. So why am I talking to you? Because everybody takes their favorite language and turns it into one big hammer and everything becomes a nail. They decide, oh, I've learned Ruby, it does everything. It's a general purpose programming language. I can do everything in it. Why would I ever wanna go do anything else, right? I'll let the other guys, I mean, the act guy, yeah, that's Pearl but whatever he does, Pearl but I don't have to learn Pearl, that's fine. I'll just, I'll use his code but it's just, it's a very romantic view of it. I'm just, I'll hide that in his code base and never have to see it. So, but the problem with this is when you get these hammers and you start to feel like this with any language, you, at some point, as you mature with this, you start to realize that every great tool has a dark side. And that what you re... That's pretty funny. I thought that was pretty awesome when I saw that. So what you really want is many hammers. You need a lot of them, right? And I'm gonna go back to the definition of several and say that it's not really that you want many, you just need more than two or three. When you have two, a lot of us in the Ruby community do Ruby and JavaScript, right? Cause we're writing a Rails app and then on the client side, we're writing JavaScript and that's about as far as we get, right? But it's really important to go out and learn new things. So my message to you is don't do everything in Ruby, asshole. I'm sorry, you're crying now. I know. Shh, it's okay, it's okay. Shh, let me give you some reasons. And I can already hear you in IRC right now going through making fun of me, calling me silly names and telling me I'm an idiot for this, but let me get through the reasons first. One is, because you want to learn how others think. And when you're in Ruby, we all tend to think alike, right? Oh, go use RSpec, go use test-driven development. Let's do test-driven development. Yeah, of course that's a great thing. Most languages, they're not gonna argue with you about that. But there's other things about how we do things. Oh, I'll make a class for that, right? And as Jim showed us in his keynote, other guys are like, no, I'll make a function for that instead. But that's interesting. How does that work? But I don't have encapsulation, do I? Yes, of course you do. You do have encapsulation in JavaScript. In fact, Josh Susser and I had an IM debate about JavaScript having encapsulation and I told him yes it does and he says no it doesn't and we went back and forth and it was interesting. So, we didn't really get anywhere with it, but it was interesting. So, also you want to, because when you start learning how other people think, you start realizing their paradigms, their views of the world and their views of problems. And that sometimes they're solving the same problems you're solving, but in a different way. And you can start to realize and understand and see how they approach it with their way of thinking. And that's really important because you can stop and think, oh that's really interesting. And one of the things that really, I get a lot of benefit from talking with other people who are passionate about other languages and who are solving problems very similar to the ones I'm solving, is the words they use. And those are really important because when people start using these other words that you're really not familiar with or that you haven't heard in the context of what you're trying to do, you start to think that is a really interesting word that just completely changed the way I thought about the whole problem. And that's to me, that's one of the biggest things I love about going into new communities and new languages. But mainly because no language is a perfect ten across the board. So this is where people are gonna start getting really mad at me. Cause I've got a chart. Let's break this down. Now I tried to fit this and get a big enough font so can everybody see okay? Let me read these off real quick. First cell is language, CPU concurrency, IO concurrency, agility, IMHO, systems as in POSIX systems, web, CLI, and text mining. I threw that one in the end cause that was for one of the languages. So, Ruby, this is in my opinion about where it scores in all of these. Perceive you concurrency, I'm giving it probably the lowest score I can possibly give it. And I'm talking like MRI, I'm not okay, you J-Ruby guys I know. See, there's the guys making fun of me and IRC. So, IO concurrency as well. I gave it about a four on IO concurrency cause it doesn't really, it has good, right? IO concurrency, if you're using threads or you can use a vent machine, which I'm gonna throw at a seven. How many of you use an vent machine? Right? Yeah, a vent machine's awesome, right? But it gives us this really nice form of concurrency where we're not blocking on IO anymore. We can start doing things with the CPU instead of waiting and waiting for IO to happen. Agility and Ruby, of course. I'm going to give it a nine, that's why I love Ruby. I can crank things out so fast with Ruby, right? But sometimes it does get in the way. Especially when at Heroku, I do a lot of work with systems programming. I need to speak to the system. I need to do things that the system knows how to do that Ruby does not. And Ruby eventually starts getting in my way with this. How many of you have ever had to work with pipes, PIDs and all that, I mean, any system calls in Ruby? Yeah, it starts to get really gnarly and nasty, right? So that, at some point, I have to start moving away from Ruby in those little areas and start going with something else. And I'll get to those. And with web, obviously you get to name, right? We've got Sinatra. That's all you need. Can I get a big round of applause for Ryan so may I go back there too, who also made Sinatra 1.0 happen? Thank you. Command line, doing command line work with Ruby, I find it pretty pleasurable. I don't really, I mean, OpPars is great if I need anything more than that. We've got things like Thor. We've got, and there's other really great libraries out there, but it's got pretty good CLI support. It starts up quick enough and it's pretty responsive. But for text mining, I'm gonna throw it at a seven. How many of you have ever done any kind of text mining or like trying to dig through a lot of text? Or maybe like an IngenX or an Apache log file, right? And especially if you have millions and millions of hits you're digging through, you might as well start a screen session and go get some more videos because you're going to be there a while. So the next language, I'm gonna try and move through these a little bit faster. Erlang, how many of you have done Erlang here? All right, we've got a few hands. So Erlang, CPU concurrency, eight. I'm gonna throw it in an eight, not a nine, even though a lot of people wanna give it a nine, but it is pretty exhausting on the CPU and does a lot of needless copying around in places, but that's how it gets its thread safety is by copying things a little more than it should have to. The IO concurrency, it's pretty good. It's pretty high up there, but the agility is about a five. I don't know if any of you have tried to crank something out in an hour in Erlang. It's not really that easy. There's a lot of setup and a lot of overhead to get started with it. So systems work, it has none. It's worse than Java. It's horrible. Like there's no opposing system support. So I cannot use Erlang for most of the stuff that I do at Heroku, even though sometimes I really do wish I could. Web development, if you're doing API stuff or you're maybe making a basic web service and it needs to take a lot of requests, but there's not much of a sexy front end and it's actually much higher than a four. But for any overall web development, it's pretty low because templating, trying to get just any kind of basic business logic in there, those kinds of things. It takes quite a while to get that going. There's not a lot of support in the community there. CLI, horrible. Text mining, pretty horrible. So now Go. How many of you have been using Go? Oh man, I hope I see more hands next year. So Go, Go is pretty amazing. I've not thrown a nine on CPU. IO concurrency is fantastic. It acts like it's blocking, but it's not in the background. The IO is asynchronous. So as you have your Go routines running, they look like they're blocking, but they're not. They're all kind of just waiting their turn until something, in a fair way. System support is really high. It does some pretty great stuff for positive system support. Web, low, there really isn't that much there. I mean, they do have something kind of Sinatra-esque built into the core packages, but it's still templating. All that stuff really isn't there yet. It's not very mature and they're not really focused on that. It breeds itself as a systems language, not a web language. CLI, it's pretty high. And text mining for C. IO concurrency, one to 10. Depends on how smart you are. And how good you are. IO concurrency the same way, agility, give it about a two. System support, fantastic system support. Web, one. CLI. What's that? I'll get to that. So, I'll get to that. Trying to be fair. All right, so CLI and text mining three. So, C++, give it about the same thing, although it's, what was it higher? The agility in C++ is a little bit higher. Some of the garbage, there isn't really garbage collection, but there's nice things around that to kind of help you. You also have standard lib, which does a lot of really nice things for you, like string manipulation and stuff, where C doesn't have any of that. They come standard with it. Node, Node.js. How many of you are doing Node.js here? All right, cool. So, Node again, low on CPU, it's single threaded. IO concurrency, extremely high. Agility, pretty high. I mean, it is JavaScript, right? There are some boundaries in the things that you learn, encourage you to get past with the asynchrony of it. But system support is really high with it, web, whatever. So, text mining, yeah. Shell. Ryan's gonna talk about Shell tomorrow. I highly suggest all of you show up for that talk. But IO concurrency, pretty low. Agility, the CPU concurrency, that's not applicable. And you'll think you'll learn more about that tomorrow in this talk. System support, obviously it's high. And web, for text mining. So, text mining is actually pretty awesome. I mean, if you're using SED and all those things, but that's not really Shell, that's SED, right? It's probably a lot. So, JVM, CPU concurrency. IO concurrency, agility, it's been so long because I've worked in it, I don't really remember. System support, it's pretty low from what I remember, web, pretty bulky. The CLI results haven't booted yet. And the text mining, text mining's pretty bad too. And Perl. So, the reason I had text mining on here was to talk about Perl. Perl is by far my favorite whenever I'm doing any kind of like heavy data mining and text files or any kind of digging around a system and searching for things, that's why ACK is written in Perl. It's fantastic at things like that. And yes, you actually can write very pretty Perl. I've seen some really, really amazing examples of Perl. So, I do enjoy Perl sometimes. So, for some things. But, I'm gonna move ahead. So, let's talk about you because all of you are special. What does being a polyglot look like? It's pretty easy. You're a badass and you're dashing. Because a seasoned polyglot, speaks the native language and keeps up with its culture, right? Just because you know a couple languages and you learned it over the weekend doesn't mean you can just stop paying attention to it if it's something you plan on continuing to use. You wanna keep up with what people are doing with it to keep that fresh in your head. That also helps when you're in other languages as well, which I'll get to. So, you can obviously do this in the IRC, in the mailing list, the docs, or in bars with other people. If for those of you who don't do much functional programming, there is a group in San Francisco called Functioning Alcoholics, or Functional Alcoholics. They meet once, I think, a month or something. And a lot of really great guys, but they're working on some pretty amazing things. But just to be around them and to listen to them and kind of absorb what they do and how they think is pretty valuable. So, and borrows from many religions but sticks to your own, right? You don't wanna just say like, oh, I'm a Ruby programmer, I'm gonna do everything the Ruby way. When I'm in go, I'm gonna do it the Ruby way. When I'm in Erlang, I'm gonna do it the Ruby way, right? When you're in other languages, you kinda wanna blend in with them, right? But you don't want to also get sucked into their way of thinking and then be, oh, I'm an Erlang guy now, I don't wanna do anything the Ruby way. When I go to Ruby, I'm gonna do it in Erlang. You see what I'm saying? You kinda need to spread yourself around a little bit there and be a little more open-minded when you're moving from language to language. But the most important with this is when you have more of these tools under your belt and you're keeping up with them, you can code with deadly force. When you're in environments where you're limited on resources, maybe all you have is VI and the C compiler and you need to get something done right away and maybe have Perl installed, right? You know these things well enough that you can quickly adapt to that situation and you're in the heat of a fire and you can perform. You can get in and get the job done without having to say, oh, I don't have my MRC on here and I don't have ACK and I don't have any of this stuff. I'm just gonna take me forever, right? Like you need to be able to do without those things as well, even though it is good to have those things on your local development. So what does this look like? Oh, it looks like this. This is you in the heat of battle. That's you compiling C++. So also AC's in polyglot knows the best and simplest tools for the job. It's kind of reiterating back on the last point that I made, but you're also seeking knowledge about new ideas and old ideas, right? During the keynote, he was going through an old textbook. So that's really important to do. I've also found myself where I take the O'Reilly Ruby in a nutshell book and flip through it out of just usually it's like, I'm kind of bored and I just grabbed this book and I flip it, oh my God, that's right, I can do that. That's so awesome. And you remember all these little things that you forgot about because you're using all these big libraries and stuff and it's kind of hidden from you that. So, seeking new knowledge, let's learn, shall we? This is one of the things I get the most whenever I talk about a new language. If I'm interested in something, like when I got into Go and when I got into Erlang and when I got into other languages, I would talk with people and try to share my enthusiasm and excitement with them and they would say, yeah, I read the docs. That was, yeah, that's pretty cool. I don't really have any problem that that solves though. Well, actually you do. Most of the things you're doing in Ruby can also be solved in another language. They'll be solved differently, maybe not better, maybe for the worst, but you'll never know until you try. So one of the first things I try to do whenever I'm learning a new language is take something that is, I'm very familiar with, and I port it into that language. So the first step to learning something new for me, and I find very valuable and helpful, is to take something that I've done and port it into a new language. So I mean, you see this when Node came up, everybody was fighting to make the Sinatra clone because people are used to it. I'm not trying to boast or anything. It's just, it's a very simple little basic system with basic principles, and it's easy to get your head around and to take over to this language and try and apply it in their community and in their way, but borrowing some of the ways that we do in Ruby, right? So one thing that's pretty easy to do is a Redis client. How many of you have ever just for fun just written a Redis client just to see if you could do it, right? I highly recommend all of you do that here. I mean, I'm not saying build your own and use it in production, right? Like you probably want to use the one that most people are using, it's more of a canonical source, a canonical place and canonical repo gem that other people are using and is production ready, but it's definitely a fun experiment, right? It's a very, very simple protocol. Again, people have ported Sinatra, that's something else that I'll try and do sometimes just to see if I can get away with it in the new language and if it comes out looking similar to the way it's done in Ruby, but hell, why don't you just port Redis, right? Yon did, how many of you know Yon from CouchDB? All these guys? Okay, yeah, Yon rewrote a very basic Redis server in Node.js. That's an excellent way to wrap your head around something. You're including networking, you're including protocols, you're including, I mean, there's just, in data structures, what a great way to take something that encompasses a lot of things and take it into another language and try and see if you can produce the same result. And while you're doing that, read. Read through the mailing list, right? And I'm sorry, let's go back to that last slide. That's, the important is your way first. When you're porting it, do it the way that you would expect to do it or the way that you would, it's okay to take all your Ruby thoughts and the way you think in Ruby and take it over there and do that, but do it your way first, do it quick, try and get something complete out and then once you've done that, while you're doing that, read through the mailing list, pay attention to what people are talking about and the problems that other people are having. Read the docs. Every morning, I've been doing a lot of work and go recently and every morning before I start doing go, I like to skim through the document, the package documentation and just click through and just reread some of them just so I can kind of keep my memory and keep it, you know, fresh in my head. So as I'm working in the language, I can remember, oh, that's right, there's a package for that. I don't have to write that on my own. Also in IRC, it's good, this can be kind of distracting though, keeping IRC open all the time, but it's good to kind of just kind of idle in there and just see what people are talking about, what's going on. And while you're in there, ask questions. It's okay to ask questions and some of the things, because you want it also, once you've ported it, you want to do it their way next. Now try and do it their way, the idiomatic way, right? Like in Ruby, we have our own idioms. There's a certain way we approach, there's common ways of, or common problems that we approach a certain way and they, you know, just as in other languages they do that as well. So, and because they have different paradigms and ways of thinking, they have different idioms and they think a little bit differently and a lot of times you're gonna be like, that is disgusting. Why would you do that? And then when you say that in a much nicer way, they'll explain it to you and you might think, oh, that actually does make sense. That was a good call, right? So again, they're paradigms. What would they do? Ask them questions. Hey, listen, okay, I've ported this over, let me give you this hunk of code so does this look right? Is this how you would do it? And then they'll come back and say, I don't know, I might actually change this and do this and then you can learn from them. That's how all of us learned Ruby, right? We just started digging around and asking a lot of questions. But we've been doing, a lot of us have been doing it for so long that when we go into another language, we forget that that's what we were like, long ago and now we're going to do it again and you kind of feel naked and vulnerable. Where as Scott Jacone, you're not in an action position, right? So anyway, you had to have been in Ireland last week. That was hilarious. All right, so. Also answer questions. Once you start, you know, you're going to ask a lot of these very basic questions and you're going to notice that other people are coming in asking these questions as well. Start answering them because there's someone who is tired of doing it already, right? They've been doing it long enough. Pick that up for them, they'll love you forever. So that those next questions you ask, they'll come and start asking, you know, they'll be more than helpful with you because they're not so bombarded with the basic questions that they have to keep answering over and over again because you were helping them with that. And also notice. One of the things that you're going to notice or that I noticed when I was doing, when I started getting more and more into other languages and working in more than one at a time or more than three at a time was when I went back to Ruby, I started realizing that my Ruby code started looking different. I started writing things differently. Whenever I had multiple returns coming back from a method, I started using an underscore instead. Where did I pick that up from? Erlang, right? Take any Erlang, anyone who's done Erlang and then go look at their Ruby code and it starts, you'll start noticing that they're doing that. I also started using functions a little bit differently. I started doing things in a little more of a functional way in Ruby, right? So that was really, really kind of cool to me. I started noticing that and it's actually your code starts to get better, right? Or sometimes worse, depending. So the other thing is, I'm not gonna get through all this. All right, interoperability, as you do this, remember the Alamo, all right? When you're trying to talk between multiple languages or remember all the bad decisions that were made and the things that had came up? There was Korba, the common object request broker architecture. This created was based on the interface definition language. It looked a little bit like this. There was a lot of UML. There was very expensive packages that you had to buy. But what you noticed was this was one of the first or one of the more modern enterprise approaches to a standard way for the OMG group. That is actually the name of the company that invented this. That is the acronym they use. It's omg.org, go to it. I'm not lying, all right? But it enabled software components with multiple computer languages to start talking. And what is that? All right, who remembers this one? Right, Symbol Object Access Protocol started getting a little bit better. We went to text. We started sending text over the wire instead. And it was more for remote process to communicate with each other. But here were their hopes. Reusable code, interoperability between different languages across the network, right? How many of you ever had to did C sharp or Java or tried to get those two to talk with each other via soap? Well, you dropped the soap because it doesn't work. It never really worked. I could never ever get it to work. It was awful. Unless it was a .NET thing talking to a .NET thing, it would work great. But if you had a .NET thing trying to talk to Java, Java would go, I don't like that way of doing it, Microsoft. And Microsoft would say, but we invented that way of doing it. And that's not according to spec. And that's how we do things. And then they would fight. So there was no standard. There was, they tried to get a standard, but it never really happened. But that was the hope, that they would have a nice standard. But it would also be contained, right? You'd have these web sphere and things. And they would all be contained in these containers and you could just move them around. And it would also be manageable. Turned out, it wasn't. What happened? That happened. I mean, have you ever seen this quote before? That's one of my favorite quotes. All right, that's what happened. So, why did they fail? Because it required expensive licenses. Expert consultants that charged a lot of money. I know because I used to be one. Valuable limited shelf space. How many of you ever owned a Rocks book before? Yeah, like leaving my job and going to the next one and taking my cube with me was worse than moving my apartment. Like it was just like, it's so heavy, I had all these huge books. And heavy code generators. But that's not always bad. Today we have JSON. The pros of JSON, in my opinion. Simple languages and it's independent. Independent primitive data. Independent primitive data types. I don't even know what I meant by that. What's that? Language independent. I can't see it from this angle, sorry. All right, and the, but the decoders are easy to code by hand. This is one of the nice things about JSON and SOPE you would never, ever attempt to decode a wisdom by hand, right? Like you would have to use a code generator to do that. Plain text, it's human readable. Like an introspect to take a look at it and go, oh, there's your problem right there and fix it, right? Not so much easy and things like SOPE Corvo. And every language already has a decoder for this built in or in a nice library, you know? Or has a very nice library that everyone already uses. So the cons of it were it isn't binary safe. And it isn't wire efficient if that's really a problem for you. Most of us, it's not a problem. It doesn't really make any sense to worry about packing it down as tight as possible. Then there's also BSON, or that VJSON, I'm supposed to be BSON, sorry. So the pros are, it's the same as JSON. It's wire efficient, but it's not human readable, right? So there's also REST, which is binary. Every language has a client for it. There is a standard. There is a, pay attention to this, a mechanism for handling multiple data, multiple formats of data, and caching. And again, it's human readable. REST cons, not every language has a client that deals with some of the more advanced features or has the specs continue to grow. Older clients don't always support it. Ruby, I mean, trying to get, how many of you have ever tried to like use the net HTTP library to communicate SSL in Ruby? Yeah, see, it's not always easy, right? So, web servers don't always conform to spec. So you'll notice that sometimes in GenX, there's certain things with Apache in GenX where they start to collide. I mean, things like chunk encoding sometimes, get in your way, right? And things like varnish start to do that as well. Start to eat. Or as varnish, I like to call it the HTTP shredder, because if you try to do anything outside of its basic spec, it will shred your HTTP. Caching proxies, there's caching proxies. But on another con, it handles multiple data formats. So this brings us to Wars in Space, where you have X and L versus JSON and others where no, this is the data format we should be communicating and this is the schema we should use and this is the, no, this is the schema we should use and talk, right? And what I'm scared is, could happen, is we could wind up with soap again, right? That was what it was trying to solve. So if I'm gonna give you a message, just please don't fight too much about it, because otherwise the supervisor or the superintendent will come by and say, that's fine, we're going back to soap. And remember that poke other languages in the eye. Learn a lot of languages, poke them, test them, benchmark them, figure out everything you can, port things, see if it's faster or slower, more memory efficient, whatever. Those are really important things. Like get that feeling yourself, I'm almost done. And twist the arms until you get the truth from each language. Don't really go based on what your friends are telling you, whatever, what else is telling you. But also learn from those languages. Understand them and their idioms. Don't try to always bring your preconceived notions into their community, into their realm, right? They'll hate you for it. Cross-pollinate, take what you learn, bring it back into Ruby or whatever language you're moving to next. And understand Unix and also keep things on the wire very simple, JSON rest. If it can't be decoded by hair, and seriously consider doing something that can be, learn, read, repeat. Thank you.