Quotes About Programming

I do love TV as a medium.

With films, you are not so much on a schedule. TV is all about scheduling.

In theater, we know a scheduled season months in advance.

PHP as an object oriented programming language should be judged by how well it does the job, not on a preconceived notion of what a scripting language should or shouldn't do.

In Lisp, if you want to do aspect-oriented programming, you just do a bunch of macros and you're there. In Java, you have to get Gregor Kiczales to go out and start a new company, taking months and years and try to get that to work. Lisp still has the advantage there, it's just a question of people wanting that.

The mind's goal is not to get at the truth but to fulfill our needs, and like a computer with very specific programming, the mind's interpretations are based on what's already known or believed.

And, if the "programming" (our beliefs) is flawed or the data is incorrect, then false conclusions will show up in place of what's true. Perceptions will be biased, but will appear to simply reflect reality.

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.

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

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.

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.

Assembly level programming] kind of still separates the chest hair—gender-independent—programmers from those who don't quite have it. — Brendan Eich

But if you ask me, is STM better than locks and condition variables? Now you're comparing like with like. Yes. I think it completely dominates locks and condition variables. So just forget locks and condition variables. For multiple program counters, multiple threads, diddling on shared memory on a shared-memory multicore: STM. But is that the only way to write concurrent programs? Absolutely not.

I think the primary limitation on software is not the speed of computers but our ability to get our heads around what it's supposed to do.

The really good programmers spend a lot of time programming. I haven't seen very good programmers who don't spend a lot of time programming. If I don't program for two or three days, I need to do it. And you get better at it—you get quicker at it. The side effect of writing all this other stuff is that when you get to doing ordinary problems, you can do them very quickly. - Joe Armstrong

Peyton Jones: For me, part of what makes programming fun is trying to write programs that have an intellectual integrity to them. You can go on slapping mud on the side of a program and it just kind of makes it work for a long time but it's not very satisfying. So I think a good attribute of a good programmer, is they try to find a beautiful solution. Not everybody has the luxury of being able to not get the job done today because they can't think of a beautiful way to do it.

A sequential implementation of a double-ended queue is a first-year undergraduate programming problem. For a concurrent implementation with a lock per node, it's a research paper problem. That is too big a step. It's absurd for something to be so hard. With transactional memory it's an undergraduate problem again.

Seibel: One way to resolve that is the way Lisp does—make everything uniformly semiconcise. Where the uniformity has the advantage of allowing users of the language to easily add their own equally uniform, semiconcise, first-class syntactic extensions.

There was a bug in GDB!

I think it's not an accident that we often use the imagery of magic to describe programming. We speak of computing wizards and we think of things happening by magic or automagically. And I think that's because being able to get a machine to do what you want is the closest thing we've got in technology to adolescent wish-fulfillment.

I have this big allergy to ivory-tower design and design patterns. Peter Norvig, when he was at Harlequin, he did this paper about how design patterns are really just flaws in your programming language. Get a better programming language. He's absolutely right. Worshipping patterns and thinking about, "Oh, I'll use the X pattern.

when you're writing programs you need to be able to name your identifiers well. And your prose has to be good. I'd feel lost without a good dictionary.

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.

I can't say beginner programmers should open up all these abstractions. But what I am saying is you should certainly consider the possibility of opening them. Not completely reject the idea. It's worthwhile seeing if the direct route is quicker than the packaged route.