Quotes from Peter Seibel

I always wish people would comment more, though the thing that makes me cringe is when the comment is the name of the function rephrased. Function's called push_stack and the comment says, "This pushes to the stack." Thank you.

When they realize, "Oh, my program's getting gigantic," what are they going to do? They're not going to know where to start. That's my first instinct because I'm a caveman. Really that probably doesn't even matter because you'll just throw more memory at it and it'll be fine.

You don't get credit because the program works. We're going to the next level. Working programs are a given,

But I feel like all of this is looking at the issue from a fairly low level. If there are going to be breakthroughs that make it either impossible or unnecessary to build catastrophes like Windows Vista, we will just need new ways of thinking about what programs are and how to put them together.

Thompson: No, you get around that with idioms in the language. Some people write fragile code and some people write very structurally sound code, and this is a condition of people. I think in almost any language you can write fragile code. My definition of fragile code is, suppose you want to add a feature—good code, there's one place where you add that feature and it fits; fragile code, you've got to touch ten places.

Deutsch: My PhD thesis was a 600-page Lisp program. I'm a very heavy-duty Lisp hacker from PDP-1 Lisp, Alto Lisp, Byte Lisp, and Interlisp. The reason I don't program in Lisp anymore: I can't stand the syntax. It's just a fact of life that syntax matters.

Language systems stand on a tripod. There's the language, there's the libraries, and there are the tools. And how successful a language is depends on a complex interaction between those three things.

Armstrong: Yeah, then all the bits fit together. But maybe I can't explain it to anybody. I just get a very strong feeling that if I start writing the program now it'll work. I don't really know what the solution is. It's like an egg. The chicken's ready to lay the egg. Now I'm ready to lay the egg.

Seibel: Some people love Lisp syntax and some can't stand it. Why is that? Deutsch: Well, I can't speak for anyone else. But I can tell you why I don't want to work with Lisp syntax anymore. There are two reasons. Number one, and I alluded to this earlier, is that the older I've gotten, the more important it is to me that the density of information per square inch in front of my face is high. The density of information per square inch in infix languages is higher than in Lisp.

Then there's a third thing, which may seem like a small thing but I don't think it is. Which is that in an infix world, every operator is next to both of its operands. In a prefix world it isn't. You have to do more work to see the other operand.

When I wrote Volume I of The Art of Computer Programming people didn't realize that they could use linked lists in their own programs, that they could use pointers for data structures.

Peyton Jones: I think probably the big changes in how I think about programming have been to do with monads and type systems. Compared to the early 80s, thinking about purely functional programming with relatively simple type systems, now I think about a mixture of purely functional, imperative, and concurrent programming mediated by monads.

Seibel: Have you heard of refactoring? Cosell: No, what is that? Seibel: What you just described. I think now there's perhaps a bit more acceptance, even among the project managers of this idea.

Seibel: What are the techniques that you use there? Print statements? Armstrong: Print statements. The great gods of programming said, "Thou shalt put printf statements in your program at the point where you think it's gone wrong, recompile, and run it.

Seibel: How do you read code you didn't write? Crockford: By cleaning it. I'll throw it in a text editor and I'll start fixing it. First thing I'll do is make the punctuation conform; get the indentation right; do all that stuff. I have programs that can do that for me, but I find doing that myself is more efficient in the long run because it gets me more acquainted with the code.

Seibel: When you're hiring programmers, how do you recognize the good ones? Crockford: The approach I've taken now is to do a code reading. I invite the candidate to bring in a piece of code he's really proud of and walk us through it.

The code shows me what it does. It doesn't show me what it's supposed to do.

The Web is broken and we need to fix it.

nobody seemed to think programming is a solved problem: most are still looking for a better way to write software, whether by finding ways to automatically analyze code, coming up with better ways for programmers to work together, or finding (or designing) better programming languages.

Moore's law doesn't apply to batteries. So how much time we're wasting in interpreting stuff really matters there. The cycles count.

The funny thing was that that this meant the whole company had been running without mutexes for a couple weeks, and nobody noticed.

you only got 80 words to write your routine, and so you do tend to use things like reusing instructions as data, using a piece of data for more than one thing. If you can manage to put this little subroutine there in memory, then its address can also be used as a data constant. This is what it took-it was origami and haiku and all that as a style of programming. And I spent several years doing that.

intransigence

What we're doing is an aesthetic pursuit. It involves craftsmanship as well as mathematics and it involves people skills and prose skills—all of these things that we don't necessarily think of as engineering but without which I don't think you'll ever be a really good engineer.