The StackOverflow Podcast

[incomplete]

Intro, advertising

Atwood: Are we on President number 44 now ?

Spolsky: Maybe? There's a question as to whether you count that guy that was President twice.

Atwood: <laughs>

Spolsky: { Not sure, please check } And wasn't there somebody who had been president for five minutes?

Atwood: Oh gosh I don't know, my American history isn't good enough to cover that.

Spolsky: Do we have a podcast guest?

Atwood: No, no, I had to { Fill this in }

Spolsky: Oh, next week maybe.

Atwood: Do you wanna play that song, there was a song.

Spolsky: Nobody like us.

Atwood: <laughs> That's not true.

Spolsky: We had a guest song, I don't know, let me look up onto YouTube and see whether I can find it.

Atwood: Yeah.

Spolsky: What was it?

Atwood: It was a parody of Let It Be, is it what it is called?

Spolsky: Right, it was about the C programming language.

Atwood: Yeah, I actually contacted that guy. I had a link here, I'll send it to you.

Spolsky: Here it is.

Atwood: I contacted that guy on YouTube but everytime I done that...

[Spolsky plays Write in C song at the background until the beginning of the chorus]

Spolsky: Write in C. Alright, enough of that word.

Atwood: That was really funny, though, I enjoyed that.

Spolsky: It was a good one, it's a nice, hardcore... so you actually contacted this kid?

Atwood: Well, I have. In the past I wanted to contact people on YouTube [and] you can use a contact form, because I have a YouTube account. And I contact him, explain { Fill this in }, who you were, who I was and of course there was no response at all. <laughs> Which is pretty typical, I mean YouTube is just not a good messaging... uh, mechanism.

Spolsky: The first thing I'd do if I post a video to YouTube would be to install some kind of, like, email electrification, zapper and nukifier to prevent everybody contacted by anyone.

Atwood: Yeah... so we are { Fill this in }

Spolsky: Yeah, it's not paying the proper royalties to the Beatles anyway. <laughs> We'll link to that from the shownotes. Awesome song, Write in C.

Atwood: That's right, Joel's favourite song. Write everything in C, because Joel does in fact write everything in C, don't you, Joel?

Spolsky: I started using a little bit of C99, the latest version of C, which let you declare variables after you written some statements.

Atwood: Isn't there like a... well no, there's is another version of C++ coming out, like, 0x something?

Spolsky: Yea, C++0x. { Fill this in } they just haven't decided what year it's going to ship yet.

Atwood: I see.

Spolsky: I guess it's either C++09 or nothing, they are kind of running out of 0's.

Atwood: Mmm, yea, as I'm not a C programmer, I don't really keep up with that stuff, but occasionally...

Spolsky: Do you know that I had lunch with Brain Kernighan?

Atwood: Oh right! That's awesome. How did that go?

Spolsky: You know, he told me what he thought was the one mistake of C programming language. Now he wrote the book The C Programming Language but he did not invent C. He work with the folks that did, he invented the language is called Awk... umm, among other things, probably. But it's an awesome book, and he said that probably the only mistake in C was the operator precedence of the bitwise logical operators as compared to the equality operator. He thought that the bitwise logical operators should be higher priority than the equality operator. And other than that he thought there wasn't really a mistake in the language, [and] I tend to agree with that. I'd say that's kind of true.

Atwood: Certainly it's been wildly popular. I mean, C has been the backbone of a lot of programming [languages], so, by that measure, it's wildly successful.

Spolsky: Yeah.

Atwood: I don't think that the criticism that it is a low-level or medium-level language, that was by design, that was the intent of C.

Spolsky: And don't forget the context, it was 78 or something, right?

Atwood: That was a long time ago.

Spolsky: So, you have to put things in context. The stuff in the C that I consider as accidental complexity like stuff you have to manage yourself, like memory management, things like malloc() things for yourself you don't have to do anymore because we have figured out ways to let the compiler and the runtime do it for you with garbage collection... or even with the reference counting like they had in Visual Basic. So the stuff in C that just doesn't have to be in a programming language anymore, but that doesn't mean that it wasn't a good programming language for its time.

Atwood: Absolutely. Now it was hugely influential -- C#, Javascript... and the other languages that looks like C, which... I was kind of bitter about, actually. I was never a big fan of sort of the way select...

Spolsky: That wasn't C, that's Algol, right? C was looking like Algol, I mean, those are all the strutural programming languages that was meant to look like Algol68.

Atwood: Right, but I blame C. Because it was just so much popular. I don't know how popular Algol was, but certainly, as long I've been a programmer, C was like, the touchstone/cornerstone language and it seemed a lot of language decisions like in Java and C# were made so that people wouldn't look at the code and freak out "I don't recognize this! This doesn't look like code I could understand." So they made it look similar to C to reduce the learning pain. I'm a little bitter about that because I always felt that I really dislike the look of C.

Spolsky: Really?

Atwood: Yeah.

Spolsky: So clean and... mechanical?

Atwood: For one thing, the curlies... like when you are ending curly braces, you never know what you are really ending. Just another curly brace -- I guess it's kind of like the Lisp problem, you have paren(thesis), you never really know the parens are closing. This is just a preference, but I'd like a little more verbosity in the ending of blocks, that I know exactly the block that was ended versus just....

Spolsky: That was a weird thing... You know there were programming languages where the end matchs the opening of the block, so like Basic: If... End If. But then again, what if you have nested if's? You still don't exactly know which one it goes to.

Atwood: Yeah, that's true. But it's really just a tradeoff, it's just a preference. It's not written in stone obviously.

Spolsky: I come to like the fact that Python that you just don't write an end: you just unindent, and so the indenting actually reflect the structure.

Atwood: That was actually a cool aspect of Python. I never really work in Python actually at all, but I always respected the choice that it was a brave choice to make the whitespace to carry the meaning and actually enforce the whitespace, and thought that was very cool. And one thing I do agree with -- and coming from a Basic background, which is the language I knew for a long time, I eventually grudging agreed that having carraige return be your line terminator.

Spolsky: That's Unix, that's not really...

Atwood: No, no, what I mean like, so in C# or C, until you put a semicolon in, it's one line.

Spolsky: Oh, I'm sorry. I thought you meant the line separator was the carraige return and  linefeed. You are talking about the semicolon versus just the line end.

Atwood: Right. At first I was bitter about that, because I was like "I have to type the stupid semicolon at the end of every line", but then I realize that it gives you so much flexibility because there's a lot of situations that you get into in Basic where you want to continue the line you have to use some crazy, like, line continuation marker like underscore.

Spolsky: It's not crazy, it's awkward.

Atwood: It's just awkward because the semicolon way, I think, is much better. And I think any language you have to have an explicit line terminator, I don't think it's a good idea to use carraige returns as a line terminator.

Spolsky: Hey do you know what Kernighan's second favourite language is?

Atwood: What's that?

Spolsky: Basic.

Atwood: <laughs> Really? Did he tell you that, today?

Spolsky: Yeah.

Atwood: That's crazy.

Spolsky: No, it's true, he said that's sort of a secondary language. He told me that "Are they really coming up with another version of VB6? 'Cos I really don't like VB.NET."

Atwood: Wow.

Spolsky: Yeah, he has done a bunch of stuff like, for example, he had some kind of a big complicated library that did all kinds of interesting optimizations and it didn't really have a very good UI like input/output thing. So they did the input/output UI through Excel, or you'd just type things into a spreadsheet and then he had this VBA code that basically linked these COM objects that were written in C to interface with them.

Atwood: Cool.

Spolsky: But in his class, I think, he teaches little bit of Visual Basic, a little of COM programming, a little bit of.. . he teaches a lot of other things, a little bit of Awk, a little bit of command line... this, that and the other things. I think it's important for programmers, especially the college levels, to learn a lot of little languages and to use the right tools for the job. There's some stuff that I think like, if you give me a problem that most people would solve it in Perl or Awk, I might solve it with Excel, like in kind of a one time way. Like's it's a problem as you get a big old file and you need to separate the first name from the last name, put the phone numbers, capitals, multiply this by that... Some kind of like column-wise kind of problem, I'd often do it in Excel I know how to do that really fast really easily.

Atwood: I agree with that. I actually talked about that in a blog post before, I see the future of languages as a lot of small languages that are good in specific things. And you'd switch between them in a fluid way, to when you are like "Oh, this is a set-based problem" or "Oh, this is a database problem" or "Oh, this is a text manipulation problem" and you sort of drop in a language that is good in that thing. I'm a big fan of that, I never really liked the idea that, and I think a lot of developers... let me give a specific example, they hate SQL for some reason, like they really don't like using SQL as a language or manipulating it, so they come up with this huge layer of abstraction just to get rid of SQL.

Spolsky: Yeah, it's stuff that they should just probably be doing...

Atwood: Yeah! And to me it's contorted!

Spolsky: { Check this line; probably wrong } As they learn more about SELECT statements, they'd realize that there's a better way to do it.

Atwood: Yeah, I mean SQL has its faults, to be sure, but it's really good: basic set-based data manipulation, I think. I actually like SQL a lot, and I realize that it's not perfect.

Spolsky: Yeah. The biggest weakness, especially for SQL Server, is any kind of interesting string manipulation you tried to do...

Atwood: It's painful.

Spolsky: ... it just falls all over the place. So if you just try and do something where its like splitting of word, ... I don't know, just anything that's inside the columns, there's not enough functions there, like they don't even have the proper, like Left, Mid, IntStr... like the most basic string functions.

Atwood: We actually created a user-defined function to bring .NET regular expressions into SQL Server. You can actually use managed code, it's not super-super fast, obviously, because it has to call to .NET.

Spolsky: How many years has SQL Server been out that they can't put regular expressions into T-SQL?

Atwood: Yeah, I was really shocked, because...

Spolsky: { Fill me in } ... this is such an obvious thing, just go friggin' put regular expression in this there! I know they are not fast, but everybody have to write COM objects now if you want use a regular expression in a SQL SELECT statement? What year it is?

Atwood: Well, it's not a COM object, it's a .NET managed code object. So it's not quite as bad as COM, but there's definitely a huge speed penalty because you are transitioning between those two worlds. Right?

Spolsky: If you do it in COM, then I'd say fast. But yeah, and your SQL queries can crash the whole machine. <laughs>

Atwood: Right.

Spolsky: ... caused by memory or god knows what. Sometimes it's just surprises me like what on earth they could have added in SQL:2008 if it wasn't that?

Atwood: Well, one thing: remember we talked about the Oslow, the modelling language, the DSL... thing we are talking about?

Spolsky: Yeah, I know, and I'm { Fill me in } about it and taped three episodes in which we get all kinds of Oslow modelling archives.

Atwood: Well, maybe what it's partly about, like sometimes, as a programmer you realize that you are trying to solve a problem and sometimes the language itself is sort of getting in your way at some fundamental level. It's not good at X, where X is... like in the case of SQL, it's not good at string manipulation. So the language is getting in your way. So what do you do? You could sort of roll up your sleeve and say "What if we could change the language itself?" And this is sort of going down the rabbit hole and to like Lisp and like Ruby and those languages that you can redefine the language and write constructs that perform the same as the language.

Spolsky: Be careful as somebody's getting out there got an email from... { Fill me in } <laughs>

Atwood: You don't agree with that?

Spolsky: Well, OK. Let's carry on that thought then.

Atwood: OK, that's as far as I'm going to go with this. I think sometimes you want to fix the problems, like, in the language, like you don't want to shell out to another executable or, you know, come up with some other of Rube Goldberg type solution. You wanna...

Spolsky: That's the trouble. The trouble is with the exception of Lisp, languages that are powerful enough to fix the problem in the language don't have these problem. They don't really have to. The exception of Lisp, where you start with language that had nothing and a really good macro capability so that you can extend the language to make it into whatever kind of language you want, so long you like parenthesis, and that's all very cool. But, I mean, the truth is, most of the language I use, either don't have the problems, or that they just aren't extensible enough to fix the problems. To give you a great example, C# is not quite extensible enough... let's say that the problem that I have is I don't like to declare types of variable, the arguments and stuff like that, and I want a dynamic version of the language... maybe that's my problem. Well, C# can't fix that. They are getting closer and closer, they got that bar thing now but it's not really a dynamic language. There's all kinds of places that where you can't... but the language is not powerful enough to fix that part of the language.

Atwood: Well, let me give you a more basic example. In C#, one thing that I find to this day very, very annoying, is when you do String::Format, so you are doing substitution within a string, there's all these cool parameters you can use to figure out, like, what type of date you are going to substitute, what it's going to look like and things like that. All the actual subtitutions themselves are numbered, so you know, {0}, {1}, {2}... which is based on the order of the paramters. Why can't I do named parameters? Why can't I give this a name, like LastName? That'd read so much better than, you know, {0}: it just say {LastName}. And you really can't do that. You can come up with extensions or some sort of workaround-dy kind of stuff, but you can't fundamentally go in and add your own native functions that does it that just mysteriously appears in the runtime. Like in a language in Ruby, I think that's pretty common when you see something...

Spolsky: If you want to write your own little templating string formatting, you could write that in C [sic], couldn't you?

Atwood: In C#? You can, you can write an extension method. But it's not really the same as making it part of the language, it's sort of just exist in your code.

Spolsky: So it won't work in other people's libraries that's calling the built-in format and stuff?

Atwood: No, I mean it does work. You can write your own function and you can call it. But at some level you just want to make a global fix to some of the stuff, because you realize that they are essential wrongs that you want to right, at least in some versions you want to right those wrongs. But it's not really possible in these [languages]... C# mostly being a static language. One cool thing that they are doing actually, they are doing named parameters to functions now. I don't know if you see all of those in C# 4.0?

Spolsky: Uh-oh.

Atwood: You don't like named parameters? So you have to say seven parameters, you can call them in any order as long you specify the name of the parameter that you want.

Spolsky: That's a little bit useful because it makes the code that's calling the function have the ability at least to be a little self-documenting.

Atwood: That's right, so if you have seven parameters to a call [and] you are using only the last one, you don't have to put in "null, null, null, null, null, null, 3".

Spolsky: Why do you want a function that take seven parameters if you only need one of them? Like, why not make it a class that has seven properties and you only have to set the ones that you want to set?

Atwood: Well, this is about flexibility. This is about naming things versus order, this is the same as the string problem, isn't it? For some situations you just want to give things names and call them...

Spolsky: You know what, I liked the named paramters because I actually personally made them put into in VBA because we had a lot of functions in Excel that took a lot of arguments and sometimes you really wanted to use the third and seventh, depending what the function did. And usually when you look at the documentation for those functions, it's because the functions were defined in a bizzare way, like the documention would say: "If you provide the first argument and the third argument, this prints a piece of paper. If you provide the second argument and the seventh argument, this emails a letter to the email address in the seventh argument using the formatting of the template of the second argument. Unless you also provide a seventh argument, in which case, it rolls the dice and decide to turn off your screen or blow up your Macintosh.

Atwood: <laughs> I agree.

Spolsky: At some level you're like "Boy...! If these arguments were names, it'd be so much easier."

Atwood: On some level I agree, you'd be asking like if you have a function with seven parameters, the question you should be asking is not "How can I call the seventh parameter very easily?" but "Why the hell do we have a function with seven parameters?"

[20:06]

....

[68:10 ends]

Outro, advertising

[69:20]