- Jeremy Ashkenas
- AJ O’Neal (twitter github blog)
- Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp)
- Jamison Dance (twitter github blog)
- Joe Eames (twitter github blog)
- Tim Caswell
- Document Cloud
- Cross-compilers for Ruby, Python, etc.
- Ruby on Rails
- i.tv uses it full time
- May not be ideal for writing Node.js libraries
- CoffeeScript NPM module
- CoffeeScript compiler is written in CoffeeScript
- testing in CoffeeScript
- Arrow notation
- Does arrow notation encourage writing anonymous functions?
- Not all anonymous functions are anonymous
- CoffeeScript uses function expressions
- Thin arrow (->)/Fat arrow (=>)
- Do you need curly braces?
- You can use parenthesis to enclose your function
- Linguistic Relativity
- Chaining functions & comprehensions
- Implicit returns
- Dave Thomas
- es-discuss mailing list
- JS-next implementations in CoffeeScript
- IE6 is the lowest common denominator
- Source Maps
- Throw syntax errors as early as possible
- Compile time errors for strict mode problems
- Strict mode
- Compiling to readable code
- Class definitions in CoffeeScript
- Node.js inheritance
- Mixin based multiple inheritance
- Compile to specific targets
- CoffeeScript allows you to evolve the language without breaking the web
- Node.js Event Emitter
- Raspberry Pi (AJ)
- ArchLinux (AJ)
- Dash (Jamison)
- Predictably Irrational [amazon] (Jamison)
- Russian Circles (Jamison)
- Basketball Visualization from the NY Times (Jamison & Jeremy)
- Ready Player One (Joe)
- Day 9 (Joe)
- Growing Object Oriented Software Guided by Tests (Joe)
- Programming should be fun (Tim)
- Nodebits.org (Tim)
- CoffeeScript Cookbook (Chuck)
- Stitcher (Chuck)
- Papers in Computer Science group (Jamison)
- JSON API’s Online Training (Chuck)
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?
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.
CHUCK: Do you wanna give a quick introduction, Joe?
CHUCK: Awesome. And we also have Tim Caswell.
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?
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.
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]
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.
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: 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.
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…
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.
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.
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.
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.
AJ: [unintelligible] words.
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.
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?
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.
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.
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.
JEREMY: How does it change for you?
JOE: So can you clarify what it means to be an “older” Ruby programmer? So he’s at least like 10 years old?
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?
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?
JEREMY: I don’t quite follow. What was that?
CHUCK: Right. So what is the least common denominator then? Is it IE7 or IE8?
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?
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 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.
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.
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.
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.
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?
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.
JAMISON: so I’m glad you brought up the nuke compiler sorry, were you done?
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.
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.
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?
AJ: So I wanna make an argument here about the “breaking the language” thing. Internet Explorer has Chrome Frame, so
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…
AJ: Exactly and all…
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.
AJ: So there’s all these tangible benefits. I think this whining about it is stupid.
JAMISON: I don’t think that…
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…
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.
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?
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.
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…
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…
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.
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.
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.
CHUCK: Did you guys hear all that?
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?
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?
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.
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.
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.