017 JSJ CoffeeScript with Jeremy Ashkenas

Download MP3



  • CoffeeScript
  • Backbone.js
  • Underscore.js
  • Pluralsight
  • Document Cloud
  • Compiles to Javascript
  • Cross-compilers for Ruby, Python, etc.
  • Haxx
  • Ruby on Rails
  • ES5
  • i.tv uses it full time
  • May not be ideal for writing Node.js libraries
  • Node.js
  • NPM
  • CoffeeScript NPM module
  • CoffeeScript compiler is written in CoffeeScript
  • jyson
  • QUnit
  • testing in CoffeeScript
  • Jasmine
  • Arrow notation
  • Does arrow notation encourage writing anonymous functions?
  • Not all anonymous functions are anonymous
  • CoffeeScript uses function expressions
  • Thin arrow (->)/Fat arrow (=>)
  • Haskell
  • Do you need curly braces?
  • You can use parenthesis to enclose your function
  • Linguistic Relativity
  • Chaining functions & comprehensions
  • Implicit returns
  • Ruby
  • Dave Thomas
  • Lua
  • es-discuss mailing list
  • JS-next implementations in CoffeeScript
  • IE6 is the lowest common denominator
  • Debugging CoffeeScript (in JavaScript)
  • Source Maps
  • Throw syntax errors as early as possible
  • Compile time errors for strict mode problems
  • Strict mode
  • Compiling to readable code
  • Minified Javascript
  • Javascript Prototypes
  • Class definitions in CoffeeScript
  • Memoization
  • Inheritance
  • Associations
  • super
  • Node.js inheritance
  • Mixin based multiple inheritance
  • V8 - V8 JavaScript Engine, JSJ Interview
  • Compile to specific targets
  • Python
  • CoffeeScript allows you to evolve the language without breaking the web
  • ChromeFrame
  • JavascriptLint
  • Node.js Event Emitter
  • IcedCoffeeScript



CHUCK: Hey everybody and welcome to episode 17 of the JavaScript Jabber Show. This week we are going to be talking about CoffeeScript with Jeremy Ashkenas. And Jeremy is here. How are you Jeremy? JEREMY: I'm doing good. How are you all doing? CHUCK: Good. It’s been a few episodes since you’ve been on; do you wanna just give people a quick introduction again? JEREMY: Sure. My name is Jeremy Ashkenas and you may know me from such open source projects as CoffeeScript or Backbone.js or Underscore.js. And I work for the interactive news team at the New York Times and I used to work at -- full time, I still work on it sort of part time -- on documentcloud.org, which is a knight foundation funded project where we open source a lot of JavaScript stuff. CHUCK: All right. We also have AJ O'Neal. AJ: What's up? CHUCK: We also have Jamison Dance. JAMISON: Hey guys! CHUCK: And then we are also going to be introducing a few new regular panelists; we have Joe Eames – who’s been on the show before. JOE: Hey. CHUCK: Do you wanna give a quick introduction, Joe? JOE: Yeah. I'm the creator of testdrivenjs.com, which is a website devoted to bringing test driven development to JavaScript and I’m also an author for Pluralsight. CHUCK: Awesome. And we also have Tim Caswell. TIM: Hello! CHUCK: Do you wanna introduce yourself for us? TIM: Sure. So, I am an open source addict. I write code because I can’t sleep sometimes. I've recently worked a lot on Node. And in the past, I've worked with Jeremy on CoffeeScript and Backbone and other parts of Document Cloud. CHUCK: Awesome. All right so, let’s jump in and talk about CoffeeScript. Jeremy, do you wanna give us a quick introduction to what CoffeeScript is? JEREMY: Sure. CoffeeScript is just sort of a fun thought experiment which… and there's a lot of languages that compile the JavaScript. If you haven’t checked it out, there's a great page on the CoffeeScript wiki where some folks have just put in all different kinds of languages that folks have written and compile in the JavaScript. So there's the usual things that you'd expect, like things like Python and Ruby and Haskell and other scripting languages that sort of cross compile over. There's interesting things like statically typed extensions to JavaScript or security enforcing JavaScript or special, optimized versions of multi-targeting programming languages like Haxx. (I don’t know how to pronounce it), where you can compile it on different runtimes. There's visual programming tools and all kinds of things. So the idea with CoffeeScript is sort of not to go in that direction and to take a different idea or a different semantic or a different runtime and implement it on top of JavaScript because there's lot of great languages that do that kind of thing already. The idea with CoffeeScript is to take the core… sort of the core things about JavaScript that are characteristic to it -- sort of the core nature of JavaScript -- and then come up with a way of writing it that exposes what it is in a simple way. So part of the goal is not to have any special semantics being added by the CoffeeScript compiler just to take advantage of what JavaScript already offers, but find an easier way to sort of write it. And so, it’s a funny premise, you know, part of the premise is that it can’t really do that much for you, right? If it’s anything that’s technically interesting, CoffeeScript probably can’t do it because you have to implement stuff on top of JS and we have to sort of try to be very lightweight. But it’s also been interesting that I think because of that restriction, it has turned out to be quite successful. So I don’t know. I think these numbers are pretty askewed because of GitHub’s methodology but it recently cracked in to the GitHub Top Ten Programming Languages lists -- knocking off Objective C -- which is pretty crazy. I think most of that is auto generated template files in Rails projects, but who knows? It’s doing decently. So there's this everyone who's worked with JavaScript for a long time who does JavaScript day to day knows how undead of a language it is, right? So it’s a beautiful language, it’s got a great heart, there's lots of interesting core pieces to it in terms of its flexible object model and it’s nice semantics where you can build your own object orientation. But at the same time, its usability is not where it should be, right? It’s basically hasn’t changed. The way that we use it today basically hasn’t changed in 10 or 15 years. Despite great things like ES5, you can’t still take advantage of it if you have to target major browsers or if you wanna write JavaScript that runs everywhere and that will run in IE7 as well as it runs on Nodejs. So I think CoffeeScript is sort of hitting that sweet point for a lot of folks who want a nicer way to write the JavaScript that they already have to write. CHUCK: Right. So I want to ask the other panelists; how many of you guys are using CoffeeScript or using it on a regular basis? JAMISON: So at iTV, we actually use CoffeeScript full time for all of our new code -- and we love it. There are a couple of grumpsters when we first started, but everybody is a big fan of CoffeeScript now. So, you rock, Jeremy. Thanks. [Chuckles] JEREMY: Cheers. CHUCK: So, I use it a lot. But I'm using Rails and Rails uses it by default, so I typically use it just because the files are already set up to precompile from CoffeeScript to JavaScript. So it works out pretty well for me just to use it in the asset pipeline that way. And you know, it’s nice in a lot of ways for writing your JavaScript. Is anyone else using it on a regular basis? TIM: I actually don’t use it, but that’s the most part, I'm writing Node libraries, so I only have one runtime to target and they are libraries; so the less dependencies, the better. But I mean, yeah I can definitely see the need for applications where you have a certain style of programming and you don’t like all the boiler plate. It can be very handy. JAMISON: And I think doesn't NPM have a field that you can put to like pre compile your CoffeeScript into JavaScript before you publish? I think I saw Isaac tweet about that or something, because somebody was complaining about CoffeeScript and NPM and he… [Crosstalk] JEREMY: Well, that’s actually one of the really funny things. So I think currently, CoffeeScript is the… if you look at search.npm.org, you'll see the CoffeeScript is the second most dependent on NPM module as dependency -- which is kind of crazy because really, if everyone is doing it correctly there should be a zero NPM modules with CoffeeScript as a dependency, right? You are not supposed to depend on it at runtime; there's no need to. You can just precompile it into JavaScript before you publish your package. So, that’s funny. TIM: Unless you are like making some special CoffeeScript add on that needs it on runtime or whatever. JEREMY: Yeah unless you are making a special CoffeeScript --- or something, then there's no real reason to depend on it. So I don’t know what all those packages are doing that they think they need it, but there's quite a few. CHUCK: So what dependencies does CoffeeScript have in order to compile? Is it just JavaScript or is it… [Crosstalk] JEREMY: it is just CoffeeScript actually. So it’s written in itself and it’s been that way I think since 0.5. It’s got sort of one major external dependency which is jyson -- which is a parser generator maintained by Zach on GitHub. And it’s just a nice JavaScript parser generator that happens to generate efficient parse tables; it does bottom up parse tables. I think there's --- one modes and then a few other types that you can opt in to and you give it a ---- and it gives you a back parser. And it’s fast, which is the main thing. There's lots of nice JavaScript parser projects with good APIs that can’t parse particularly quickly and sort of done all the work theoretically and in the JavaScript implementation to make it very, very quick for parsing. Takes a while to generate a parser, once its generated, its quick to parse. CHUCK: Nice. So one another thing I'm curious about -- and this is kind of up Joe’s alley here -- is have you seen people writing tests in like QUnit and stuff using CoffeeScript? JEREMY: Sure. Actually I think one of the things that people sort of start with; people who are evaluating it or looking at it. I've heard a lot of stories about folks who aren’t using it for their app, but is using it for their Jasmine tests, just because I think when you have… you try to make those tests as reasonable as possible, like you are giving it a string and you are passing a function all the time is always like name this thing, pass a function; name this thing, pass a function and people don’t like typing “function, function, function”. So that’s like the first little gateway drug into trying CoffeeScript more is to redo their jasmine tests with it. JOE: Interesting. CHUCK: So, that’s one thing; you could bring up typing the keyword function over and over again as opposed to using the arrow notation and I've heard some people complain about it and other people go crazy over it because they love it. What kind of reactions have you guys heard regarding the arrow notations – that’s the -> or the =>. JAMISON: So I remember Joachim, when used to be on the podcast, he talks about how it encourages the use of anonymous functions. He was kind of grumpy about that because who likes anonymous functions? And I find myself doing that a lot too. I'm still not sure how I feel about it. I know its way better to write… or way easier I should say to write the code like that and since it’s easy, I do it a lot. I don’t know, I haven’t been really… [Crosstalk] AJ: You should feel dirty. That’s how you should feel. CHUCK: [Laughs] So the thing is though is for me, it feels a little bit more expressive because my brain can parse that just as easily as parsing function, and it kind of indicates there's something that comes after this that means something and so my brain can just parse that and say, “It’s a function; whatever’s nested here is part of this function.” And so, is encouraging people to write anonymous functions just something that comes out of it maybe a little bit more expressive? JEREMY: I think there's a couple of things to get into here; one of which is it’s not so much about the anonymousness of the functions, like that isn't really the issue because especially the modern browser engines can tell you the name of the functions even if it is technically anonymous function -- whatever the property is attached to -- they'll have that in stack trace. So, many more functions are named than you would think. The real issue with the semantics of it is that JavaScript you have these 3 different types of function objects; you have function declarations, you have named function expressions and you have functions expressions. And semantically, they all behave slightly differently. And it’s problematic because there's bugs related to function declarations and name functions expressions in Internet Explorer that can trip you up pretty badly if you happen to run into them. And it’s also weird to have these three different types of objects that behave slightly differently, but are basically the same thing. So that’s one semantic simplification that CoffeeScript does is it says, “We just wanna have one type of function. We don't have three different kinds that work differently.” So we just have function expressions which are the flexible kind, right? A function declaration, you can only use sort of procedurally at the top level; you can use that as an expression in a larger part of your program. You can’t pass a function declaration as a callback, for example. It will be common name function expression if you do that. So we just say, “Throw those other ones out. Let’s just do function expressions. Keep it simple, not have different types of things to worry about.” And so that’s one piece of it. Then the other piece of it is that thin arrow/fat arrow distinction, which is maybe being talked about maybe it’s going to make it into the next version of JavaScript if they end up adopting it. But this idea that in JavaScript – and you'll know this if you do a lot of jQuery or prototype, where whenever you need to bind the this value of a function to stay the same, even as you are passing off the function as a reference into an options object or into a callback, then you have to bind that function to the current value of this – so you do that with function.prototype.bind or  you do that with jQuery.proxy or you do that underscore.bind or you write var self = this. There's a million different ways of saying, “I want this to stay the same.” And CoffeeScript gives you that thing where you say, “Give me a fat arrow,” and the fat arrow means that this, at the time you write the function does not change. So even if you pass it off and store it in a different object, the this stays the same. So I think that’s sort of the interesting shift with the arrows, you have the visual difference, which I don’t think is super important between typing out function and typing an arrow. But then you have the simplification of not having two different kinds of function anymore and you have the ability to very easily say, “Give me a function where the value of this doesn't change.” JOE: Hey, I'm curious, why did you choose that particular arrow syntax. Where did you pull that from? JEREMY: So, sort of visually and symbolically… I mean this is one of the things that I actually was debated a great deal, like all of these sort of little visual things on the GitHub on the issues if you wanna go look at it in the early versions as to what the notation should be. But the basic idea is just that with the function, the input points to the output, right? The input goes in one side and your value is on the other side. And so visually, you have this thing where you can see the left hand side is the input and the arrow pointing to the right hand side. And because you don’t have to write “return” in CoffeeScript, the value of the expression on the right hand side is the value of the function. It’s sort of this nice little that you have where it’s just literally input points to output and you can see how it works. JOE: But you didn’t pull that from any other language? JEREMY: I think we did. I think that doesn’t Haskell do something similar? I mean Ruby uses arrows for a different purpose, so we weren’t sort of following off of that. I think the main idea was just to have the arrow to be a pointer. TIM : Right. At the time, I don’t remember how much if you already had this syntax but I’d been doing OCAML and it has a similar syntax. JEREMY: Yeah I haven’t used OCAML, but I think it kind of makes sense. JOE: Yeah I think… I do some .Net and .NET has the same exact syntax for its lambdas and I think they pulled that from OCAML. So just curious if they have a common parent for that syntax that express visual representations. JEREMY: It’s probably floating around and people probably see it and don’t realize they’ve seen it and it comes back up. And I’ve heard other justifications for it too where with the thin arrow, people say that it looks like a lambda, like if you sort of take the thin arrow and twist it on its side, it looks visually kind of like a lambda, so that’s another source. JOE: Yeah. I've noticed when I was learning CoffeeScript that I didn’t find it to be that difficult at all to make that jump and feel like I don’t need the function all the time, simply because coming from having done .NET programming with lambdas seemed very natural to me. JAMISON: Can I just say it feels harder to go from CoffeeScript back to JavaScript?[Chuckles] Than from JavaScript to CoffeeScript. There’s weird stuff in JavaScript now. CHUCK: I think it’s interesting because syntactically, you can get away with a little bit more with CoffeeScript, and so, for me going from Ruby to CoffeeScript is much less of a leap than going from Ruby to JavaScript. And really what it comes down to is in Ruby, you don’t have to include the curly braces or the semi colons and things like that. And so I wind up forgetting them JavaScript and then my code does funky stuff or it won’t run because it needs those curly braces or something. And in CoffeeScript…  I'm just saying just in programming mode, I don’t have to make as bigger transition. I'm not saying that its right or wrong, it’s just the way it is. AJ: I was just going to say, I think the curly braces is a little difficult for me when I go to read, because I like some sort of visual cue and I think it’s okay to get rid of some of the syntax, because obviously we don’t need a lot of it; a lot of it is just superfluous. But I do like some syntax to like clue me in to what is going on, and that's where I found it to be just a little confusing is understanding when the function is being invoked because it’s just like function name space, space, space, space, space. CHUCK: You know, I've heard a few people say that they would like to see some kind of closing at the end of functions, like in end or something keyword. JOE: You know, I agree with what AJ is saying about visually, it seems a little bit difficult to parse through, but I think that the jump from a more higher common server side language into CoffeeScript is a bit easier than it is to go into JavaScript because I think JavaScript is such a different mindset, and CoffeeScript is kind of like pulling that mindset back to something that’s more typical; something to Java, even if the visual representation looks quite a bit different. AJ: [unintelligible] words. [Laughter] AJ : Something that’s close to Java, that’s a good thing? JOE: I'm not saying it’s good, I'm saying it’s more familiar with people that are doing a server side language. [Overlapping talks] JEREMY: So one of the things is that you totally can delimit everything in terms of its begin and end in CoffeeScript and if you prefer that style, then you definitely should. But instead of having do and open curly, close curly, it’s easier because you could just use parenthesis, right? Parentheses are the logical way to group operations; whether that’s a block of code, whether that's the arguments to a function, whether that’s the operators inside of the complex piece of Math, you know, you can use the parenthesis group anything you’d like in there. CHUCK: So you can actually put parenthesis around the body of your function? JEREMY: Sure. JAMISON: It’s because everything is an expression, right? So everything will. Isn't that why you can do that? JEREMY: I guess that’s sort of part of the reason. Yeah. Parenthesis can just pop right in. JAMISON: So I wanted to ask you about… I posted this link, somebody posted this thing on Hacker News about linguistic relativity, about how the languages that you speak affect the way you think about stuff. Do you think stuff like that applies to programming languages where different languages will affect the way you approach problems? And if so, how do you think CoffeeScript affects how people approach problems as opposed to JavaScript. JEREMY: That’s a very good question. I think the whole notion of the Sapir-Whorf hypothesis and linguistic relativity is one that’s much debated over and much argued over in academic circles and everyone started the anecdote about Eskimos having 50 different words for snow, but how true is that really as the stories. But at the same time, there are certain tribes that don’t have the cardinal directions, but only have left and right and have to express how to get around in terms of left and right, instead of north, south, east and west. So there's a little bit of that going on in human languages and there’s maybe less than folks thought at a certain point in the 70s and 80s. But at the same time, in programming it’s very interesting, because in programming we know that well all real programming languages being to complete are able to express the concepts that you can express in any other language, right? You can express in JavaScript all of the semantics of Haskell should you choose to or vice versa. But that doesn’t mean that people do on day to day basis and it doesn’t mean that the programs that you write tend to. And I think as programmers, we also believe very strongly in the linguistic relativity in our programs. We know that if we write a program in closure or we write it in Ruby, the way that it functions is probably going to function very differently. And we care a lot of the way that it functions because it’s not just about the end effect, right? It’s not just about the way the program does when it runs, it’s not just making a web app so the web app looks a certain way, but the behind the scene stuff really matters in terms of how you are going to work with it and maintain it and refactor it and how easy it is for you to hire people to understand the code that you wrote and work at it with you. So I think linguistic [inaudible] is more interesting questions in terms of natural languages. And CoffeeScript over like the [inaudible] about that because the semantics are just JavaScript semantics. So basically, the things the things that you can say in CoffeeScript are the same things that you would say already in JavaScript -- just it’s easier to write -- and hopeful it’s easier to read. JAMISON: But even then, I find myself writing much different code in CoffeeScript than I would in JavaScript for the same problem. Like even if it so similar, yeah. JEREMY: How does it change for you? JAMISON: I think I do a lot more. It sounds weird because JavaScript seems like a more functional language, but I do a lot more functional stuff in CoffeeScript when I'm chaining like transformations together. Like especially the comprehensions, so instead of doing a for each loop and then doing stuff in that and then saving the results -- or doing, I don’t know stuff to a lot so, I don’t know, yeah I just use comprehensions to chain stuff together a lot. I think part of that is again from the “everything is an expression” idea where you can chain together the results of expressions. I was talking to a guy on our team who’s like an old Ruby programmer and he says that part of the reason why in Ruby you have implicit returns is that because you think of your functions as just transforming some input, so you are not doing something and then building up something and returning it; you are operating on an input and then it just kind of streams out of the function. So I think that’s something that I think about more in CoffeeScript than in JavaScript. JOE: So can you clarify what it means to be an “older” Ruby programmer? So he's at least like 10 years old? CHUCK: [Laughs] JAMISON: Yeah. He's like pre-Rails. I don’t know. He's old school. CHUCK: Pre-Rails. He's been coding since before 2004. JAMISON: No. he's been coding since before that, but he's been doing Ruby for a long time. JEREMY: Ruby started 1994 or something? I don’t remember. Early 90s, right? JAMISON: Yeah. Around the same time as JavaScript. CHUCK: Yeah it didn’t really come to the US until 1999 or 2000, maybe 2001 something like that. When Dave Thomas picked it up and went with it and got excited about it. JAMISON: Tim, were you going to say something? TIM: Yeah. So speaking of other languages, I've been working a lot with Lua in the last few months. I don’t know. I just want a different VM to play with on the server. And I am amazed at how similar it is to both CoffeeScript and JavaScript. And they are completely independent as far as I know, I mean development plans. It was made in South America because something about the couldn’t use US technologies. And as JavaScript evolves, it looks more and more like Lua. They have a lot of the same features. And I think CoffeeScript has a lot of influence on where JavaScript is going. Its interesting how we are all evolving to these similar scripting language. JOE: That seems true to me too. It seems like as CoffeeScript shows what JavaScript can be, I would imagine that people that are designing JS next are looking at that and saying, “Hey how can we make JavaScript better?” And this is a great plan of examples of how JavaScript can be better. Do you find that same thing too, Jeremy? JEREMY: I mean, it’s all a bunch of friendly folks, so if you wanna talk on the es-discuss mailing list, they are always open to ideas and suggestions on the proposals that they are working on. And they definitely… especially I guess Brendan Eich and Douglas Crockford have taken a look at it and played around with it a little bit in terms of looking at what it’s doing. I don’t know about how much of a direct influence it is because I think they are trying to sort of come from first principles at problems in JavaScript. So maybe there's just a little bit going on there. One thing that we do try to do in CoffeeScript is adopt things that we can from JS.next or es.next or whatever we wanna call it. So looking at the current…. So basically in wiki.ecmascript.org, you can see a whole bunch of proposals that going to the next version of JavaScript. Things that have been sort of agreed upon in general consensus already and things that are still more raw proposals. And a lot of the ones that are possible to implement in terms of Internet Explorer 6 and 7 semantics are things that we will try to do. So the structuring assignment, we do and default values and functions, we do and rest in spread parameters is something that we do with slightly different syntax that may or may not be changed, and then of course arrow functions -- some of the easier syntactic things. And there's tons of stuff we can’t possibly do that just isn't implementable in terms of JavaScript or isn't implementable in a simple way like maps and proxies and that sort of thing. CHUCK: Yeah that's sort of what I was going to ask is if you implement something in CoffeeScript that is coming up in es-next and it’s not necessarily available in JavaScript, I guess you’re building it out in the current version of JavaScript where you can and not implementing it if it’s not possible? JEREMY: I don’t quite follow. What was that? CHUCK: So, if there's something in the next version of JavaScript that you want to put in to CoffeeScript, do you only put in the ones that you can implement with the current available versions of JavaScript? JEREMY: Yeah. The ones that we can implement, the ones that we can implement simply, it can’t be too complicated and the ones that we can give good ideas, basically. But the main thing is that we are very concerned with just JavaScript that run everywhere, like all of the code that CoffeeScript generate should run on every JavaScript runtime. We should be able to use it on IE6, we should be able to use it in Node, we should be able to script Photoshop and Illustrator with it. And to that extent, all the stuff that’s being added to the next JavaScript doesn't actually affect us that much, because we won’t be able to use it as a compile target for however many year it takes for IE7, IE8 to finally disappear -- which I don’t know if it’s ever going to happen because of the whole windows XP thing. CHUCK: Right. So what is the least common denominator then? Is it IE7 or IE8? JEREMY: It’s basically IE6 is the lowest, lowest common denominator of stuff that has to work. But then again, IE’s JavaScript engine doesn’t change much between 6 and 7, so it’s basically the same thing all the way through. JAMISON: So I wanted to ask you about debugging. Debugging when I first started about CoffeeScript is probably my biggest hang up because you are not debugging in the same language, as you are writing your code in. And I feel like it’s gotten better over time as I've worked with the language more, but what kind of support does the language have for debugging? I know source maps are thing that’s being worked on; are there other things like that too? JEREMY: Yeah. So debugging… there's a few different angles. I mean, so clearly it’s a source to source language, so I mean, we don’t… it’s not a runtime, like anything that compiles to JavaScript is going to be that way. So if you wanna use something that is not JavaScript in the browser, you are going to have to fight with this one way or another. And there's several things we do to try to make it easier. So we try to throw syntax errors as early as possible -- which we don’t always do a great job of -- but we try to make it harder to have code that’s going to fail it at runtime but is going to compile. So we'll try to throw an early warning if there's something that is syntactically invalid. And there are simple things that actually give you a lot of pain in JavaScript, like trailing commas in your array, right? When you type trailing commas in your array, everything is groovy in Chrome and Firefox when you are testing; we you deploy it into production it blows up in IE and you never got warned unless you run JSLint on it. CoffeeScript doesn’t have problems with trailing commas. It will fix it either way; if you have it, if you don’t have it, it doesn’t really matter. It will always compile it down to correct thing for JS. So we try to catch stuff like that at compile time. We try to do more early warnings, so the latest version of CoffeeScript actually has compile time errors for lots of strict mode problems; things like assigning to arguments or to eval, things that are semantic errors at run time in strict mode in new engines are now compile time for errors for CoffeeScript, so we'll warn you upfront about that. And then the next step with compile time stuff is compiling your readable code. So put a whole ton of effort into making sure that the JavaScript that is produced by CoffeeScript is still generated code. We try to make it readable as we possibly can. So that means using nice variable names, writing it all out and indenting it correctly. And basically the generated codes, we are going to try to make it performant, so we are not going to write inefficient code just to make it a little bit more readable but we are going to try and make it as readable as possible. So when you actually have your JavaScript debugger open, you have unexpected null value in your function somewhere and you are stepping through the debugger the JavaScript code, that shouldn’t be painful. That shouldn’t be something that’s relatively comfortable to go through. And then the last piece of the puzzle of course is source maps -- which are now in Chrome stable -- which we want to support in the next version of CoffeeScript whenever someone has time to do a nice implementation and get that in, which we’ll make it so that you can basically have your CoffeeScript source in the browser. I'm personally not as super psyched. I mean everyone has been asking for source maps forever. I think personally think that having readable generated code is more important than having source maps, but source maps will be nice for folks who would wanna use them. For people who are not familiar, the basic idea for source maps is that when you compile your CoffeeScript, you also emit a file that tells a browser, for every line of CoffeeScript what is the line and character of JavaScript that corresponds. When they get error in the JavaScript, you can map it back to the source and show the original source. I'm not as excited about those because you're still going to have -- and this is less true for CoffeeScript, like CoffeeScript semantics are pretty straightforwardly one to one more or less with JavaScript -- but with other compiled JS languages, that have more complicated outputs, even with source maps, if you have an error deep inside of the JavaScript, there might not be any place in the source language that corresponds to that problem. So you know, for the really tricky things where you’re trying to debug something that doesn’t necessarily exist as such in the source code, I think that readable source is more important than source maps. JAMISON: The source is great too. It’s very readable. It’s funny when we first started using CoffeeScript here, there were a couple of people who are really upset by the mismatch between the language you write code and language you debug in. And we kind of talked about the whole C from assembly thing and how there are couple of other guys and everyone talked about how when C first became popular, people were just all up in arms about how you are writing code in a different language than you are debugging in, and it’s like impossible to know what's going on when you have a problem and stuff and how just tools got better and better. So it seems like that’s the promise of source maps, that if it really bothers you now, like the tools are getting better and better and people just won’t care about it. JEREMY: I think that’s definitely true. And I think it’s also, still again much more of a problem for other people than for CoffeeScript. CoffeeScript probably has like the least amount that. I mean, like you are going to have it for all your files if you are using CoffeeScript for everything, but it’s so much less than say Minified.js. Have you tried to debug Minified in production? That happens all the time. And that’s really what the source maps is for, right? Source maps will be insanely helpful there and they are going to be a little bit helpful for CoffeeScript, but not nearly as much as they would be for that. CHUCK: I have an idea for the debugging; just don’t write error prone CoffeeScript. Then you won’t have a problem. JAMISON: “No bugs-driven development.” I like it. CHUCK: There you go. AJ: That’s what we've got over here. CHUCK: Oh, is that what you write AJ? AJ: Yeah. Jamison [inaudible] no bugs driven development here in iTV with him. JAMISON: Yeah. I implemented it there. [Chuckles] CHUCK: Oh, nice. JOE : Very nice. JAMISON: It has some bugs in its implementation. JOE: I have a question related to not necessarily just the readability of the code the’s put out, but the form and structure. I was specifically looking like at the class declarations and the way that the prototype model, exactly how you use it which is a slightly different flavor than my typical way that I build my classes. I'm just curious, why you chose the different ways to output JavaScript? Some of them were stylistic, some of them were just personal preference, some of them are actually more efficient. JEREMY: Can you tell us briefly about the difference between how CoffeeScript is doing it and how you like to do it? JOE: I'm trying to remember exactly the way that they write out the prototype, it writes up the prototype and then it goes and it creates the function and then it goes and it modifies the types in every different function as a different modification. And I typically use an initializer on the prototype and then I have a different object that goes back in. it’s hard to explain over the… JEREMY: Are you talking about the saying class.prototype = an object literal and just assigning everything on the prototype in one big object? JOE: No. Not quite that syntax. It’s too difficult to explain over the mic. That’s just one particular example, like you know, exactly how you structure that prototype. I assume that there's a lot of other areas where you did the same thing. JEREMY: Right. So one thing that we are trying to do with the classes -- and maybe we should start this with the preface that classes in CoffeeScript are just the same thing as JavaScript prototypes the way that it commonly used, we are just trying to call… and if it looks like a class and walks like a class and acts like a class, and use it as a class, we are just going to call it a class instead of being dogmatic and saying that JavaScript has no classes because you know, constructive functions are basically class objects, the way that you use them in JS. So with that said, we are trying to be straightforward about it, so there's not really…. There's lots of things you’d like to do with JavaScript classes; you'd like to add maybe richer hooks so that you can tell when a class is being extended or mixed into; you’d like to add other types of features like -- we do a little bit this-- but you know, correct static inheritance, so you get the property off your parent class as well as the properties off of your parent class’ prototype and we try to keep it straightforward so that CoffeeScript classes are interoperable, with JavaScript prototype. And we try to keep it straightforward so that CoffeeScript classes are interoperable with JavaScript prototype. If you have a JavaScript prototype coming from a JS library that’s not written in CoffeeScript, you can have CoffeeScript class extend that and vice versa. You can have a JavaScript library extend your CoffeeScript class using a prototype without too much of a problem. So the basic thing is just to set up the prototype in a fool proof way, and that means assign the properties individually; don’t blow away the prototype objects that you lose that prototype chain going back up to its parent. And then the other cool thing about CoffeeScript class body is… so it was sort of controversial to add them and I don’t know if Tim remembers it but we had a bit of a back and forth over whether CoffeeScript should have a class queue or not or what that would mean or if it was worth doing. And one of the reasons why it ended up getting added was because we realized there would be a way to implement it where the entire class body is executable code. So, usually when you define a prototype in JS, you are either doing it as an object literal and it’s just simply the key value, or you are sort of assigning properties one at a time, and its very verbose; you are always typing, you know superclass.prototype.methodname = function and you are doing that over and over again. And so lots of people have to write functions that give them the sugar for doing it more easily. But we realize that because we have the compiler and we can sort of look at this class body  in the abstract syntax tree and work with it, you can have be executable code. So this is something that actually Ruby has and it’s pretty nice where inside my class body, I can do metaprogramming, I can wrap my functions, I can say I'm going to define a function on this class but I'm going to memoize it, I'm going to pass it into a different function that turns it into a memoized wrapped version before I use it. I'm going to put in an if statement, so I'm going to say, if debug define this method this way otherwise, define this method this way. And then instead having that check it at runtime, my class has been defined differently depending on whether debug is true or false and all kinds of fun stuff like that. And then also, well I guess I can get more into it but then the one last thing I should mention is that the context. So if your class is just executable code and you are defining keys and values that become prototypal properties, the value of this in the context of the class is the class object. It is the constructor function. So if you've inherited from a parent class, now you can have access to all of the stuff in the parent class. So you can implement fun things like Rails style has many and belongs to in CoffeeScript classes pretty easily because if your parent class has that function available .hasMany function, that’s going to be available as this.hasMany in the class body and you could use it to set things up like that. JOE: So would you consider your implementation of classes to be a best practice for JavaScript developers versus say, assigning an object to the prototype? JEREMY: No. It goes slightly beyond that. So I think it’s the basic best practice of creating a new constructor. So basically when you set up a prototype chain, you have to make an instance of your parent class to use set as your prototype but you don’t wanna call the constructor function. So there's a little bit of shuffling that you do if you wanna do it correctly, because the constructor function could have side effects. You could be launching the nuclear missiles or running some code you can’t take back if you actually call the constructor function. So there's a little bit of shuffling you do where you make a new empty function, you make a new instance of it, you assign the prototype and you swap that into place – and that is the sort of the best practice for setting up prototype in JavaScript. And then we do couple of extra things; one of which was the static -- we copy the static properties from the parent class -- which is totally optional. We wanna do it so we can get that sort of has many meta programming in the executable class body, but if you were doing that, you don’t need it as much. And then the other thing is that we assign __superReference and that's so that CoffeeScript can call super, has a super keyword so you don’t have to know about the name of your parent class when you are writing functions and those are the two extra things that you don’t need to do. JOE: Do you guys see a lot of people using inheritance in CoffeeScript? JEREMY: I don’t know. I feel like I don’t see enough of other people’s CoffeeScript to know. I know I certainly use it. JAMISON: We use it a lot in Backbone stuff -- with views and models and stuff. We have like base super class views that do garbage collection things to cleanup events and stuff like that. That's probably the area we use it the most. JOE: Do you have more than one level of inheritance, typically? JAMISON: No. We haven’t yet; just one. JEREMY: Yeah. I think [inaudible] is pretty common, right? You have a whole bunch of different object types that are vaguely similar and that you want some sort of common functionality shared amongst of them. And especially, when you want to be overwritable, then that’s where it’s really useful. TIM: I find in Node programs that I often inherit from event emitter or stream for my domain objects. Because if you inherit from the event emitter, suddenly your object can emit events and it’s really handy. And Node has this built in utils that inherit, which basically does the same thing, I mean it’s nice that you can just declare it in a very Rubyesque function body or class body. JOE: So is there a way to do basically mixins and get sort of multiple inheritance going with CoffeeScript? JEREMY: I mean and with JavaScript, right? So that's where the standard… actually that’s how any in JavaScript is you’re just mixing in functions on to the prototype. So you make a new constructor function and it’s got a prototype object that you can add things to and you just mix stuff in there. So it works the same way in CoffeeScript; you can just add functions to any prototype you like all the way up the chain. TIM: So what about using features of the language that some of the engines have but others don’t? Like would you have a V8 mode of CoffeeScript, where it uses the ES5 and some of the ES6 there? JEREMY: That would compile to it as compile target or will allow you to use it in the grammar if you want it to? TIM: Right. Well, either. I mean mainly as the compile targets like if I knew I was compiling for an ES6 engine, then maybe I could just set underscore proto on the function instead of copying over the parent’s keys. JEREMY: That’s right. So that’s definitely been debated. And I think Michael Ficarra, who is one of the main contributors to current version of CoffeeScript is working on his own version of the compiler wants to add at some point to his version down the line. I'm not terribly interested in targeting different JavaScript runtimes because I think that there's way too much of that happening already in JavaScript. There's way, way, way too many awesome Node libraries on NPM that could perfectly well work in the browser but don’t; you know, things like tweening or math libraries or doing CMYK color conversions that are written for Node. And because the original author just needs to use them in Node, it take advantage of all that fun stuff like object.keys and for each, and then it doesn’t work in IE6 even when it could. And I think that that’s sort of a big problem. A lot of the advantage of JavaScript is that it runs everywhere. And it runs in all the browsers and it runs on the server. And the more to which we can write JavaScript that runs everywhere by default, like the better off we'll all be. So I'm not terribly interested in supporting that in CoffeeScript for that reason. You know, I think it would normally be about practice to admit. Especially if it was just fast, you do it the other way, which I probably would be for a lot of the common Node stuff. You might as well just have it be compatible. JAMISON: so I'm glad you brought up the nuke compiler sorry, were you done? TIM : I just have one more question. This is the great thing about JavaScript is that it runs everywhere, but this also the great bane of JavaScript with  the people who were trained to evolve the language and fix the words is you can’t remove anything. Because someone somewhere in their business depends on IE6 and if they don’t have those customers, they don’t have a business. And so, this decade of browser is holding us all back. And so I mean, that’s the good and bad in JavaScript; you can’t break the web. CHUCK: CURSE YOU MICROSOFT!! TIM: They fixed it. They got a whole new engine. JEREMY: Yeah they do. If only they would automatically update it in XP, then I think everyone will be much happier. JAMISON: Right. JEREMY: Yes that is definitely the course of JavaScript. It’s the curse and the blessing, you know? Might also be the reason why JavaScript is so popular because it really hasn't changed. Well, apart from it being a browser. But these things are all connected, right? It doesn't change because it’s in the browser and it’s popular because it’s in the browser and is it popular because it doesn’t change. But these things are all tied together. TIM: I've definitely seen the contrast working with Lua because Lua is server side only. And because of that, it is not near as popular. How many of you guys know Lua? JAMISON: I read something about it once. That’s my only experience. CHUCK: I've heard of it. JOE: I thought it was only used to build World of War Craft extensions. TIM: Right. But as a language, it’s extremely similar to JavaScript. It’s actually a little easier to learn, but because it doesn't run in the browser, no one uses it. But at the same time, they are free to evolve the language. JEREMY: Being [inaudible] of all the language is also a blessing or a curse because we have the whole Ruby 1.9, Ruby 1.8 thing. We have the Python 3, Python thing were its like, a huge effort for relatively trivial changes. Like Python 3 isn’t that different from Python 2 but it’s really hard to get everything moved up. TIM: Right. So do you feel like CoffeeScript lets you evolve the language without breaking the web? JEREMY: Exactly. It’s one fun thing about CoffeeScript. So CoffeeScript actually has made a decent amount of breaking changes. Usually it is sort of minor things that you can just find a replacement fix up very easily, but a decent amount of breaking changes. And I'm much less concerned about it than if we have VM, because we target lowest common denominator JavaScript and that’s what we compile into. All of your CoffeeScript that you have ever written will always be compatible with every other version of CoffeeScript -- all the way into the future, right? CoffeeScript that you compiled with version 1.1, 1.2, 1.3, 1.4 is always going to be completely interoperable with any other version because semantics are defined as JavaScript semantics. So to that extent, you don’t really have to worry about breaking changes at language and changing syntax even because your old code will still run with your new code; you just can’t recompile it with a new version of compiler until you upgrade that syntax. So it’s kind of fun. AJ: So I wanna make an argument here about the “breaking the language” thing. Internet Explorer has Chrome Frame, so CHUCK: [Laughs] AJ: I people will install Flash without a problem. I really just don’t get this mentality of, “Oh, it doesn’t run in a browser that’s 20 years old. Blah, blah, blah.” JEREMY: Yeah I know. But out in the world it’s a whole other thing, right? AJ: What do you mean “out in the world?” You just tell people, “Look, you must download this plugin, the end.” People download flash all the time. They’ve done it for over a decade and they don’t have any problem with it, nobody complains about it. I mean, like some of us did a more technical complain about it but none of the end users are like, “Oh no, now I have to install Flash!” CHUCK: Yeah but a lot of don’t know what it is. JAMISON: It’s because there are technical benefits to Flash. They can watch like… Flash is YouTube, flash is like all these game sites and if stuff already works... [Crosstalk] AJ: Exactly and all… [Overlapping talks] AJ: If you have all these game sites, like you have all the HTML5 games, the only way to play them is either to use HTML5 browser to install Chrome Frame. JAMISON: Yeah. AJ: So there's all these tangible benefits. I think this whining about it is stupid. JAMISON: I don’t think that… [Crosstalk] AJ: No. I mean like people are constantly saying, “Oh, we can’t do it because of Internet Explorer. Oh, we can’t do it because of Internet Explorer.” Just use Chrome Frame. Just put a button there. “In order to use the site, you must use this plugin. In order to continue listening to music, you have this plugin. In order to…” JEREMY: Unfortunately, for my context, “in order to use this site” is at least a couple of weeks ago, the example for that would have been the homepage of the New York Times. So I don’t think we are going to put a big banner up on nytimes.com that says, “Please upgrade and install Chrome Frame to continue viewing the homepage,” right? That’s a nonstarter and if you try… [Crosstalk] AJ: Well sure if you are not doing anything where you are actually using… if you are not intensively using language, if can just kind of…. JEREMY: Well you do. This is in the context of like the election results widget where we've got a lot of live HTML5 map on the homepage and we still have to do the flash fall back for IE. It’s going to be Canvas and every browsers supports canvas and it’s going to fall back to Flash for Internet Explorer, so that you don’t have to make an upgrade. AJ: So then, they have to install Flash, so why don’t have them install Chrome Frame? JAMISON: Because they already have Flash. CHUCK: Yeah. Anyway, I wanna jump in here and ask another question; we've been talking about cross browser support and things like that and my understanding -- and I may have this wrong so you guys can correct me if I do -- but JSLint is something that kind of provides you with a common denominator to avoid some of the issues the JavaScript can throw at you. And I understand that CoffeeScript actually compiles to JSLint lintable JavaScript, correct? JEREMY: It’s actually JavaScript Lint. Lintable JavaScript is a different program. So JSLint is a Crockford one, and it’s fairly dogmatic about – or pedantic, or however you wanna say it -- about the style that you use has to be very Crockford style. And that’s why we have JSHint and other things. But there's another older program called JavaScript Lint which is the one that we use. So if you type Coffee dash, dash, lint as you compile, it will also lint to the output if you are programming make sure that it doesn’t have any style problems. CHUCK: Is that to help with some of these funky issues that come up from the different engines to help them work everywhere or is that just so that you can say its proper JavaScript? JEREMY: That’s mostly to keep us honest with the code, like we want the style of we don’t wanna have any extra semi colons in funny places even though… or too many parenthesis around things even though it doesn’t affect the semantics of the generated code. It’s mostly just so that we can lint it and make sure that we are emitting sort of correct pretty printed code all the way through. CHUCK: Okay. Cool. AJ: So I have one other question, which is you’ve got the opportunity with CoffeeScript  to fix a lot of things in the language, you know? So you add in a lot of this stuff that’s from Ruby and I think that’s really great. Why not just make a control flow paradigm fitted in to the language so theres not 15 bajillion different control flow things that everyone is using? JEREMY: What do you mean by “control flow”? You are talking about Node in async stuff? AJ: No. I'm talking about JavaScript in async stuff. So for example, a simple promise library, a simple event emitter, I think Node is pretty much standardized that one and people that are looking for an event emitter will either use that or I think jQuery has one too. Just something that makes it easy to compose functions that are not on these and keep out of the pyramid of doom. JEREMY: Yeah. So I think that’s really not as standard as it needs to be in order to make that change. So Node does its thing, right? Node’s got event emitter, which is one thing. Node got this callback system which does something a little bit different, right? So Node callbacks expect the error to be first argument of the callback and that’s something that might have been around a little bit, but that Node otherwise more or less invented. And all the asynchronous APIs in the web usually don’t do that. And it’s actually a problem because if your writing… so this came up there was an effort a while back, maybe like over a year or a year and a half ago to try to merge Underscore.js and Asnyc.js which is on GitHub Caolan McMahon’s great library for composing asynchronous functions in Node. And we wanted to merge it too so that you can have underscore.map and underscore.asyncmap and have them both work the same. And the reason why it didn’t ended up happening is because unfortunately, Node’s use of the error as the first argument of the callback has basically looted all of those APIs. So it’s not generic anymore, right? You can’t pass the callback to an irregular async map function in the browser and say that there's always going to be an error as the first argument of the callback. AJ: So that’s the thing. JEREMY: Maybe I can make this a little bit more clear. So say I async map over an array, just be like I don’t have to, but I just want to, async map over an array. The first argument of the callback is going to be the item in the array. But now, if I async map over filesystem.readfile, now I'm just reading a whole bunch of files and looping over all of them and mapping them. The argument is not the error, is the first thing. So you can’t do it in this generic fashion. And so that’s like one of the reasons why I think it will be very hard to standardize it, sort of in “CoffeeScript” it would be either be compatible with Node, and not compatible with lots of other things and vice versa. AJ: So what I'm saying is, why not just create arbitrary standard and go with it? You know? Just create something that’s implementable easily in JavaScript and it makes sense mathematically. The problem I’ve had with these other control flow libraries is they haven’t approached the problem from the perspective of making it composable. Like jQuery has done a really good job because… well, they have the same idea that I did. And I think Node does a really good job in general, except for the callback being last is dumb because you can’t count on the callback doing in a particular. So, what I'm saying is, if somebody in the community – that's a leader in the community – were just to say, “Here's something that’s going to be part of the language and this is how we are going to do it.” And you can use it or you cannot use it. People might gravitate towards adopting that standard as being part of the language, rather than saying, “Oh, well I'm going to write a library that handles this and then whenever you want  to include somebody else’s code you get their control flow library as well.” JEREMY: Yeah. So if there was one that was obvious and standard and mathematically sound, then please open up a request and send it along because that sounds awesome. But I think that you are also sort of describing the risks there, right? Like you just mentioned jQuery and Node’s approach to this and they are not compatible. Like jQuery you know, the jQuery promise callbacks don’t work exactly the same way as the Node ones. And I know Node is thinking about moving towards... [Crosstalk] AJ: Those two are completely different. Like you can implement the jQuery style in Node without any problem and you can implement the Node style in jQuery without any problem. CHUCK: Right but then somebody has to… [Crosstalk] JEREMY: Which one would CoffeeScript work with by default? It wouldn’t have worked with neither by default, you have to write a mapper. And then there's more like this for other things. So I think one of the reasons why CoffeeScript has been, you know, as useful to folks as it has been is because it’s basically compatible with any JavaScript library. There's no JavaScript library that you are going to have to shim to make it work better with CoffeeScript, really. So I think that was one of the reasons why it works. One thing that you should definitely check out is that there's a fork of CoffeeScript that the OKCupid guys use for all of the I think server side OKCupid stuff called IcedCoffeeScript, that adds asynchronous primitives. It basically takes your code and then they transform it into continuation passing styles. They transform it to call backs, you don’t have to write the call backs so you can pretend like you are waiting for an asynchronous value to come back without having to write a callback and then it’ll transform that for you. And it’s pretty advanced; it’s pretty well done. AJ: I've taken a look at that, but I feel like that approach is… like it doesn’t compile cleanly to JavaScript because its wrapping so much to create the closures and… JEREMY: It’s doing a lot for you, right? You can pretend like you are going through an array comprehension and you are doing an asynchronous operation to every single thing in the array and then using that immediately on the next line, and it does all of that callback transformation for you, that’s why it has to be so ugly in terms of the generated output. AJ: So I don’t see that as being a really good solution because it doesn’t fit with the way JavaScript is. CHUCK: Yeah. All right guys. We need to get to the picks. Is there anything else that we need to go over before we wrap this up? JAMISON: I just wanted to ask what your role in CoffeeScript is now Jeremy because it’s pretty well established; it sounds like there are lots of people working on it, so what do you do day to day on it? Are you kind of benevolent dictator? JEREMY: Yes. I mean, I don’t do as much as I should, day to day. There's been and a lot of these open source projects that sort of taken off and grown legs. Folks are much more active day to day in CoffeeScript; that’s Michael Ficarra and Gerald Lewis are very good about keeping things along day to day. As these things get more stable, and you are sort of comfortable with them being useful and you don’t feel the obligation to keep working on it constantly, I think it’s nice to not work on it very much for a couple of months and then dive back in… [Kid’s voice in the background] That’s adorable. JAMISON: [Chuckles] CHUCK: Did you guys hear all that? JAMISON: Yeah. CHUCK: Oh, I was hitting my mute button. I didn’t work. JEREMY: Anyway, to finish my thought, I think it’s nice to take a break for a little while and then comeback and put out a big new release. So I think the next thing on the plate for CoffeeScript is just getting source maps done and among with lots of little tweaks and bug fixes and things. CHUCK: Right. All right well, let’s go ahead and jump into the picks. AJ, why don’t you start us off? AJ: Okay. Is my mic working now? JAMISON: Pretty staticy but I can hear you. AJ: Try one thing. Okay can you hear me now? CHUCK: Yeah there's still static on the line. AJ: All right. Well, I don’t know what to do. Sorry about that. So I wanna pick the Raspberry Pi and ArchLinux because I got my Raspberry Pi and I like it and I put ArchLinux on it and it worked, although it’s a little too much like Gen2 in the sense that you do everything on your won and it breaks at every step and its complete and utter headache but you know, it’s kind of fun. CHUCK: You learn something, right? AJ: Yeah. CHUCK: All right. Cool. I think we are all a little I bit jealous. I know I want a Raspberry Pi so… AJ: You should have ordered one! They are shipping. CHUCK: Really? I thought there were only a limited number? AJ: Well, there's a limited number in the sense that they can only make so many per day, but there's not a limited number in the sense that you won’t get one eventually. I mean, I ordered back in February. CHUCK: All right. Jamison, what was that? Did somebody say something? JAMISON: I don’t know. CHUCK: All right. Jamison, what are your picks? JAMISON: All right. I've got four picks; the first one is Dash, if you are on Mac OS, it’s a great graphical documentation viewer and it has like the Node docs, it has the MDN docs for JavaScript. It has like HTML and CSS stuff if you want that. It has the iOS stuff, Ruby stuff, it has all these different documentation sets that it knows how go scrape off the web and download, so you can view them offline and search them really easily inside it. CHUCK: Is that in appstore? JAMISON: No. I don’t think so. It’s free though. It’s just Dash. And I use that all the time now because the Node docs are not in alphabetical order and that caused me headaches. My next one is the book called “Predictably Irrational” I think it’s a pretty well-known book. I just never got around to reading it. It’s about behavioral economics. So the idea that the people behave in irrational ways, but they behave in a sane irrational ways and we can look at the dumb things we do repeatable and analyze them to fix mistakes. So he takes about procrastination and dishonesty in the work place and what incentivies that and what incentivies people to be more honest -- and lots of other stuff. So that’s pretty cool. Chuck bugged me for not picking music recently, so I've got a music thing. Russian Circles -- if you like post rock, so just instrumental stuff, it’s a little bit of like the harder end of post rock, but it’s really great programming music to just kind of zone out and write some code in. And my last one is a thing from New York Times. I think Jeremy might have tweeted this, it’s this basketball visualization that they did. JEREMY: I was going to use that for mine for today. JAMISON: I know. JEREMY: I guess we can share. JAMISON: Yeah. JEREMY: That’s fun. JAMISON: It’s sweet. It’s really cool. I don’t know what exactly what they used to do it, but it shows the location of all of the shots taken by Heat and Thunder and the individual players on the different teams and it’s got kind of a heat map about how many points they scored for different places. It’s pretty sweet. Jeremy can probably talk more about it. JEREMY: So Jeremy White and Joe Warden, Mark Erickson worked on it with a statistician I believe and I think it’s fun because it sort of shows the kind of thing that you can do if you take JavaScript seriously in terms of like a document. Like this is basically a chart of how deadly the players are from different positions on the court, but at the same time, because it’s using Canvas, so those are all I think are using canvas sort of portraits that then turn it into a chart.  It is much more interesting than it otherwise will be. JAMISON: Are they individual cells on here? Or it’s all one Canvas? JEREMY: The individual charts I believe. So, each turns them into the graph. JAMISON: it’s sweet. I've posted it in Skype so you guys should check it out; it’s really cool. CHUCK: Cool. All right. Well, Jeremy sounds like you’ve got some picks ready. Why don’t you... JEREMY: That was mine. That was my pick. CHUCK: [Chuckles] All right. Joe, what are your picks? JOE: All right. I have a couple of picks today; the first one is I want to… I think somebody already picked this on the previous ones, I wanna re-pick it. The Ready Player One book, that was an awesome book. My next pick is for Day 9. He is a sports caster for sports, specifically Star Craft 2. JAMISON: (Oh my gosh, Day 9 is so cool!) JOE: He is so cool. He actually picked as one of the 30 Under 30 to Watch by Forbes magazine for entertainment industry. And he's a great, great sportscaster and really, people like him are going to bring the sports a lot more makes it a lot more enjoyable  to watch any sport like Star Craft. And my last pick is the Growing Object Oriented Software Guided by Tests book. A lot people call it the GOOS book. It’s fantastic book about doing test-driven development. And so it’s my third pick. CHUCK: Awesome. That’s also the Book Club book for the Ruby Rogues podcast. And it looks like I've got confirmation from one of the authors. We are going to get confirmation from the other author and probably talk to them in August about that book. So, something to look forward to there. Tim, did we warn you about picks? TIM: I think so. CHUCK: All right. Do you have something you wanna share then? TIM: Sure. So, mainly just that to remember that programming should be fun. And recently I started a blog called nodebits.org. Its Node-specific, but the purpose of the blog is to just remind you that have fun programming and it’s a community driven blog right now. I'm the only author but anyone can contribute to it. Just come up with some really interesting hack and write up an article and it can be posted. CHUCK: Awesome. All right. Well, my picks, the first one that I'm going to be pick is relevant to the CoffeeScript -- is the CoffeeScript cookbook. It’s actually I think its coffeescriptcookbook.org, but I'm not 100% sure. I'll put a link in the show notes. A friend of mine, David Brady and a few other local guys started it up and it’s got a lot of terrific ideas on how you can use CoffeeScript to do different things. So, I highly recommend that you go check that out. And the other thing that I wanna recommend to people is to go check out Stitcher -- Stitcher Smart Radio. It’s another way of getting podcast, but it streams it to your phone and it’s kind of a cool service, so I highly recommend them. They are just really cool. The only problem I have with them is that the producers of the shows have to put the shows in, or they have to submit the shows and then it will pull them off of the RSS feed and then send them out to you. The issue is that not all of the podcast I listen to have been to have been submitted to Stitcher -- so I find myself if I'm using Stitcher on my phone -- I find myself still fiddling around iTunes. So you know, that’s something to be aware of, but I really liked the way that they’d handle a lot of stuff, so you can go check them out. I'll put a link in the show notes for them as well. And with that, I think we are done. Is there anything else that anyone wants to announce? JAMISON: Oh, I forgot about this. Okay. I started up a Papers in Computer Science Reading Group. I don’t know as much academic stuff as I would like, but I'm not in school anymore, so I wanna keep up with it. It’s really just going to be like a Google group and then we are going to go a hang out or something once every so often. We haven’t quite nailed down the times. First one is today, so it’s going to be too late by the time you hear this, but I'll post a link to the Google group when we figure out the next time. We try and pick really accessible papers, we are doing like the Google one right now, so about takes about --- and their first implementation of the crawler and search engine and stuff. So it’s trying to do something that people of all skill levels can participate in and enjoy -- but you can learn cool stuff if you want to if you are interested in that type of thing. So you guys should all join and check it out. CHUCK: Awesome. Yeah while we plug on things we are working on, I will be having the JSON APIs online training. It will be in middle of July and I will have all of that finalized by the time this episode goes out, so I'll have a link in the show notes for that as well. And with that, let’s go ahead and wrap this up. We'll catch you all next week. Thanks Jeremy for coming again and welcome to our new hosts. JAMISON: Thank you so much. JOE: Thanks.

Sign up for the Newsletter

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