- Jamison Dance (twitter github blog)
- AJ O’Neal (twitter github blog)
- Joe Eames (twitter github blog)
- Merrick Christensen (twitter github)
- Tim Caswell (twitter github howtonode.org)
- Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)
01:01 – David Herman Introduction
04:27 – Reader Opinions & Controversy
09:09 – ES3 Shimming
11:25 – Code: effectivejs/code
12:50 – Parts of the Book
15:54 – Blocking
17:28 – Book Level of Difficulty
20:09 – Asynchronous APIs
- Tail-Call Optimization
26:51 – Programming Language Academics
30:55 – DOM Integration
33:16 – Advice for Programmers in General
34:53 – Performance
40:45 – Primitives Vs Wrapper Classes
42:37 – Semicolons
45:24 – -0/+0
- Jack (Tim)
- Putting Constants on the Left (AJ)
- Getting Started with Amazon AWS EC2 (1 year free VPS web hosting) (AJ)
- Notes on Distributed Systems for Young Bloods: Jeff Hodges (Jamison)
- Hurdles getting started with Ember.js (Jamison)
- Grieves (Merrick)
- The Scala Programming Language (Merrick)
- Antoine Dufour (Joe)
- Torchlight II (Joe)
- Appliness Digital Magazine (Joe)
- Powermat Home & Office Mat (Chuck)
- Une Bobine (Chuck)
- The Rust Programming Language (David)
- mozilla/servo (David)
- Roominate Toy (David)
- OpenWest Conference Call For Papers (AJ)
CHUCK: The most effective way to hack is quickly.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net.]
[This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]
CHUCK: AJ O’Neal.
AJ: Yo! Yo! Yo! Coming at you live from the living roomisphere of Provo, Utah.
CHUCK: We have Joe Eames.
CHUCK: Merrick Christensen.
MERRICK: What’s up guys?
CHUCK: Tim Caswell.
CHUCK: I’m Charles Max Wood from devchat.tv and this week, we have a special guest, Dave Herman.
DAVE: Hi there.
CHUCK: So Dave, you haven’t been on the show before. Do you want to introduce yourself?
DAVE: Oh, and I wrote this book.
CHUCK: You did this book.
TIM: You didn’t just read it and then become an expert on the book and then talk on a podcast about it?
CHUCK: So, I heard about this book. I’m a little curious when you started writing the book, I mean, what was the idea behind it? What inspired it?
DAVE: It kind of happened organically. It was like I sort of had some topics that I could talk about. And then, when I thought about those topics, I started drilling down. And before you know it, you start realizing, “Wow, I should really talk about this. Well, if I talk about this, I got to talk about that.” And it just kind of builds up from there and I ended up having to cut some things.
JOE: So you didn’t start off with like 65 ways off the top of your list, and you just add three?
DAVE: [Laughs] No, we’re also lucky that the number wasn’t something else. I had no number in mind ahead of time. I didn’t even know until I finished and counted them up.
TIM: So, thanks for writing it. It’s awesome.
TIM: I’ve actually seen lots of people congratulate or talking about how awesome it is too. So, it seems like everyone really likes it and I wonder if it’s really gone to your head and now you make people call you ‘D-Money’ or something.
TIM: …balances out.
DAVE: Yeah. I have gotten a lot of good feedback and I really had no idea. It’s kind of terrifying. I had no idea how scary it is to write a book. But I just didn’t know how it was going to be received. So I’ve been really pleasantly surprised that people seem to be happy with it.
CHUCK: So I have to ask, what is the most controversial part of the book?
CHUCK: What is the part that people are getting mad at you about?
DAVE: You know, they haven’t gotten mad at me yet about the book. I get more opinions about ES6 than I do about the book. But it hasn’t been out for very long so I’m sort of waiting to hear more. I’ve certainly gotten a share of typos. And the most embarrassing thing was that I kind of misused the term currying, item 26 says, “Use binds to curry functions.” I really should have said, “Use bind for partial application.” And as a programming language nerd, I should have known better.
TIM: Yeah, don’t you have a PhD in Computer Science and programming languages?
DAVE: I do. Yes.
TIM: Did your advisor call you up and chew you out or something?
CHUCK: So they’re going to revoke your PhD commitment.
JAMISON: I remember when I was reading it, the only part that I objected to a little was the parts on the Wonder Bar Proto, because I think it’s fun to mutate the prototype. But I understand why it’s dangerous too.
MERRICK: Yeah. I was disappointed that there wasn’t a section that said, “Don’t forget to put semi-colons everywhere.” Or, “Don’t put semi-colons in,” one or the other.
AJ: No, I liked it. I liked how objective it was.
DAVE: My goal was to arm people with an understanding of the consequences of their choices. Between consenting adults, I think people can write the code they want to write. I didn’t want to end up with a book that was kind of so uncontroversial that it wasn’t saying anything. But what I really wanted to get into was, “Look, you can have this debate. You can be on either side of the debate but you better understand what the consequences are of your decisions.”
AJ: The one thing about that is, I did feel that the book had too much about ES3 shimming, and not enough about, “ES5 is here, it’s been here. It’s even in Internet Explorer, use it.”
DAVE: Interesting, I wonder what in particular you’re thinking of.
AJ: Well, just as I was reading through it, there was a lot of — you’re mentioning a lot of shims for ES3 but like…
DAVE: Oh, like objects I would create and stuff like that? Yeah.
AJ: Which is good, but then there wasn’t — I didn’t feel like there was enough of, like I’m letting you know about this problem if you’re working with IE6. And I kind of wished that you would have said just IE6 instead of just other browsers as this euphemism.
DAVE: [Laughs] Yeah, that’s a hard line.
AJ: Because it’s really just IE6 and like what? Opera for Wii or something?
DAVE: Not entirely.
JOE: Firefox 1.
DAVE: I’m not actually an expert in all of the individual browsers but I’ve certainly read a bunch of articles in preparation where it was like, “The BlackBerry Browser does this. The various older versions of Firefox do that.” And there actually were gulches in more than just IE6.
AJ: But one thing that I really love/hated about the book, was almost every example, you start out with like the worst possible way to do it. And my gut is just like churning inside and I’m like, “Please, don’t show people that. Please, don’t show people that.” Then, I have to turn the page because the paragraph finishes and it’s like, “That is a terrible way to do it. This is the right way to do it.” And then, I’m like, “Phew.” It’s like a roller coaster.
DAVE: Rebecca Murphey and, I think, Rick Waldron both pointed that out when they were reading drafts of the book. They were like, “I am terrified of you publishing these bad ways of doing things. Even though you correct them, somebody’s going to come and copy and paste it and just not notice that it’s the bad way.”
AJ: Oh, sweet! Dictionary class, nice.
DAVE: I tried to do as much as I could. The publishers were really generous in letting me use color. And I tried to put red comments next to as many of the negative examples as I could. So hopefully, that is like a big red warning sign, “Don’t touch this code.”
TIM: Put the Unicode poop symbol.
MERRICK: Use the radioactive one.
CHUCK: Is the code online anywhere where people can get it?
DAVE: Oh, God! I’m behind on that. I’ve got two of the seven chapters transcribed. They’re on the Github repo.
JAMISON: Is that something someone could just do? Like if a reader wanted to just transcribe the code examples and then submit a pull request?
DAVE: I would welcome that, absolutely.
JAMISON: And fix little typos?
DAVE: Yeah. I also have an errata page, they’re definitely a handful of typos. Some of which are even in the code and that’s a shame. So hopefully, in another printing, we’ll fix some of the simpler typos.
MERRICK: It’s certainly, from what I saw, nothing that you can’t just look at it and reasonably as a human discern like, “Oh, he said add text here and set text here,” you just rename the function.
MERRICK: So, I want to point out for the people that are listening to this, like the kind of errata that’s in there is definitely not something that’s going to prevent you from being able to learn or follow the examples. It’s just stuff where you have to be slightly above monkey intelligence.
DAVE: Yeah. And if you do find that you’re confused by something like, “Wait a minute, that doesn’t make sense.” It might not hurt to just take a quick glance at the errata page and see it was just a typo rather than you’re misunderstanding something. But anyway, the Github repo is github/effectivejs/code is where you can get the code samples. It’s only chapters one and two right now. And yeah, please, if somebody wants to help out, get this transcribed faster. I’ll be happy to accept pull requests.
JAMISON: So to me, reading the book, I think there’s two main parts to it. There’s the first five chapters that teach you the language and what the language has and every gotcha you could have. And then there’s chapter six and chapter seven which are basically best practices, like how to design libraries, how to do concurrency. And I mean, there’s nothing in the language of semantics or syntax there. It’s just how to more effectively use the language on top of understanding how it works. I mean, do you see a similar split or is it just more of the same?
JAMISON: Especially chapter seven, like it starts out with, “Don’t block the event queue on IO.” And I know the browser has always had non block in IO, but it’s never really been an issue because the only APIs you get are non-blocking for the most part unless you do a sync XHR.
CHUCK: Wait, did you just say Mozillan?
CHUCK: It rhymes with Villain.
JAMISON: So, I also want to point out that with the browser, there are issues now of blocking in such a way that it could prevent the user’s interactions. In particular, Joe, you were at the presentation where Aaron Frost was talking about doing motion detection, right?
JOE: I only caught the tail end of it.
JAMISON: Okay, but that raises a very good point. He’s taking an image that he’s getting using the GetUserMedia API, and then he’s running an algorithm on it that’s going through all of these million pixels and he’s doing that every so often. The way that he did it in the presentation was he was only doing it every 200 milliseconds. But if you were designing like a live motion tracking type system where you’re iterating over video frames, you can get into a situation where you need to follow one of those patterns of, like process some of the data, let the event loop continue for a loop, process more of the data.
DAVE: Yeah. And actually, item 65 talks about that more specifically like it’s not only IO but it’s also a long running computation that you want to make sure doesn’t hog the main thread.
TIM: It’s just cool that people are doing things in browsers now that could do long running computations, like people are starting to do some really interesting stuff in browsers that you could never do before.
JAMISON: I’m going to put a link to his, Aaron Frost’s presentation notes because since I mentioned it, it’s pretty cool.
And I think programming is hard, no matter what level you’re programming at. So I didn’t want to shy away from really getting into the more advanced topics. At the same time, people have pointed out that this can be a little daunting for beginners. So I would kind of recommend for people who feel like one of the items they’re reading is kind of going over their head, to just not worry about it and put that item down and maybe go on to some of the others and revisit it later. Maybe the first time they come across a program using bit wise operators, they can go back at that point and revisit that, for example.
MERRICK: The other thing that I found interesting that I found myself doing a lot is you mentioned in the book about how asynchronous APIs should not call until the next turn of the event loop.
DAVE: Yes, I’m so glad you said that.
MERRICK: Even if you have that internally or you can immediately call it back, you should still wait till the next turn of the event loop so people can know not to block, or do some sort of expensive computation or you break the contract. And I never even considered that as being part of the contract until you mentioned that.
DAVE: It’s so subtle. I really believe that there’s a lot of really subtle gotchas in designing asynchronous APIs. That they’re rare enough to get bitten by, and they’re hard enough to diagnose that when they actually happen, you’re not even sure why your program’s going wrong. You’re just like, “Wow, I’ve got this occasional bug and I can’t figure out where it’s coming from.” And it may well be deep in the guts of an asynchronous API. And I have this feeling that, that one is actually out there and biting people. But it’s a little hard to prove.
MERRICK: Yeah, it was brilliant.
JAMISON: I know I’ve heard lots of the promises, people talk about that too. And one of the things the promises are supposed to do is always make things that are supposed to look async, be async and it definitely carries over to callback based code.
DAVE: One of the subtle things that can go wrong is if you call it in the wrong stack and it throws an exception, it’s really subtle to get the catching of exceptions. And when you’re writing one of those libraries, you have to think of every line of code so carefully and you get one thing wrong with exceptions and kind of everything goes wrong. So that’s definitely an area where you have to be super careful.
JOE: And even using, for example, using functions to essentially recursive functions, to iterate on the async operations. Things like that were just so insightful. Like I said, the book is just amazing. I just loved it.
But when you’re doing async stuff, when you want to do a loop asynchronously, you’re actually forced to use recursion. So, it’s something that you can’t really avoid learning once you start writing more asynchronous programs.
DAVE: It’s half right. So, we’re definitely — the committees agreed to have what’s called Proper Tail-Calls in ES6. But that’s only for one specific kind of recursion. That’s for tail recursion which is basically when the last thing that your function does is to return the results of calling another function. And so, when you’re returning, calling that other function, rather than keeping your stack frame around kind of pointlessly, you can actually pop your frame before you call the other function. That’s actually only one of the limitation strategy a JS engine could do differently.
But a reasonable way to think of it is before it calls the other function, it pops the current frame. So what that ends up doing is if you do a whole bunch of tail-calls, like maybe just some long sequence of tail-calls, you’re never going to be growing the stack because it’ll keep popping and calling, popping and calling, popping and calling. But that only works for tail recursion. So, if you have a recursive function call that’s not a tail-call, your stack is still going to grow and eventually, all the JS implementations will blow up.
There are other programming languages where they will actually continually grow the stack. So, kind of like a link list where instead of an array, it can keep growing forever. They’ll grow your stack and they’ll let you use as much recursion as you want to. It will slow down eventually but it will keep growing. But that really is kind of different from the way the architecture of the JS engines works. So, that’s not likely to happen. Sorry, long story short, tail-calls are happening but not general recursion.
MERRICK: The other take away is that there’s going to be a hit R&B song called ‘Popping and Calling’, pretty soon.
TIM: So, you say these are proper tail-calls, not just implementation tail-call optimizations. What’s the difference?
DAVE: Yeah. That’s a subtle point. And from the standpoint of the implementation, it’s maybe not much different. But from the programmer’s standpoint, what it means is you have a guarantee. The language mandates that an implementation must not grow the stack without bound when you do tail-calls. And that means that as a programmer, you can rely on that; whereas with tail-call optimization, it’s just sort of a best effort. It’s like the compiler will try to optimize this in some cases, but you can’t count on it.
So, one analogy that I make is, imagine that for loops, every time you start at a new iteration of your for loops, it pushed a stack frame. You’d never really use for loops because you wouldn’t really be able to count on them not blowing up if you had too many iterations. And if you had a compiler that said, “Sometimes, for loops will blow the stack and sometimes they won’t.” As a programmer, you still wouldn’t be able to use it because you wouldn’t be able to rely on it. But if the language mandates, “Your for loops must not blow this stack without bound,” which of course, that is what the language mandates. It just doesn’t bother saying it because with for loop, nobody expects the stack to blow. But with tail-calls, sort of historically, languages haven’t had proper tail-calls. So, if you don’t actually say it explicitly in standard, “You must have proper tail-calls,” then in practice, the engines aren’t going to implement proper tail-calls and programmers won’t be able to rely on them.
JAMISON: Yeah. So, I wanted to ask you, we’re kind of getting into some of it too, the more programming language like academic stuff. You definitely have a background in that. How much of that came out in the book?
DAVE: I think some of it does. It’s kind of hard not to get into it. It’s definitely one of my favorite topics. And you can also probably sort of relate it to that, a lot of the programming languages world, like especially the research world, does a lot with functional programming. So, I have a lot of background in functional programming. And I think you can see that coming out in the book too, talking about binds and currying – which I should have called partial application – and structural types and recursion. Those are all programming topics.
And when you talk about getting into some of the internals, like how stacks work when you’re doing recursive calls, that’s certainly a programming language-y topic. But I did try to think always from the standpoint of the user of the language. There’s a sort of disease that PL people get of being so obsessed with the technology itself. So, I really wanted to keep the book focused on, even if I’m talking about sort of nerding out on PL details. It really should be only in as much as it matters to the programmer.
JAMISON: That’s really cool. You should talk to some of my professors.
TIM: That was one of the coolest tricks that I took away from the book by the way it was the partial application with bind, particularly how that cleans up your for each loops and basically all those asynchronous APIs that take callbacks. That was just so cool.
TIM: Do you guys know if underscore and all those bind up limitations does kind of a similar thing?
JOE: I’m pretty sure they do. All the code that I’ve looked at does.
DAVE: Any time you put that stuff in print, it goes out of date so fast.
AJ: Well in the end, is it going to disappear anytime soon?
DAVE: I hope not but it could. And then in ten years, there will be this link. Like I read these books from ’95 and they have links to like just these defunct websites that don’t exist anymore. So, I don’t know. I like it.
AJ: I would say it’s a net game.
DAVE: I think it’s a fair point. And also, if I had enough links that started going stale, we could always do another edition of the book. I assume eventually, there will be another edition. For example, once ES6 ships, we’ll want to update the book to have more stuff based on ES6. But yeah, I take your point. I think some references to kind of more information or more reference material wouldn’t hurt.
TIM: And it acknowledges multiple platforms; and also, the history that you have to deal with in practice.
MERRICK: Do you think there’s a place for a book about DOM integration, an Effective book about DOM integration?
DAVE: I bet there could be. I think I’m probably not the person to write it because I really was writing about what I know which is the language. And the DOM is, I really wouldn’t call myself an expert at it. But I think there are so many gotchas in the DOM, both in terms of just weird API design, as well as interoperability issues where things were unspecified and different browsers do it differently.
Yeah, I think there’s probably a lot. In fact, there’s sort of a precedent for that in the Effective series. The first book Effective C++ has a separate book, ‘Effective STL’ which is about the C++ STL library. So, I think that’s not unheard of. That would probably make a lot of sense.
DAVE: I guess, I just really like to hang around people who are smarter than me. That for me is the way I’ve learned the most. So find your community, and that community can be of any sort. For me, a lot of it was Grad school where I was actually physically around a whole bunch of just incredible programmers. But in this day and age with Github and IRC and all sorts of online resources, I think it’s really about find yourself some open source projects. Get involved and just hang out with talented programmers and try to learn from them what you can.
TIM: I like that. Based on what I read out of your book, I imagine when you want to get around with people that are smarter than you, it’s hard for the three of you to get together.
TIM: I look at Mozilla, and Tim Disney, we had him on for macros and I was like, “This is an intern.” Like, “Are you kidding me? This is the intern quality that these guys have? These guys are insane!” They’re smart over there.
DAVE: Yeah. So he interned with my group at Mozilla research and we’ve got a just incredible program. Our group is phenomenal. And I just go to work everyday, hoping nobody will notice that I don’t belong there.
JAMISON: I think the biggest thing I took from the book is to not prematurely optimize my code. Now, let me explain what I mean. I’ve been doing Node for the last three years and one of the big pushes in Node is to make your servers fast, make your servers faster, make them really, really fast and faster than everything out there. And so I’ve learned all these techniques like if you manually cache your array link and all these things that make your code faster. And reading the book and reading things like, “Actually, no. You shouldn’t call back synchronously even if it’s slightly faster. Worry more about proper API than just being slightly faster.” It’s balanced me out a little. So, that was useful.
DAVE: That’s good. I think that’s kind of a perennial challenge in programming. Performance is a feature but if you have a highly performed program that’s just doing the wrong thing, it’s not so much use to anybody either. Hopefully sometimes, you can find that you can divide things up so that the really good interfaces, the really well engineered stuff is sort of the external interface to your program. And you can just optimize some part of the internals and get the performance you need without having to sacrifice the right API that your clients are going to really like.
JAMISON: Yeah, it’s a tough balance, like on the ‘don’t callback synchronously’ thing, I’ve been telling people for months, “Well, there’s some cases where it’s okay because you really need the performance.” And I’m sure that’s been misunderstood to mean that you can callback synchronously from an async function.
JAMISON: Because I mean, there are cases where it makes a huge difference in performance, especially if you don’t have a really fast Nextick or Setimmediate or something like that.
DAVE: Yeah, it’s a tough one. And hopefully, if this becomes enough of a bottleneck, the platforms can kind of do better than Set Time Out which is throttled to four milliseconds and just horrible from a performance perspective. But yeah, with this exact issue, I think I heard it came up in the Windows 8 API where they have a promises library that sometimes does callbacks synchronously. And I imagine that decision was made on the basis of performance. But I’m not sure it’s not going to come back to bite them.
JAMISON: There’s another similar one you have later in chapter six, you distinguish between arrays and array-like. And I mean, that’s a gotcha. How many times has someone tried to push onto their arguments and there’s no push method? I mean, if performance didn’t matter, you were just always trying to do an array or change the language so that arguments is always in array.
DAVE: Yeah. That’s true.
JAMISON: Instead, we just document clearly. This thing is array-like, this thing is a real array. I had the same argument for callbacks, like this async function can call back synchronously, it’s documented, be warned. Maybe that one’s not worth it even. I don’t know.
DAVE: I think that one’s useful even if you’re not thinking about the performance aspect of it, just to know the difference between whether an API’s expecting a true array or an array-like because otherwise, you’ll just possibly pass it the wrong thing. So that’s sort of, at the least, about kind of clear documentation
JOE: It kind of echoed your own sentiment about structural typing too.
JOE: The worst he gets is to say it’s unfortunate.
JAMISON: Yeah, you might as well know it if you’re going to use it.
MERRICK: So you said that sometimes you get angry. Do you just like to march into Brendan Eich’s office and have it out?
DAVE: Brandon said he’s past apologizing.
MERRICK: How cool is it to actually work at the same place as that guy?
DAVE: Oh, man! I don’t want to idolize him too much but it’s just been an incredible privilege to work with Brendan. I’ve actually known him now for seven years and I’ve worked full time at Mozilla for about three and I can’t say enough. It’s amazing to work with him. He’s an incredible person.
AJ: Yeah, he seems like a genuinely good guy. The amount of, I guess, people are just being tools to him. He takes it all pretty professionally.
DAVE: He does better than I do. It just rolls off his back which I’m impressed. Please don’t take that as encouragement to give him more crap.
DAVE: I’m not sure I know what you mean.
AJ: When you do a primitive, like say you type in the number 15, it’s not the same as doing new number 15.
DAVE: Absolutely, the primitives versus the wrapper classes.
AJ: Yeah, the wrapper classes. That’s what they’re called. I’m sorry. Scala has a similar notion of those, so I’m trying to not connect the words. But yeah, that’s right, the wrapper classes.
JAMISON: I think it would be a shame to go a podcast without talking about semicolons. And you boldly approach this issue, this mind field and talk about the rules of automatic semicolon insertion. Was this your reaction? Like did this happen after that debate kind of blew up?
DAVE: I think I was writing it after the debate blew up but I already knew that I was going to write about it. The fact that there was this debate probably affected the way I wrote about it. It probably was getting on my nerves enough that I decided not to pick a side.
curly, I always drop the semicolon. It makes no sense at all but somehow there, it just seems so clearly unnecessary.
MERRICK: It feels so awkward there.
TIM: How many parsers have you written?
DAVE: I think another part of it is, sometimes you’ll write like an array.map with a callback function, and the callback is just doing some pure computation like maybe you do, array.map function X, return X+1. And what I really, really want there is an expression syntax rather than the clunky return statement. And leaving off the semicolon makes it feel just a little bit more like an expression.
DAVE: But anyway, my golden rule is be consistent with whatever the house rules of the code base I’m working on.
JAMISON: I fell like this section makes everybody happy because it explains why automatic semicolon insertion happens, and it explains the rules of it really simply and concisely. But then, you also, I don’t know, still show semicolons and talk value using it. It feels very non-partisan.
CHUCK: That’s the big thing with the rules is, you follow the rules until you understand why they’re there and then you can start deciding when to break them.
DAVE: The one thing I think is inexcusable is people going around and claiming that, “Oh, it’s straightforward. You don’t have to use semicolons.”
DAVE: It’s simply false, like you have to know the rules because if you just leave off your semicolons, there are gotchas. So, it’s fine if you want to take advantage of semicolon insertion but if you don’t know the rules, you will get bitten.
CHUCK: Yeah. Alright, are there any other angles we want to cover before we get into the picks?
JOE: Yeah. I just want to ask one more question. Why is it that you didn’t cover -0 (negative zero) and +0 (positive zero) in your book?
DAVE: I can’t remember if I thought about including that at some point. I mostly try to get by as if there is no such thing as -0 (negative zero). And even === (triple equals) treats it as the same as 0 if I’m not mistaken. So by and large, you can mostly just pretend that it’s the same. There are a few examples where it’ll make your program behave just slightly differently. But maybe, I just haven’t come across the scenarios where it bites you. So I think mostly, it just kind of didn’t make that first level list.
JOE: So you just didn’t feel like it was worth the space on the page because it’s just not that big of a point to understand?
DAVE: I feel like you can get by never even knowing there’s such a thing as -0 (negative zero) but I may be missing some critical gotcha that means that that’s not true. So, I encourage anybody who’s listening, who knows better than I do, to educate me about that.
TIM: Just really quick, I want to mention that there is one thing. There’s just one tip about checking for an auto number and how the IF and AND function is kind of broken because it can coerce stuff into things that are actually not a number. I don’t know. So, it can have inconsistent behavior. And I thought that it was so cool that I Tweeted about it, “Here’s how you actually check if something is a number or not. Check if it equals to itself with the triple equals.” And so many people were like, “Ha…ha…dude, that’s nice but you know there’s an IF and AND function, right?” It’s just funny, it’s not widely known and it’s really useful. I thought that was cool.
DAVE: Yeah. That’s one of those like, where I’d use the word unfortunate in the book but IF and AND should not coerce its argument but it’s too late to change.
CHUCK: Alright. Let’s go ahead and get into the picks. Tim, do you want to start us off?
CHUCK: Cool. We’ll put a link on the notes.
DAVE: Does it run?
TIM: Does it run?
CHUCK: Will it blend?
TIM: It’ll run soon. I keep changing the syntax every other day because people give me feedback and I realize it was terrible.
CHUCK: What, the feedback or the stuff you did?
TIM: No, the feedback’s good. Although certain people at Mozilla keep trying to get me to make Lisp, not Dave. Goes by Gozalla, not Lisp, Closure.
DAVE: Yeah, it’s Raco. He’s a huge Closure fan.
TIM: Indeed, and Closure is a nice language but it’s not the language I want to make.
CHUCK: Somebody else already made it, I think.
DAVE: Making a language, it’s probably good. I don’t know. These days I’ve been recommending to a lot of people SICP, Structure and Interpretation of Computer Programs. It’s not like when you finish that book, you’re not going to know how to make a language. But it gives you a lot of ways of thinking about writing interpreters and building languages.
CHUCK: Cool. AJ, what are your picks?
AJ: My technical pick is Putting Constants on the Left, because if you don’t put your constant on the left, it will never ever, ever, ever, ever, ever, ever be accidentally assigned to. It will throw an exception. God Bless America! And God Bless every language that can support that, which isn’t C++.
AJ: Also, I am starting to do some screencasts and I’m putting them up on YouTube. And I’ll put a link in the show notes tomorrow where I’m talking about Amazon Web Services and just showing how to sign up for their one year free VPS type thing that they call EC2. And I am doing consulting. So I want to pick me and my screencasts, start looking out for them, they’re coming. Hopefully, they’ll have some cool stuff. And if you’re looking for somebody to hire, I’m available for short term work.
CHUCK: Cool. Jamison, what are your picks?
JAMISON: Okay, I’ve got two. I need to get back to some non-programming picks. These are both programming picks again. One is this blog post called ‘Notes on Distributed Systems for Young Bloods’. I guess ‘young bloods’ is what they said instead of like beginning programmers or newbs or something, I don’t know. And it just talks about all the tricky problems that come in writing Distributed Systems. And as someone who’s running into these problems, it was really good to see an overview of some of the ones we’ve already found and some that are moving ahead of us, just laid-out really clearly and concisely. It’s a great read and I think it will be probably one of those classics that people post around for a really long time.
And then, my next one is just a Gist. I’ve been doing a lot with Ember lately, not putting full time into it. So, I get into it for a while and then leave and come back for a while and stuff. And it’s really powerful. It’s also really frustrating at times. So, this is Polotek, I can’t remember his real name again. But he talks about his experiences using Ember and some of the gotchas he’s found and the tricky things. And then Tom Dale, one of the core Ember guys, comes in and comments on the Gist and just goes through all of his comments and really nicely says, “Thanks for the feedback, and you’re right about this. We need to change this.” It’s just really cool, and then corrects some of his misunderstandings. So, it’s really cool to see this interaction between two people talking about this framework I use a lot. And I also learned a bunch of things about it. So, I’ll post those in the show notes.
If you use Ember, you should look at the Gist. If you don’t, you might not care that much. But the Distributed Systems one is really good for everybody.
CHUCK: Alright. Merrick, what are your picks?
MERRICK: I’m going to pick this Hip Hop artist named Grieves. He’s just awesome. He’s from the Northwest and he’s just got some good jams.
CHUCK: Cool. Joe, what are your picks?
JOE: My first pick’s going to be on a music artist, Antoine Dufour. He’s a guitarist. And he just has the most amazing, it’s kind of like a mix between sort of a classical and Spanish mostly, and then maybe a little bit of New Age. Just instrumental, no words, no singer. He does some duets with some other people and it’s just fantastic music.
And for anybody that’s listening, if you do happen to listen to him, he has a song called Tango Agricole, and I’ve heard that song in a movie somewhere. And for the life of me, I can’t find out what movie. So if anybody out there figures that out, please let me know over Twitter what movie that song was in because it’s just driving me nuts.
Then I want to pick, Torchlight II, the game. I picked it up over the Christmas break and I’ve been playing it a bunch and it’s a sweet game. I like it a lot better than Diablo III. I like the cartoony style of the graphics. It’s been a really fun game.
And for my third pick, I want to pick the Appliness Magazine. It’s just a digital magazine and they have a lot of really cool articles in there. You can get it on your iPad for free or I think you can read it online as well for free. But it’s a really sweet magazine, all about development topics.
CHUCK: Alright, sounds good. I’ll go next and then we’ll let Dave go last.
So, my first pick is something that my wife got me for Christmas. It’s called The Powermat and it’s one of those magnetic induction charger device things. And so, you can get what they call doors, they’re just these little magnetic squares that let your device charge. You can get them on phone cases and stuff or you can just get the Powermat. It’s kind of a universal one that has a mini-USB and adaptors for most of the devices out there. And I really like it. I just wind up switching my devices off of it all day. And so, everything’s always charged and it’s really kind of nice. I’m not sure how well it travels though it will probably go with me next time I go anywhere.
My second pick is something that I got at CES. They gave me a review copy. The only issue that I really have with it is that it doesn’t have the lightning adaptor for my iPhone 5. Instead, it’s got the 30-pin adaptor so I can use it with my iPad. And what it is it’s — the company is called Fuse Chicken, and you can find them at fusechicken.com. What it is, is on one end, it has the USB plug and on the other end, it has the 30-pin adaptor for the iPod or whatever. And it’s this flexible, bendable charging cord. So you can use it as a stand if you don’t want to plug it in, or you can plug it in and then use it as a stand anyway, to hold up whatever it is that you want to have up and off the desk and kind of up where you can see it. Anyway, those are my picks and I’ll put links to them in the show notes.
And we’ll throw it over to Dave. Dave, what are your picks?
DAVE: Well, I’m going to be greedy and take three. The first pick I want to talk about is, we mentioned it briefly I think, the Rust Programming Language. This is a language that my group has been working on at Mozilla Research for a couple of years. It was originally started by Graydon Hoare and the team has grown and it’s just an incredible team. The way to think about Rust is a replacement for C++ that has sort of the same performance level that C++ does but that’s safer and better at concurrency and parallelism. So, Rust is at 0.5 right now. We’re going to hit 0.6 probably this quarter. And our hope is to hit 1.0 by the end of 2013. So, it’s still changing a little but it’s definitely stabilizing and it’s definitely at a point where you can start playing with it and trying it out.
And the reason for Rust’s existence, the reason why we’re doing it at Mozilla is, my second pick which is another project I’m really excited about, a project called Servo. Every browser has its engine. At Mozilla, we use Gecko. A bunch of browsers use WebKit but all these are kind of based on aging 90′s era technology and there’s enough competition that they are moving quickly. But Servo is really about rethinking, redesigning the entire guts of the browser to try to take advantage of modern hardware and to try to be more secure. So, Rust was designed to support Servo. Servo was implemented in Rust.
So that’s just kind of getting started. But we already have a little bit of functionality. You can render some basic pages with it. I expect to see a lot more activity in Servo in 2013.
TIM: Do you anticipate Firefox switching over to that eventuality?
DAVE: Servo, right now, is a research experiment. And we’re not really limiting it to what its future could be. It could end up being a totally separate browser or it could end up being a part of Firefox. But one of the things we want to be open about is how much we can break with its compatibility. Within Firefox, we have to be absolutely web compatible. But if we’re thinking about possibly a new browser for the future, maybe we can say we can get much better performance if there’s some things that we break compatibility with. So basically the answer is we’re not going to commit to that until we know better how well it works.
TIM: Very cool. It looks like, maybe for the mobile feature, you guys are working on too. That’s really cool stuff.
DAVE: Absolutely, yeah. With mobile, multi-core and JPUs are just as important. So, that’s really high level. But basically, the nature of hardware is completely changing from what it was ten years ago and that’s happening across the board – desktops, laptops, tablets, phones. We’re already seeing eight-core phones coming out this year. So, software has to change to keep up with the hardware and that’s really what these projects are about.
So, my third pick is not about Mozilla at all. My wife and I are expecting our first child in about a month. And Rick Waldron, who is a totally cool guy, sent us this gift. We’re not actually telling people what sex of the baby is. But he got us this little gender-neutral gift called ‘The Roominate’. The Roominate, I think, was designed by some Engineering women from Stanford who wanted to create something that would be kind of appealing to both boys and girls. I think they might have been focused more on girls but it could be just as good for boys. It’s like an engineering toy crossed with a doll house. So, you get to like play house but you also get to put pieces together and make things work. And I think it’s such a cool toy that I’ve been buying it for all of my friends who have kids.
CHUCK: That looks really, really cool. It looks like it is aimed at girls but I think my son would like it just as much. That’s great.
Alright. Well, we’re going to go ahead and wrap up the show. Thanks for coming, Dave. And thanks for the writing the book. It’s an awesome book.
DAVE: My pleasure! Thanks for having me on the show.
CHUCK: I don’t think we have any announcements of anything coming up. I did set up a mailing list for the podcast and eventually, I will start emailing out in advance so that you know what’s coming in future episodes. So, go sign up for that and hopefully, we can start sending those out soon.
And if you’re interested in learning Ruby on Rails, I’m going to be teaching that course starting in March. You kind of get unlimited access to me for eight weeks in learning Rails. And you can find that at railsrampup.com.
Other than that, it looks like AJ has something that he wants to announce real fast and then we’ll wrap up the show.
AJ: Yeah. I just wanted to let everybody know that Open West Conference is coming. It used to be called Utah Open Source but now it’s being expanded to be a regional conference. There’s a wide variety of topics that you can choose from, basically anything open source-y. So, I want to see you there.
CHUCK: Alright, sounds good. Go sign up, Open West Conference, it’s openwest.org/cfp.
That’s it. We’ll wrap it up. We’ll catch you all next week.