The StackOverflow Podcast

[10:05]

Atwood: Confidence, self-confidence. Okay we're small and we don't care. They gonna be out there beating the bushes and yelling at people.

Spolsky: There is a psychological reasoning for that. Well documented in the psychological literature. Its the same reason people join fraternities.

Atwood: [grunts agreement]

Spolsky: So there is a principal in sociology called cognitive dissonance. And here is how this works, the idea is lets say for example you are an enthusiast Squeak programmer and you have just written a web server in Squeak - which is the current version of Smalltalk, the open source version of Smalltalk, very nice actually - anyway I think they have a framework, is it Seaside, is that the name of their framework?

Atwood: Ah that sounds right, I don't know.

Spolsky: It just doesn't matter. Anyway so your at work and your just built a whole webserver and you have somehow convinced your boss to built this whole webserver in Squeak. And you know its crashing all over the place, its not production quality, and its just a big disaster, and they can't hire Squeak programmers.  And everybody is yelling at you all the time and people are calling you an idiot.  So now there is two possibilities. You have, there is sorta, what you have now is a psychological conflict.  Between you did something, and it seems to be the wrong thing. So you can resolve this conflict between what everybody is telling you and what you actually did in one of two ways. You can either admit to yourself that you were wrong, and say Squeak just isn't that good.  Or you can make up this story to tell yourself that Squeak must be so excellent that is must really be worth all the pain that you endure in order to use it.  And the second one doesn't involve thinking that you were wrong so it involves less cognitive dissonance.  In other words there is less, your less upset by the theory that Squeak must be really great and that is why you endure all this pain, then you were stupid for enduring all this pain.  So that is the principal of cognitive dissonance, and that is if anything makes you that much, much more attached to the platform because you have to in order to justify yourself why your suffering all this pain. And indeed that is principal that is used by fraternities and hazing.  So they haze people and the people theoretically think to themselves, "Why am I undergoing this ridiculous torture in order to belong to the fraternity?"  And the two possibilities are:

A) I am stupid, which is a painful thing to acknowledge; and

B) This fraternity is really worth joining.  It's really going to be awesome once I'm a member.  And so it must be worth going through all this hazing.

And the second one does not require you to think that you're stupid, and therefore most people choose that one.  And so that's the principal of cognitive dissonance.

Atwood: Oh, wow.  I had read the term before but I didn't realize it had that specific meaning.

[12:44]

Spolsky: Yeah, it's a specific Psych 101 term.  Very useful concept.  So that's what happens when you have either a new, or a very young technology or a recently acquired technology.  It's gonna be painful to use, no matter what.  For example, there won't be books you can read on how to use it, none of your colleagues will know about it, and they may taunt you about it.  You're just going to be undergoing all kinds of pain, because you're using a programming language or a programming environment that is not yet mainstream, to have a lot of support.  And it may indeed be worth it, or it may not, but in either case, you are undergoing pain.  It's just guaranteed that there's some pain there and you could say to yourself, "I'm undergoing this pain because I'm stupid," or you could say to yourself, "I'm undergoing this pain because it's really worth it, because this is really, truly a fabulous language."  The second one is more common, and that's why these niche groups--it's not fair to put Ruby in that category anymore, but in the early days, certainly these more niche-y kind of not-yet-documented, not yet mainstream version 0.1 products where you see the most avid and vigorous and rigorous advocacy and flaming rhetoric about how great their platform is and how anybody who doesn't believe is a heretic. And obviously if you ever find somebody who agrees with you, to use your crazy little niche bizarre platform that nobody else uses (Not like Ruby on Rails! I can tell by the hate mail that's already zinging my way!) if you can ever find anybody else who agrees with you then, what are you gonna sit around and talk about?  "God, aren't those other guys idiots for not using our platform? And gosh, doesn't that suck?"

Atwood:  Right, yeah, it's something the community has in common.  Mutual enemies, right?

Spolsky:   So, yeah, it's easy to find them, and it's easy to find the other 3 or 4 people who are using your crazy platform.

Now, I should should say - to be fair - that the reason the Ruby on Rails, and the Ruby community in general has it in for me, is that at some point a friend asked me what to use - what programming environment to use - for something he was building, and Ruby on Rails had been out at that time for 8 months, and I said "You know, Java and .NET are fine" - I can't remember why I didn't say anything about PHP?  And I said "Python is almost ready for prime time" - this was a couple years ago - and I can't remember what words I used but basically "Ruby is not quite ready for prime time yet", you know, it just didn't have enough of a track record that you could bet your career on a Ruby project, especially in his position.  So anyway, so they all decided that I was a lunatic, and they've had it in for me since then, because I am clearly an enemy of the state.

Now since then, that was a couple of years ago so Ruby on Rails is now 3 years old, there's a huge community - there's 2000 people going to the Rails conference. Just an absolutely stunning community. There's books that you can buy, there's a lot of Ruby programmers - Ruby programmers are in extreme demand right now, because they're all sort of working. Every once in a while you see a blog post that says "Heey, uh, if you're a Ruby on Rails programmer looking for a job..." Come on that's ridiculous, that's not happening because the number of Ruby jobs is increasing at a rate that is much more rapid than the number of new Ruby programmers, and it is a very very elegant programming language, albeit, not such a fast one, so for large classes of problems it's quite suitable

Atwood:   Right, well you know what those Ruby programmers should do though, Joel.

Spolsky:   Yah...

Atwood:   They should learn C, I think...

Spolsky:   Well, they mostly know C [laughs]

Atwood:   [laughing] Oh that's your out, you're just going to say "Well, they already know C."

Spolsky:   Well at the reaffirmation of 1915 convocation in North Dakota, they were all required to learn C.

Atwood:   I see, that's good, well I want to make sure that's at the forefront.
It's amazing, that is an evergreen topic, the whole learning C issue comes up again and again, it's still funny - there's some very funny things I've read about it, so I enjoyed that conversation.

[16:56]

Atwood: Another thing that happened to me, and this relates to New York City, your hometown: I did write a blog entry about the book Here Comes Everybody by Clay Shirky, and I've been a longtime admirer of Clay Shirky's writing, because I find that--and it's pretty much what I said in the blog post, but it really is true--that I keep going back to it year after year, and every year it seems smarter than the last year that I read it, because everything that he writes about kind of tends to come true. I mean, not everything but like 80%, which is still pretty darned good for somebody who's writing about future trends and things like that. So I greatly admire Clay Shirky, and I loved his new book, Here Comes Everybody, to the point that Jarrod, the other programmer I'm working with on StackOverflow, I gave it to him, and made it assigned reading and said "you must read this, because the site we're building is about online community." That's essentially what Here Comes Everybody is about, about these self-forming communities, and how, now that the Internet is kind of mainstream, it's not necessarily all about techies and people who love computers, that it's really changing--and I hate to be dramatic here--but sort of the fabric of how groups organize in the world, for the better, largely. And it's a really powerful concept, and actually anyone listening I will still heartily recommend the book. And Clay is actually based in New York, and I was wondering, Joel, if you had ever met him.

Spolsky: Yeah, sure.

Atwood: You have?

Spolsky: Yeah yeah, we hang out, man.

[18:20]

Atwood: [laughing] Do you really hang out, or are you exaggerating?

Spolsky: We have hung out.

Atwood: Ok, that's cool. Well, 'cause he emailed me, which was nice again, because I said some very complimentary things about him. And he offered to hang out, he's going to be out here for the Supernova conference.

Spolsky: What kind of conference is that?

Atwood: Ah, it's some--gosh, you know--Web 2.0 kind of thing. I don't understand the details. But it's in San Francisco, which is great 'cause that's just, I can just get on BART and go to San Francisco. So I will have the opportunity to meet Clay as well, which is great, 'cause he's really truly one of my, sort of, heroes.

Spolsky: Yeah. He is. He's a very very smart guy. He's a part of--I think he's a part of this interactive technology program that NYU has had for the longest time.  And there's a lot of really random nonsense at the interactive technology program.  But not him!

[19:16]

Atwood:  No, no.

Spolsky:  I don't want to say "random nonsense."  There's an awful lot of students in the interactive technology program that are really focused on interactive technology as if it were an art medium.  And so they're doing things like making interactive art in a way that is, shall we say, completely relevant to the art world, and completely irrelevant to the technology world.  So they're making things that would have a place in a gallery, and an art historian might have something interesting to say about them, but the geeks look at them, and they're like "I don't get it, you just made a window with static on it."  "Yeah, well, I'm really deconstructing what it means to be a window.  Usually a window is such an information-rich thing, and static is the absence of information."

Atwood:  Yes.  So another thing that came up--and I guess I should ask you how many questions we have. 

Spolsky:  We have about a hundred.

Atwood:  Are you serious?

Spolsky:  But queued up, I got about four.  Yeah, we got a lot.  Some of them are no good.

Atwood:  That's fine.  Before we get into that, I did read one--I do have an ego, like many people I have an ego search set up in Google, which triggers based on my name, because I do like to know when people are talking about me.  And occasionally it'll find things that I never would've found myself.  And one thing I found this week was a blog post from Paulo.  And unfortunately, Paulo, I don't have your last name in front of me.  But Paulo was sort of complaining about our podcast, and he wrote this really sort of nice criticism.  And I do take that stuff seriously, and I actually had a blog post this week about somebody that wrote this long criticism of my blog and my writing.  And obviously I don't address every criticism that people write about me, otherwise I'd do nothing else in the entire day. 

Spolsky:  And people would criticize you for spending so much time addressing all of them.

Atwood:  But if it's a really well-written criticism, I do take that seriously.  Because most people are gonna just walk away from it.  If they don't like what you're doing, they're gonna say "Y'know what?  Screw you!" They actually won't say anything, they'll just walk away.  So if someone writes a thoughtful piece about, "Look, I wanna like this thing, but here's why I don't," I do like to address it and take it seriously.  Because I feel like they're sending you a message.  They're saying look, I want to like what you're doing, but here's why it doesn't work for me.  And, granted, at the audience levels you get to, that you've gotten to, and I've gotten to, you can't satisfy everybody--it's impossible.

Spolsky:  Well, there comes a time--actually, it's very bizarre--there was some point, as Joel on Software grew, there was some point maybe two or three years into it, where I actually started seeing negative comments.  Up until that point, when it was below, y'know ten thousand readers or whatever.  I don't know what the number is, or the date.  But when it was on the order of thousands of readers.  In the early days Dave Winer used to link to me all the time, and in those days people would just not bother writing to me if they didn't have something nice to say.  Which I thought was really surprising.  But it turned out to be the case.  When you're sort of unknown, and you write something and people like it, you'll get the positive, if they don't like it they'll just click on to the next thing.  And at some point I started getting the first negative feedback, after a couple years.  And then at some point you become--and you're just hitting this point, you've hit this point--where you're actually kind of a brand name, and every young blogger needs to take you down, because you're the established power, you're the authority. 

Atwood:  [laughs]

Spolsky:  So you need to be put in your place.  So there arise a new, young generation of rebels, who remember not when you were the young rebel, writing interesting things and making no claims to authority.  When you and I started writing, we were like, "well, we're just guys, y'know.  This is what we think.  If you disagree, could you please tell me why, and let's have a debate?"  But we're not saying "You shall believe me because I am the authority!"  I was very careful not to say that.

Atwood:  There's a Catch-22, though.  Perception becomes the reality.  I mean, that's true of everything.

Spolsky:  Well, no, at some point you become the official authority, right?  So now, all of a sudden, Wikipedia's saying that Jeff Atwood and Joel Spolsky are authorities on blah, blah, blah, or they're gurus of such-and-such, or maybe that's just what people think, because we automatically zoom up the Slashdot and Reddit and Digg and stuff like that.  And so we must be--or everybody is always mentioning us in meetings at their little software company as if we were the authority on something, and they say "Who the heck are these jerkoids?" And they go, and they research, and they realize that we're just actual humans, that we have no claim to authority, that we don't--you don't know C, and I'm not the king of the Universe, or something.  Oh, I know, I don't like exceptions.  And therefore--

Atwood:  Which is dumb, by the way, but go ahead.

Spolsky:  Yeah, let's talk about exceptions.

Atwood:  No, no, I--

Spolsky:  That was completely--

Atwood:  Do you really wanna talk about exceptions?

Spolsky:  I dunno, I just feel like I was misunderstood on exceptions.

[24:10]
Atwood: Ok, go ahead. The floor is yours.

Spolsky: When you're writing systems programming, an exception is just a way to get a bug in your code you can't see. When you're writing application programming, it's a marvelously convenient and useful thing to have. But I came from a kind of a world where you're trying to write like a little bit of C code, like a page of code, that a processor can run, that will absolutely 100% work. And you really need to be constantly trying to think about every code path, and an exception is just one more thing that you may forget to think about.

Atwood: Mhhm.

Spolsky: So there.

[24:49]

Atwood: Well, I think this is an area where C programming is really worse, much worse, than modern structured programming like you'd see at Java or .NET.  Although Java does have that crazy concept of the checked exceptions, that you actually have to catch all the exceptions.

Spolsky: Yes, C has something called a long jump, which is technically an exception but doesn't clean up stuff that's on the stack that you left around, that you might have to free. C++ obviously has exceptions. But it kind of doesn't matter.  At what level you are implementing something?  If you implementing a fairly low level operating system functionality and for whatever reason it is absolutely essential that the code runs perfectly and that every control path is carefully thought through and tested, then I think control paths, it helps to have your control paths be explicit in the code, because it's one of the things that - you know with exceptions you've got some function in the middle and you completely forgot that their functions that your calling that are throwing exceptions to functions above you.  Now if you writing application programming, and there's something you need to get done. [...] If you're writing, heck a bug-tracking application, then 99% of the time when your have something that goes kinda wrong at the very low level, it's ok to just kinda abandon what you were doing, clean up only the most rudimentary of ways, display some kind of error message and let the user go on, and it's really really nice to have that exception capability as a programmer. It's just if you're were writing say a memory allocator for an operating system, then using exceptions is probably a very bad idea, 'cause it probably means that there are invisible code paths you haven't thought about.

Atwood: Well how many people are actually writing memory allocators for operating systems...

Spolsky: None.

Atwood: Relative to how many programmers are working.

Spolsky: Yeah, I agree.

Atwood: So yeah, that where a lot of that, I think, criticism comes from.

Spolsky: Yeah well the world, I mean there are sort of different types of things that people are doing with their programming languages. And there is different tools that are appropriate to different kind of things. What I, what I should get myself into a debate about is threads, it's like I'm pretty convinced that it's almost never the right thing to do to write code using threads.

Atwood: Yeah, that one I actually might be with you on. Because certainly you could go to the Unix model where they just basically fork.

Spolsky: Yes.

Atwood: Ghetto threading. That's just spitting up another process that does the same thing...

Spolsky: And at a great expense and coming up with some enormously complicated inter-process communication mechanism that's so difficult to do, that you are forced to get it right. [laughs]

Atwood: Yeah, I...

Spolsky: Where as a thread sort of thing: [pixie voice] "la la la, I'll just put this thing there, and put that thing ... and take the thing there...", [/pixie voice] and all of the sudden you have a run condition and you don't know why.

Atwood: I like the song you were singing while you're writing the threading code, that's a nice touch.

Spolsky: People always sing to themselves as they write thread code the first...

Atwood [laughs]: It's like one of those songs in the Snow White and Seven Dwarfs, the dwarfs are singing the songs and writing the threading code, but it's going to be... there's going to be dead... there's going to be dead dwarfs, deadlock, whatever, yeah.

Spolsky & Atwood [laugh].

Atwood: No, threading is one of the major problems facing the community, but what I found paradoxical about this whole situation is web server applications scale hugely, and nobody's writing any... like you think those PHP guys are writing threading code? I mean it's laughable, right? Like... [laughs, to demonstrate]

[28:04]

Spolsky:  No.  And they're getting the advantage of threading because the guy that wrote their webserver thought really, really hard about threading, and has implemented all the threading code correctly - although that was practically impossible - whether it's IIS or Apache or anything like that.  I dunno if the other ones do much threading.  Does Apache even do threading, or do they just make a pool of processes and throw things at the wall?

Atwood:  In 2.0--I do know a little bit about this, not a lot, but I'll tell you what I know--Apache 1.x did not really do that, it followed sort of the Unix model of, it would just fork, fork, fork and create new processes.  But I believe Apache 2.0 does use some threading.  Like, they sort of rewrote parts of it to better accommodate operating systems that weren't Unix, right?  Because on Windows, if you do that forking model you're gonna fall over, because creating a process in Windows is a really heavy-weight thing, it's not something you wanna do accidentally.  So they did--in Apache 2.0, I think they changed their architecture somewhat to accommodate both camps.  But I'm unclear how much, how far that goes. 

Spolsky:  Yeah, and in that particular case you have a very specific type of thread, which actually doesn't have to do much more than emulate a process that you used to have code for.  So at least you have a fighting chance of getting it right, because,

first of all: there's only one kind of thread, and it's very specific; 
Number two: it used to work with processes anyway, so you're not really doing something that you weren't doing before parallelizablewise; and
three: you're just one guy on one project, it's not like you're trying to build a whole, y'know, you're trying to build eBay with a whole bunch of threads. 

It's like the guy that wrote that thread code for Apache, one or two people, and they can concentrate on it and pay a lot of attention to it.  And they'll still have a million bugs which they'll never find.

Atwood:  Right.

Spolsky:  Alright, where were we?

Atwood:  No, no, one last thing on that.  So, Paint.NET, which we've talked about, it's a great app, Rick Brewster, who wrote that has a great blog where he talks about Paint.NET.  I'll always remember he wrote a really long blog entry about the threading stuff that he did for Paint.NET.  And graphics is one of the areas where you can actually get huge benefits from threading.

Spolsky:  Gaah!?  Oh, you mean if you have two processors?

Atwood:  Yeah, if you have more than one processor.  If you have multiple, six, eight processors, it scales really, really well, and it's one of those problems that's amenable, just very amenable to this approach of multi-threading.  And he said up front, "This is the most complex code in Paint.NET, by far," was the threading stuff.  And it just goes to show you that even when the benefits are very clear, versus unclear, like, "Well, why should we thread?"  It's really the most difficult code you may ever write, and it's a huge challenge, even when it's the right thing to do, it's a huge challenge.  So there's a lot--

Spolsky:  Yeah, and the difficulty probably means that you're gonna get it wrong.  So in general, sometimes something may be the right thing to do, but there's something else you can do that you're more likely to get right.  Sometimes, you really have no choice, you absolutely, positively, like if you just need to be performant [sic] on large graphical operations on multicore systems, then you can either do multiprocessor, multithreaded, but you're gonna have to do one or the other.  You're just sort of left without a choice.  On the other hand, threading was initially proposed as a way of taking these object-oriented programs, and having the objects run on independent threads, and it was actually believed that you would do this -- I guess in the early days -- it was actually believed that you would do this simply for the convenience of not having any particular determinism as to what order the objects ran in.  Like, let's say you were writing a little game, and the game had sprites and the sprites were moving around on the screen, and there's your AI, and there's you, and there's your sound process, and there's the little musical things that are playing.  It's like, let's just throw each of those in a thread, and it's really convenient, you don't have to figure out how to schedule them in any way, you just let them each run in their own little threads.  And then all of a sudden you have code that's a million times too hard to maintain and get right.

Atwood: Right.

Spolsky: Ummm.... how did we get on that?

Atwood:  Well, because--

Spolsky:  Let's delete all that. That was boring. 

Atwood:  No, no, no, I thought it was a good discussion, I don't want to delete it.

Spolsky:  [laughs]

Atwood:  I do want to come back around to Paulo, because I realize I talked about Paulo, he actually left a comment on our site, because I left a comment on Paulo's site, trying to have this conversation,  "What don't you like about it?" And granted, we can't satisfy everybody, but I was curious to hear what his thoughts were.  And I think a lot of what he's saying here is actually a comment on the blog.stackoverlow.com.  He wants us to talk more about the specific technology we're using in StackOverflow, and how we're using it.  So let me just, real briefly, touch on some of the stuff we haven't talked about.  So we are using SQL Server 2005 as the backend, which is kind of the default choice if you're a Microsoft developer, I mean, you're in the Microsoft stack, so you're gonna use the Microsoft database.  I have had pleasant experiences with SQL Server.  One thing I do like about it is, it's mostly self-tuning.  Because I know when I use MySQL,

Spolsky:  Uhhh, no it's not!

Atwood:  Well, OK--

Spolsky:  No, just no, good Lord, you're gonna think that, and then one day there's gonna be some query that's unbelievably slow, and you're gonna be like, "What the heck?" And you're gonna spend like five hours working on it, and then somebody's gonna be like "Oh, did you try sp_updatestats?" And you're gonna run sp_updatestats, and all your problems will be cured.  And you'll be like, "well, why didn't it do that?"

Atwood:  Well, that's one of my beefs, and I've actually run into this more with MySQL.  Like, MySQL, even with little, dinky stuff, like when I had that problem with WordPress, I had to go through, and basically reconfigure huge swaths of MySQL to get it to perform respectably using WordPress.  And it was a really simple database, there must've been like 20 records in the whole thing.  So I think that's disappointing.

Spolsky:  When you say self-tuning, do you mean there's that wizard you can run that tells you what indexes to create and stuff?

Atwood:  No, I guess I'm a little bit of a utopian, in that I believe the database should be looking at the queries that are coming in and making decisions about those without you necessarily having to do tons of extra work.  Like, say you start querying a column over and over and over, but the column isn't indexed.  Well, the database should go "Y'know what? I'm gonna put an index on this column, because you weren't smart enough to do that."

Spolsky:  OK, that would be great, but SQL Server doesn't do that.

Atwood:  Well, I know, I agree, and I want to be clear, I think SQL Server is slightly more self-tuning than MySQL, but not--you're right, at some level all these databases--and the worst is actually Oracle, where it's almost like Oracle they go out of their way to create this priesthood of people that understand Oracle at a very low level.  Because you almost have to tweak the crap out of everything in Oracle to get performance.  Have you ever actually worked with Oracle?  I did at a previous job.

Spolsky:  I definitely agree with you.  And, you know what, SQL Server, I haven't seen the prices lately, but last I was looking it was one fifth of the price of Oracle.

Atwood:  Yeah.  Well, compared to MySQL, which most people effectively have used free -- although I don't think it's actually free, I think there's licensing behind it, and doesn't -- Sun actually owns MySQL now.

Spolsky:  I want to say two things about MySQL.  Well, I want to say something about MySQL and then I want to say something really really deep.  The thing about MySQL is that we support SQL Server and MySQL for FogBugz, and MySQL is the only database I've ever programmed against in my career that has had data integrity problems, where you do queries and you get nonsense answers back, that are incorrect.

Atwood:  You've actually got, like, bad answers back?

Spolsky:  Yeah.  Like you would do "select count from some table" and you'd get some large obviously random number that is not correct.  And, uh, the response to that particular incident was, "oh, yeah, that's just the version of MySQL that ships with that particular version of MacOS X and you need to upgrade to the latest version, and it won't have that bug."  But I've never -- but what occurred to me is MySQL has lots and lots of little versions like many of those open-source products and many of them have data integrity type bugs or data integrity type issues that would be shocking to anybody that's used to working with stable releases from Microsoft.

[36:17]

Atwood:  Yeah.  No, I think that's a fair criticism.  And I actually had a friend-

Spolsky:  Now the deep thing.  I just want to say the deep thing before we go any further, which is that what I just told you is just this one little anecdote of one thing that happened to me.  And it's a little bit distracting - lately I've become a little bit distressed at how, especially in our field and the field of blogging, these little anecdotes tend to become more than anecdotes.  Like, maybe, this is just one little tiny thing, and maybe I just happened to miss, because that wasn't the query that I did, that exact instance of this exact thing happening in SQL Server where MySQL got it right, or maybe -- basically, the experience I've had is just one person's experience and that's not a lot of experience to do a judgment call on.

Atwood:  Not enough data to make a decision source.

[36:59]

Spolsky:  Right.  It's just an anecdote.  And that's one of the things that frustrates me, actually, about blogging or just the Internet in general.  I was ranting to Jared last night, I practically couldn't go to sleep I was so upset because he was -- we were trying to figure out what fridge to buy for the beach house, and he was just sort of surfing the Internet, looking, seeing what people were saying about various fridges, and I wanted to read Consumer Reports, and he's like, "ah, Consumer Reports is so depressing because they're always testing things and they're always telling you that you shouldn't buy a SubZero because it has twice the incidence of breaking, and it's just depressing."  And I said,

"well, you know, at least Consumer Reports buys all these fridges and they set them all up and they do some kind of moderately scientific experiment on all these fridges, and then they send letters to thousands of people asking them what kind of fridge they have and how often it breaks, and they actually compile this data, and when they're telling you that a SubZero is twice as likely to break as a General Electric, that's actual data.  But when you go to Amazon and you read the review for the General Electric fridge, you're getting information from a person who has experience with maybe four fridges." 

You know?  It has no scientific background whatsoever and absolutely no reason to be answering this.

[38:06]

Now, what set me off on the whole thing was an article that appeared yesterday in the New York Times.  I don't know who wrote it -- a New York Times columnist was complaining about the decreasing level of service on american airlines.  Not American Airlines, but airlines in the United States.  As they cut costs, they're decreasing levels of service, and she illustrated this by saying that she was on a flight recently where there was no sink in the bathroom.  There was just one of those little squeezy things with the alcohol rubbing stuff that you use to decontaminate yourself after you go to the bathroom, but there was no actual sink sink with running water, and she thought this was a gross, this is terribly gross, and she says look how much they're cutting back.  And this annoyed me because there is actually no airline that has removed sinks from the bathrooms.  What had happened is she had flown on a little isty bitsy commuter plane which she obviously never did before and they never had sinks. 

Atwood: I see.

Spolsky: So, because it's a 19 person plane which she didn't notice, I guess, and it's small.  And what was weird, first of all, is that this had gotten past fact checkers, but also, it occurred to me that her anecdote was just based on her experience in taking a few flights, and she had taken a flight on a large plane and then taken a flight on a small plane, and decided that that must be a cutback that american airlines are taking.  And you know, there are lots and lots of cutbacks, and they are removing the pillows and the blankets and the earphones and whatever they're removing all kinds of stuff, and that's true, they're just not removing the sinks.  There's plenty she could have complained about that would have been real.  So that was bad enough that the general story was kind of wrong in that particular way by applying an anecdote of somebody who does not have a lot of experience with taking flights and is therefore extrapolating from a very very small piece of the elephant and describing the whole elephant.  But then there was an entire train because this is the New York Times and they have commenting on this article - there were another 200 comments from all kinds of people who had also each taken one flight recently, and were extrapolating wildly, and saying crazy things like United Airlines is getting better when it's not, or Continental Airlines is the worst when it's not, or just all kinds of stuff that's just factually wrong, but because of the three flights that they took, and they didn't realize how badly they were extrapolating their anecdote onto reality.

Atwood: I think that's a fair point, but I don't know that the Internet makes that unique.  The Internet just makes it easier for you to get up on a pulpit and express your one data point.  The other thing that's interesting there --

Spolsky: And the New York Times would have run that stupid story if it had been a print paper long before the Internet came out, so that's true.

Atwood:  Yeah, yeah, so there's not --

[40:41]

Spolsky: So I won't blame that on the Internet.  There's just a weird tendency to make anecdotes into truths and I actually as a blogger I'm starting to feel a little bit guilty about this because I don't know how many times, I mean the standard model for a blog--not your blog, your blog articles are, like, researched, so I like them--but the standard model that I follow, and that a lot of people copy me, is to tell a little anecdote, some little story of something that happened to you, and claim that it's a model for what everybody should do all the time, and then try to make some kind of big meta "The moral of the story is, you should always do this."  And when you add up all those morals, it takes about ten minutes to find everybody saying everything every possible way. 

Atwood:  Right.  Anecdote-driven development is probably a real challenge.  And I'm glad that you saw that, because you're right, I mean a lot of your early writing is hugely entertaining, and I think it has some excellent points as well, but you're right, it's anecdote-driven.  So you can begin to question the model, it's not exactly science.  And I think the model that I've been using is more of a meta-aggregation type model, where I go out and I look at a bunch of different people's opinions, and I try to sort of more-or-less summarize them, and then also maybe have my own position on it.  So you're right, it's sort of research-oriented, in the sense that I'm quoting a lot (people complain that I quote too much) but what I'm doing when I do that is I'm trying to show you different facets of this argument.   And it frustrates me a little, like with the XML thing that I wrote, and the PHP thing that I wrote, that people see those as just straight up opinions, as like "Oh, Jeff says XML sucks," "Jeff says PHP sucks," so: he sucks.  But what I was trying to communicate is, there's pros and cons to this stuff.  And I obviously have opinions, because I'm a guy that has a lot of opinions, that's one reason why I have a blog.  But I'm trying to show you some of the nuances to it, like the pros and cons to it, by pointing out other people that have written about it, and places you can go to find out more about it.  And generally, I just want people to think about it more.  And that's why I wrote a blog post that I referred to earlier about "strong opinions, weakly held."  And the weakly-held part is where you're looking at the research and saying OK, this is what I think, but I could be convinced otherwise.  And Paul Sappho, who actually came up with that, he was the former director at the Institute For the Future, which is, I guess, some think-tank, actually wrote me about that, which was great, I was very glad to hear from Paul, but I was glad to finally have a name to put on this, because I really do do that, I'll get really excited about certain things, and say "This is the greatest thing ever since sliced bread!" And then like a week later, I'm like "Oh, that's all crap, this is the new greatest thing!" And rather than considering myself this total flake, who's very easily swayed by whatever--which may still be true--I can say it's the byproduct of strong opinions, weakly held.  

Spolsky:  Yeah, and some of this stuff is not actually--like, it's OK not to have a scientific answer, because you could derive it from first principles, so to speak.  Like, you don't actually have to go out and measure a million development teams and find the ones using JSON, the ones using XML, and the ones using YAML, and see which one is most successful, which would be an impossible scientific experiment, you can actually go back to first principles, and just look at the code, look at the data formats, and come to a reasonably educated opinion about the superiority of one or another. 

Atwood:  Right.  I think if you look at enough opinions--the example you gave, about refrigerators, let's go back to that.  So the way I would approach that personally, I would view those all as datapoints, right?  Like, Consumer Reports is a datapoint, the Amazon reviews are a datapoint, like the spread, like how many people hated it, how many people loved it, how many were credible.  You end up having to consume a lot more of this to get a good answer, because you want to look at the big, big picture.  If you zoom in on this one user on Amazon who hated Sub-Zero, obviously you're going to get a wrong impression, or an incorrect impression, that person is not a scientist.  But if you consider it all, there's actually some great information that can come out of it, there's a consensus that can kind of emerge.  And if you ever use, like, Rotten Tomatoes--

Spolsky:  Sometimes. And sometimes the consensus is that we have to invade Iraq! Because they have weapons of mass destruction. 

Atwood:  Yeah.

Spolsky:  And you're just reading every newspaper, and they're all saying the same thing.  And that's why I'm really--well, I don't wanna make this political in any kinda way, but it's not a refrigerator that makes this dangerous, or accidentally using YAML instead of JSON, what makes this dangerous is when your entire country goes to war because you don't have a good system of ferreting out the truth.

Atwood:  Right.  Well, I think if you're going to war, somebody's lost their sense of humor, and their objectivity.  I mean really, at some really high, meta level, someone has lost their sense of humor.  And I think it is important for everyone to realize, these aren't religious issues, particularly a refrigerator, that's easy to see.  But when you talk about Iraq, it becomes almost like a religious issue, and that's really the danger, and I think that's the great thing about strong opinions weakly held, is, you can say "I'm not going to be religious about this.  I feel strongly about this, but I'm not going to fight you to the death about it."

Spolsky:  I'll change my mind if I'm wrong.

Atwood:  Yeah, show me data, right?  It's about the data.  And there's all these datapoints, and y'know, my wife is a scientist, and I think I share a fascination with collecting data of various kinds.  It's just really fun to go out and look at all the data points, and graph it, and come to a conclusion.  So that, to me, is what it's about: getting as many sources of data as possible.  And that's why the Internet is so great, and I can tie that back to Clay Shirky's book, there's so many more people giving you data that there's an endless supply of this data, so then it becomes a question of, how do you aggregate it, what do you do with it?  That becomes the challenge.

Spolsky:  Interesting.

Atwood:  So hopefully you guys get a nice fridge, I want you guys to have a nice fridge.

Spolsky:  Yeah, I don't even know what we're gonna do about that.  Apparently the Sub-Zeros are--they're just really, really expensive, and they have two compressors instead of one, so they break twice as often.

Atwood:  Weren't you telling me your fridge has a problem where you close it, and you can't reopen it because there's too much pressure?  Which I found very comical.  I have a mental image of Joel Spolsky like pulling on the fridge and being unable to open it.  Going "I found the Wasabi!  If we had the Wasabi in this fridge it would totally solve this problem!"

Spolsky:  Yeah, it is that fridge, and that fridge actually died.  So in looking to replace it, we discovered that it's one of those really wide fridges, it's 42 inches wide, so wider than a normal fridge, and those are just like ridiculously expensive, just like shockingly expensive.

Atwood:  That's hilarious, because--

Spolsky:  So we're getting it repaired instead.

Atwood:  --we had a similar problem with stoves, there's this geometric correlation between width of a stove - and I am not at all joking - and price.  It's hilarious.

Spolsky:  It's factorial.

Atwood:  Yeah, it's almost factorial, it's incredible.  And so you're right, what we ended up doing was building a facade, so that we had a smaller, narrower opening, and we could actually not pay $5,000 for a stove.  So I feel your pain, it totally correlates to width, that's hilarious.  So before we go too much further, I would like to get to the questions, I feel like we're--

Spolsky:  The questions?  Oh yeah, let's do at least one.  Where are we? How do you get the questions? I click on here. Ah here is a, oh this is a good question cause we were talking about languages, I want to bring this one up. Here is a question about DSLs.

Tendayi Mawushe: Hi Joel, Jeff my name is Tendayi Mawushe in Dublin, Ireland, and as one of your two remaining listeners I would like to say I am certainly enjoying the podcast and I hope you guys have the energy to keep it going.  My question is a follow-up to the discussion you had last week on XML.  I work primarily as a Java developer and certainly in the enterprise Java world, there was a time you pretty much couldn't do anything without writing a lot of XML.

And to some extent in response to that a new idea has came up that is gaining popularity which is that of Domain Specific Languages or Language-Oriented Programming. Where you create little languages which take the concept of your problem domain and keep in as first class contracts.  And then you write your business applications in those little languages.  Just wonder what your thoughts are on that and where you might see that idea going in future? Thanks.

Spolsky: You recently did the whole XML jazz, so you wanna take a shot at that?

Atwood: Well I think in the general principal he is describing I am definitely for it.  Ah I mean I think there is going to be increasing specialization in languages and I think Ruby is an example of that.  That I think if you went back three or four years people would say you know, "what your creating a new language what are you, crazy?"  I mean you know what that sounds like right, Joel? [laughs].

But I think creating new languages they solve really specific problems that your having makes total sense. And I think eventually the software engineering or computer science or whatever you call it might actually evolve to the point where you'll have an explosion of these really narrow languages attacking your domain. Like say your doing embedded programming,

Spolsky: Well they already exist.

Atwood: Yeah, and I think the popularity is gonna grow is my point. Its gonna be less of, "oh, you've got to choose Coke or Pepsi."

[49:30]

Spolsky: Well think of... Alright let's say you need a programming language for, to run phone switches. So, like, for example the Asterisk configuration file. There's a programming language, and it's a language in which you describe stuff about how the phone switch should work and it certainly doesn't need loops - 'cause that doesn't make sense in a phone switch.

Atwood: Right.

Spolsky: But it does need things like "forward calls from this number after 6pm to that number."

Atwood: And one thing that always bugged me a little was I enjoyed - even in the C# code that I was writing - I enjoyed using regular expressions 'cause I viewed regular expressions as a language specifically dedicated to dealing with strings and I thought that it did that extraordinarily well, right? I mean, granted the syntax is a little hard to read but if you're manipulating strings, regex is like such a joy. I mean really it's just fun to work with for me, and the same thing with SQL. I would meet programmers that hated SQL. How can you hate SQL? SQL is the language of data. Like saying you hate SQL is like saying "I hate data" which I can't really empathise with. I didn't see a problem "mixing" these languages, like you would see programmers write these long frameworks that did nothing but hide the fact that "oh you're using regular expressions? Well now you could just instance up this object and call this method and you don't ever have to - you can pretend that SQL and regular expressions don't exist!"  And I had a problem with that. And I feel that Domain Specific Languages are powerful precisely because they attack the problem specific to the thing you're trying to do.

Spolsky: Well I have a stupid question. Where are these coming from? Are these coming from Java programmers? This concept of Domain Specific Languages. Like what world is this from?

Atwood: I think, so, Rails -

Spolsky: Is it the Patterns people?

Atwood: I have no idea. I think Rails as attacking the Web problem. 'Cause Ruby's the language, right? And people say "Ruby on Rails" and they sort of forget that there's two specific things there. There's the language Ruby and there's Rails which is this DSL attacking -

Spolsky: I mean Rails is in Ruby. When you're writing Rails code you're not writing in some language that somebody's written a mini compiler for. You're actually writing in Rails code.

Atwood: Hold on, but the dynamic nature of Ruby means it's Lisp-like in that you can redefine the language. You know you can change the way the string works, like literally, like completely which is scary to me and I think scary to a lot of other people who are like "Wow, the string doesn't work like I expect it to any more." But you've built a little new language, right? Because you can redefine the fundamental way the keywords work at a very low level.

Spolsky: So is this coming from people like Ruby, or is it coming from people in Java looking at what Ruby is doing and wishing they could do the same thing?  Of course the one thing I can be sure of, it's not coming from Lisp. [laughs]

Atwood: That's all you do in Lisp. Lisp is like the -

Spolsky: Exactly! That was my whole point! [laughs]

Atwood: Yes, well Lisp is the canonical example.

Spolsky: The truth is, for somebody to stand up and say "we need Domain Specific Languages", seems to me like they're using a programming language which doesn't have a good enough way to express trees as literals. And C# and Java are firmly in the camp of not having a good enough way to create trees. So basically to me, if your language has a very very powerful capability of creating any size or shape of data structure literally in the code on the fly, that's how you're going to do your domain specific stuff/language/whatever. You're going to say it's a tree that has these things in it. And so because Java never had a good way to make a tree literal, it was just impossible, you would have to create all the objects and then assign them all to each other, and then create references to each object inside each of its parent's objects and you would just end up with thousands and thousands of lines of procedural code to try to describe, you know, a typical XHTML page, if you tried to do that as a literal in code. And so I think that the first thing the Java programmers did (and that's a little what this caller was alluding to) is the wrote really good XML class libraries and they used XML as the be-all and end-all language for everything and then they allowed these XML class libraries to somehow load those structures into memory and then do the domain-specific thing with them and then that way you could basically use XML as your syntax for any kind of Domain Specific Language you wanted to come up with, whether it's describing a world of games, or describing a bunch of rules for interest rates at a bank, or describing business process rules, or creating a fluid-flow model for a factory or whatever it may be. You would do it in XML and then you would parse the XML using the tools and then you'd get it to a data structure and it seems to me like the Lisp programmers would never have had this thought for a minute because it would never occur to them that you can't just create lists of lists and just nest them all as deeply as you want in their native language which they are using every day.

Atwood: Right.

Spolsky: And what's really cool, and the really cool thing about Ruby - and Python actually - is that they actually have enough syntactic capability that you can create code that is actually procedural but looks declarative.

Atwood: Right, agree totally. And that's hugely powerful.

Spolsky: Yeah, so it sort of looks like you're creating, like let's say that you are trying to create this domain specific language and you're doing it in Ruby code actually. The whole thing may look like it's a tree, it's declaring a tree and it's saying that thing is here and that thing is there and actually that thing has got to run at runtime, it just happens to look - because just the nature of the elegant syntax of Ruby and Python and the ability to override things at the right points and at the right levels - and the ability to just create, you know- does C# 3.0 -- sorry to ask such a stupid question -- does it have a way to create a list on the fly, even?

Atwood: They've been slowly sort of overloading the language to do dynamic-y [sic] things. Generics was one step in 2.0 and now one thing they've added is, I think it's called extension methods where if you decide "hey the String class should have this method called JeffsCrazyMethod()" that looks and feels like a native method but is in fact declared in your code -

Spolsky: Wait, wait, wait. A very specific question: I just need to make an array that has the values 1, 2, 3, those three values, one, two, three in the array. So I know in classic Java I need to declare the array -

Atwood: You can do it inline.

Spolsky: - and then I have to set the values of each of those three things. So in C# I -

Atwood: Yes. You can do that.

Spolsky: Can I nest things? Actually that's some of the dynamic 3.0 features, right?

Atwood: Right. Yeah you can do that, you absolutely can. There's a bunch of semi-cool stuff in 3.0.

Spolsky: So that's an improvement over where we used to be and once they get really good at that stuff you may never create another DSL again.

Atwood: I will say that, you know not to come down hard on Java again, we've already I think pretty burned on that -

Spolsky: [laughs]

Atwood: But I will say that C# and particularly Anders [Hejlsberg] - you know: the language designer - has been really smart about growing the language organically in ways that people want that reflect -

Spolsky: It kind of makes sense.

Atwood: - the new thinking about, OK, dynamic languages are great and we have the DLR, the Dynamic Language Runtime which is what IronPython, IronRuby are based on. And did you see recently that IronRuby, which is John Lam's project, actually I think was running unmodified Rails code, that's a new development. They actually got Rails up and running on IronRuby which is a huge deal. That was pretty recent news. So I think Microsoft has been really responsive to a lot of these new developments in sort of the developer community, maybe more so than people would give them credit for being Microsoft. Microsoft has been such a long-time developer company, if you think what was Microsoft's first product, it was like BASIC I think for the Altair, right? So this goes back to their very roots and I still think they do development stuff really really well so I want to give them their props on this. They've been I think keeping up very well with new developments such as Ruby.

Spolsky: Almost. Almost, I was very -- I'll tell you, I was really disappointed with LINQ, erhm for a couple of reasons. One is that they somehow managed to make this backward SQL syntax that you use, like from table select blah blah blah, just because that allegedly float better for intellisense purposes.

Atwood: Right.

Spolsky: And I don't buy that story and it's irritating and I'm, and the minute I saw that I was like "Oh God do I have to, the whole point here was to emerge the syntaxes and not to make another one."  And the other is because they added a bunch of nifty little features to make LINQ work that are just not as flexible as they could be.  So in particular - what was I trying to do, I think I was just trying to arhm... - ok I'm not going to be able to remember on the spot.  Now but but, the truth they added a new whole bunch of new capabilities, oh I know what I wanted to - do they have this idea of a variant now, were you basically don't declare the type of something and let in be inferred.

Atwood: Right.

Spolsky: But you can't use is as an argument to a function, for example.

Atwood: Right, well that's...

Spolsky: They basically they went about 5% of the way, with some of these concept they went about 5% of how far they needed to go, they just went just far enough to get LINQ to kinda work, but none of these really really nice things like dynamically typed things or not even dynamically typed, just type inferred things, type inferred datatypes. They didn't go quite far enough so that you actually could use those features yourself in a non-LINQ scenario. Which to me is just sort of a shame that's like, "oh God take it one step further guys, it's just obvious what the next step is."

[59:06]

Atwood: But that next step is the Dynamic Language Runtime, so I see what you're getting at, they are bolting stuff on --

Spolsky: No, no, I'm even talking about just type inferencing, and they've kind of added things, you know, and it's, you can sort of see how it's possible to do these things, but you kind of can't do what you want to do.  I wish I could give a better example of that.  For right now, the key thing that I remember is that you don't have to declare the type of something, however, it'll infer it in many many cases, but the minute you take that thing whose type you haven't declared and you want to infer, and you try to pass it to another function: you can't do that.  And so whole categories of things become impossible for no reason.

Atwood: Well, I think what you're seeing there is you want to go fully dynamic, right, you don't want this fake pseudo--

Spolsky: No, I don't want to go dynamic, I want to go type inferred.  There's a difference.  I want the compiler to figure out what type something is at compile time, which is what it's doing, and I want it so I don't have to type the actual type.

Atwood: That's the very nature of dynamic languages.  You don't have to type anything you don't want.

Spolsky: Yeah, but there's a difference between a dynamic language and type inferred.  A dynamic language is one where it's not decided until runtime what type something is and that has a performance penalty.  A type inferred language is one where it's decided at compile time but it's decided based on all kinds of inferences and logical reasoning that you do about the code.  That thing must be an integer because a minute later you're going to add something to it, so it's got to be an integer, so I know it's an integer then I can compile it as an integer and make it run just as fast as if it were native code without any performance penalty, but without requiring you to declare that it's an integer, we can infer that.  So C# is not yet doing the dynamic thing.  What C# is doing is type inferencing in certain cases in certain situations.  But it's so narrow as to be frustrating.  And I was kind of disappointed in that, I was expecting it to go a lot further.  I think they're now, I really do feel like C# in some ways -- it's still the main language that I use so let's not get carried away -- but I do feel like it's a generation behind Python and Ruby, and certainly a couple of generations behind Haskell.

Atwood: Well, I think, well, that was my point, is that I think if you feel strongly about that then IronPython and IronRuby, that's what that's entirely about.  These are from the ground up, and they're running on the--

Spolsky:  IronPython is pretty freakin' amazing! Did we talk about this last week?  IronPython is actually a better ASP.NET programming language than C#. 

Atwood:  Oh yeah, I don't doubt it.

Spolsky:  Because you don't have to keep doing this form.findControl thing, you can just put the name of the control.  And it'll - because it's Python: it's dynamic.

Atwood:  Right, I agree, and that's sort of what I was getting at. Well, we should probably cap it here, because I don't want to get to far over an hour. But there's a nice discussion on performance I want to have, maybe next week.

Spolsky:  Cool, OK.  What else did we have to talk [about]?  You know what, I did go through a whole bunch of the emails that we got, and we have a whole bunch more, and I'll play them and I had four for today, and I didn't really get to all of them.  But if you're listening, y'know what would be cool to call in about?  We didn't get a lot of answers about this.  What system do you use for managing passwords.  Because I don't think I've gotten a good answer to that.

Atwood:  We got a lot of textual responses.  We didn't get a lot of audio responses on that.

Spolsky:  Yeah, I have no use for text.  I can't read.  [laughs]

Atwood:  [laughs]

Spolsky:  Get your little mp3 recorder, and tell me what method you're using to keep, in a secure fashion, all your passwords to all these websites, and make it available on multiple computers at home and at work and all that kind of stuff.  And maybe even Mac/Windows would be good, and available on the Web in an emergency, and so on and so forth. If you have a good solution--

Atwood:  Yeah, email that to podcast@stackoverflow.com

Spolsky:  Like I say, record an mp3, Ogg Vorbis, .WAV, or use that BlogTalkRadio thing (which is awesome) a lot of people are using that, works very well, it's just a phone number that you call and records a little mp3 for you, and you get the link to it and send that to us, and what else, any other business that we have?  So, this is podcast episode number eight, which means that we have three to six weeks until we're shipping the first beta of StackOverflow.

Atwood:  One tiny bit of business.  I did add one more member to our team, it's another person that I used to work with, because I have cronyism really badly in the way that I do my projects.

Spolsky:  Right, that's coming out of your salary.

Atwood:  We have added another person to the team.

Spolsky:  Who's that?

Atwood:  His name is Geoff Dalgas, and I worked with him in Colorado, through '99, and he's a very, very smart coder, and I'm very excited to have him on board.

Spolsky:  Alright, we got three people, that means it's two to four weeks, instead of three to six weeks.  Totally makes sense.

Atwood:  Mostly just trying to compensate for my own inadequacies, and Geoff is gladly helping me with this.

Spolsky:  I was down at the construction site for our new offices today, and they gave me a schedule, and I'm like, "Well, when are we moving in?" And they guy said, "Well, y'know, October 15th." [laughs] October 15th, oh my God, we were hoping August 1st.  And I said, "Y'know, October 15th, we're gonna be homeless on September 1st, so is there any way we could move that up to September 1st?"  And he's like, "Mmm... alright."

Atwood:  [chuckles] Just like that.

Spolsky:  Yeah, and so what he was thinking, obviously, is, "You can believe September 1st if that makes you happy, but you're still moving in October 15th." [laughs]

Atwood:  Well, what are you guys gonna do then?

Spolsky:  It's just a disaster.

Atwood:  What are you guys going to do, seriously?

Spolsky:  Well, the main reason this thing's so long is because they are not yet trying to get--there's these things called lead times, in construction, where you like order a part, like a particular kind of vent, or a particular kind of light, and the person who makes it says, "Well, there's a 14-week lead time on that." Which means you can't have it for 14 weeks.  And they seem to have the philosophy that if this happens, that gives you fourteen weeks to relax at the beach, until the light arrives.  And my approach is, go back to the light vendor and say, "What kind of lights do you have that are similar to the light that I like, which are in stock?" And they say, "Oooh, yeah, I guess we could do that."  So a lotta the reason that their schedule was so absurd is that they are not yet aggressively trying to, let's say, "manage the vendors," so as to bring those long-lead items in shorter, or replace them with other items, or just basically do everything they can to get things moving faster.  So hopefully they'll do some of that, and we'll be in sometime before October 15th.  But it's kind of a bad situation.

Atwood:  Yeah, OK, well, I'm sure you'll keep us updated, and I'm sure the fine people at Fog Creek will have someplace to work, even if it's only a foldable desk in the hallway somewhere.

Spolsky:  [laughs] Kind of something like that, yeah.  Anyway, the hallway of your apartment, right?

Atwood:  [laughs]

Spolsky:  Thanks a lot for listening, to all you peoples out there.  Send us more mp3's with your questions, limit them to 90 seconds, please, podcast@stackoverflow.com, see you next week!

Atwood: Bye!

Spolsky:   Where's the stop recor--

[1:06:27 Ends]