Peter Seibel > Quotes

“Armstrong: I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“We’re all optimists in our profession or we’d be forced to shoot ourselves. - Joshua Bloch”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Norvig: I think one of the most important things is being able to keep everything in your head at once. If you can do that you have a much better chance of being successful. That makes a small program easier. For a bigger program, you need extra tools to be able to handle that.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“[On identifying talented programmers] It’s just enthusiasm. You ask them what’s the most interesting program they worked on. And then you get them to describe it and its algorithms and what’s going on. If they can’t withstand my questioning on their program, then they’re not good. I’m asking them to describe something they’ve done that they’ve spent blood on. I’ve never met anybody who really did spend blood on something who wasn’t eager to describe what they’ve done and how they did it and why. I let them pick the subject. I don’t pick the subject, so I’m the amateur and they’re the professional in this subject. If they can’t stand an amateur asking them questions about their profession, then they don’t belong. - Ken Thompson”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“And once I realized that code I write never fucking goes away and I'm going to be a maintainer for life. I get comments about blog posts that are almost 10 years old. "Hey, I found this code. I found a bug," and I'm suddenly maintaining code.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Readability of code is now my first priority. It's more important than being fast, almost as important as being correct, but I think being readable is actually the most likely way of making it correct.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“But in the meantime there's no reason to starve the users for [syntactic] sugar. It doesn't rot their teeth and it helps them avoid mistakes. — Brendan Eich”
― Peter Seibel

“Zawinski: Sometimes. I end up doing all the sysadmin crap, which I can't stand-I've never liked it. I enjoy working on XScreenSaver because in some ways screen savers-the actual display modes rather than the XScreenSaver framework-are the perfect program because they almost always start from scratch and they do something pretty and there's never a version 2.0. There's very rarely a bug in a screen saver. It crashes-oh, there's a divide-by-zero and you fix that.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Ironically, as a result of his move to the country, Cosell- one of the fathers of the Internet-now has only dial-up access from his home.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“He came in and took a piss in my hotel bathroom without even closing the door as I'm standing right there. I'm like, "Alright. You're comfortable." It was like we knew each other for four or five years, even though we had never met.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“The experience of writing something in Java and then trying to figure out—I myself have trouble installing Java on my computer—it's horrible.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Joe Armstrong: I think the lack of reusablility comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle”
― Peter Seibel

“Fitzpatrick: Back when I was doing Perl-even for people that knew Perl really well-I would recommend MJD's Higher-Order Per!. The book is really fun in that it starts somewhat simple and you're like, "Yeah, yeah, I know what a closure is." And then it just continues to fuck with your head. By the end of the book, you're just blown away.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Knuth: They were very weak, actually. It wasn't presented systematically and everything, but I thought they were pretty obvious. It was a different culture entirely. But the guy who said he was going to fire people, he wants programming to be something where everything is done in an inefficient way because it's supposed to fit into his idea of orderliness. He doesn't care if the program is good or not—as far as its speed and performance—he cares about that it satisfies other criteria, like any bloke can be able to maintain it. Well, people have lots of other funny ideas. People have this strange idea that we want to write our programs as worlds unto themselves so that everybody else can just set up a few parameters and our program will do it for them. So there'll be a few programmers in the world who write the libraries, and then there are people who write the user manuals for these libraries, and then there are people who apply these libraries and that's it. The problem is that coding isn't fun if all you can do is call things out of a library, if you can't write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who'd want to go into that as a career? There's this overemphasis on reusable software where you never get to open up the box and see what's inside the box. It's nice to have these black boxes but, almost always, if you can look inside the box you can improve it and make it work better once you know what's inside the box. Instead people make these closed wrappers around everything and present the closure to the programmers of the world, and the programmers of the world aren't allowed to diddle with that. All they're able to do is assemble the parts. And so you remember that when you call this subroutine you put x0, y0, x1, y1 but when you call this subroutine it's x0, x1, y0, y1. You get that right, and that's your job.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“So there's that change and then there's the change that I'm really worried about: that the way a lot of programming goes today isn't any fun because it's just plugging in magic incantations—combine somebody else's software and start it up. It doesn't have much creativity. I'm worried that it's becoming too boring because you don't have a chance to do anything much new. Your kick comes out of seeing fun results coming out of the machine, but not the kind of kick that I always got by creating something new. The kick now is after you've done your boring work then all of the sudden you get a great image. But the work didn't used to be boring.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“There's a brilliant quote by Tony Hoare in his Turing Award speech about how there are two ways to design a system: “One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: There's a Dijkstra quote about how you can't prove by testing that a program is bug-free, you can only prove that you failed to find any bugs with your tests. But it sort of sounds the same way with a proof-you can't prove a program is bug-free with a proof-you can only prove that, as far as you understand your own proof, it hasn't turned up any bugs.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“the advantage of some ignorance; it leaves some room for creativity. But sometimes it feels like ignorance is endemic in this industry-that people are unaware of things and wheels are constantly being reinvented with pointy corners.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“One that's tricky is slight spelling errors in variable names. So I choose variable names that are very dissimilar, deliberately, so that error won't occur. If you've got a long variable like personName and you've got personNames with an “s” on the end, that's a list of person names, that will be something that my eye will tend to read what I thought it should have been. And so I'd have personName and then listOfPeople. And I do that deliberately because I know that my eye will see what I thought I'd written.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Something I worry about a lot when I write, that I'm less worried about with a computer, is about the ways in which English is ambiguous. I'm constantly worrying about ways in which the reader might misinterpret what I've written. So I've actually spent a lot of time consciously crafting the mechanics of my prose style to use constructions that are less likely to be misinterpreted.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I've done this business long enough to understand that there are some very hard problems. But very few. It's invariably the case that when they think about it harder, it gets easier and all of a sudden it's easy to program correctly.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Steele: Yeah. And not knowing the future. If I could change one thing-this is going to sound stupid-but if I could go back in time and change one thing, I might try to interest some early preliterate people in not using their thumbs when they count. It could have been the standard, and it would have made a whole lot of things easier in the modern era. On the other hand, we have learned a lot from the struggle with the incompatibility of base-ten with powers of two.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“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.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“an open-plan cubicle kind of thing-working, doing something, writing some Lisp program. And he'd come shuffling in with his ceramic mug of beer, bare feet, and he'd just stand behind me. I'd say hi. And he'd grunt or say nothing. He'd just stand there watching me type. At some
point I'd do something and he'd go, "Ptthh, wrong!" and he'd walk away. So that was kind of getting thrown in the deep end. It was like the Zen approach-the master hit me with a stick, now I must meditate.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“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.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“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.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: I was looking at one of your papers from the 70s about your Fortran profiler. In the preamble you were very enthusiastic about how that tool changed your programming from figuring out what you were going to write, writing it, and debugging it, to figuring out what you were going to write, writing a really simple version, profiling it, then optimizing it.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“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.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: Other than the possibility of implementing it at all, how do you decide whether your interfaces are good? Steele: I usually think about generality and orthogonality. Conformance to accepted ways of doing things. For example, you don't put the divisor before the dividend unless there's a really good reason for doing so because in mathematics we're used to doing it the other way around. So you think about conventional ways of doing things. I've done enough designs that I think about ways I've done it before and whether they were good or bad. I'm also designing relative to some related thing that I've already designed before. So, for example, while looking at the specifications for numeric functions in Java, I'd already done numeric functions for Common Lisp. And I'd documented numeric functions for C. I knew some of the implementation pitfalls and some of the specification pitfalls for those things. I spent a lot of time worrying about edge cases. That's something I learned from Trenchard More and his array theory for APL. His contention was that if you took care of the edge cases then the stuff in the middle usually took care of itself. Well, he didn't say it that way; I guess that's the conclusion I draw from him. To turn it around, you want to design the specification of what's in the middle in such a way that it naturally is also correct on the boundaries, rather than treating boundaries as special cases.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I sometimes feel a bit afraid about the commercial world with, on the one hand, the imperatives of getting it done because the customer needs it next week and, on the other hand, the sheer breadth rather than depth of the systems that we build.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming