CodersAtWork

From Wiki

Jump to: navigation, search

JWZ

C++ is just an abomination
On Perl - Oh, I despise it It’s a horrible language. But it is installed absolutely everywhere.
Eventually I figure out that what’s going on is this is one of the early machines that did speculative execution. It would execute both sides of the branch. And GDB would always take the branch if you single-stepped past a branch instruction. There was a bug in GDB!
You’re not here to write code; you’re here to ship products.
Just figuring out how to get from point A to point B— how to make the machine do what you want. That’s the basic element that the satisfaction of programming comes from.
Are you trying to write good software or are you trying to be done by next week? You can’t do both.
Maybe that’s the caveman thoughts: “Back in my day, we programmed with a nine-volt battery and a steady hand!”
I remember thinking that was a really good book, not because I learned anything from it, but because it was the book you wish your idiot coworker had read.
Seibel: Is there a key skill programmers must have? Zawinski: Well, curiosity—taking things apart. Wanting to know what’s going on under the hood. I think that’s really the basis of it.

Brad Fitzpatrick

This is why I really love Perl. As ugly as the syntax is and as much historical baggage and warts as it has, it never fucks with me and tells me what style to write in.
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.
It’s always easier to do something right the first time than to do a migration with a live service. That’s the biggest pain in the ass ever.
Seibel: Do you like C++? Fitzpatrick: I don’t mind it. The syntax is terrible and totally inconsistent and the error messages, at least from GCC, are ridiculous.
The way they think about solving things is always within the space they know. They don’t think end-to-end as much.
In practice, nothing works. There are all these beautiful abstractions that are backed by shit. The implementation of libraries that look like they could be beautiful are shit.
Everyone wants to do a web site where their favorite four web sites aren’t quite right and they want to make one that looks kind of like that.
Always try to do something a little harder, that’s outside your reach. Read
I like working alone but I just bounce all over the place when I do. On a plane I’ll bring extra laptop batteries and I have a whole development environment with local web servers and I’ll be in a web browser, testing stuff. But I’ll still be hitting new tabs, and typing “reddit” or “lwn”—sites I read. Autocomplete and hit Enter, and then—error message. I’ll do this multiple times within a minute. Holy fuck! Do I do this at work? Am I reading web sites this often that I don’t even think about it? It’s scary.
Programmers’ time is worth more and all that crap? Which can be true. This is true for a small number of machines. Once you get to a lot of machines, all of a sudden the programmers’ time is worth less than the number of machines that this will be deployed against, so now write it in C and profile the hell out of it, and fix the compiler, and pay people to work on GCC to make this compile faster.
Users always like to get the one with the higher version number even if it sucks more.

Douglas Crockford

The problem with the language is that it was rushed to market way too fast and standardized way too fast. So most of its defects are not in the current implementations—they are in the specification. (on Javascript)
The worst feature of JavaScript, without question, is its dependence on a global object. It doesn’t have linkers, it doesn’t have any kind of information hiding between compilation units. It all gets dumped together into a common global object.
Mash-ups realize something that we’ve been trying to do in software for 20 years: to have interesting reusable components that we can snap together like LEGO and make new applications out of, instantly.
One of the things I’ve been pushing is code reading. I think that is the most useful thing that a community of programmers can do for each other—spend time on a regular basis reading each other’s code.

Brendan Eich

We have found fuzz testing to be more productive than almost any other kind of testing.
As far as programming goes, I was doing, like I said, low-level coding. I’m not an object-oriented, design-patterns guy. I never bought the Gamma book.
Staying close to the metal was my way of keeping honest and avoiding the bullshit, but now, you know, with time and better, faster hardware and an evolutionary winnowing process of good abstractions versus bad, I think people can operate above that level and not know assembly and still be good programmers and write tight code.
At SGI, the kernel, of course, was where the real programmers with chest hair went, and there you couldn’t screw around.
The immediate concern at Netscape was it must look like Java.(on JS)
I’m not really looking for respect,especially from the Java-heads or the trailing edge. (on ES4)s
I never played with any Self code, but I was just inspired by them. (on inspiration for JS)
Maybe we’re entering the second golden age; there’s more interest in languages and more language creation. We talk about programming: we need to keep practicing the craft—it’s like writing or music. But the language that you use—the tonal system—matters too.
I don’t mind eclecticism. Though Ruby does seem kind of overhyped.
There’s sort of a programming ziggurat—the Right Stuff, you know. People are climbing towards the top, even though some of the tops sometimes fall off or lose a toe.
We’re also trying to move the research needle because—this is something else that was obvious to me, even back when I was in school, and I think it’s still a problem—there are a lot of problems with academic research. It’s swidely separated from industry.
Academia has not been helpful in leading people toward a better model. I think academia has been kind of derelict.
The go-to-market, ride Moore’s law, and compete and deal with fast product cycles and sometimes throwaway software — seems like a shame if that’s all everybody does.
Proofs are hard. Most people are lazy. Larry Wall is right. Laziness should be a virtue. So that’s why I prefer automation.
Like Joel, I’m skeptical of rewrites. I think it’s rare to find that kind of an alignment of interests and get enough funding to live through it and not miss the market. The exceptions are very rare. (on the big netscape rewite)
I think young people have enormous advantages, just physiological advantages to do with the brain. What they don’t have is the wisdom! You get crustier and maybe you get slower but you do learn some painful lessons that you try to pass on to the next generation. I see them ignoring me and learning them the hard way, and I shake my fist!
I am not JavaScript. In the early days, it was such a rush job and it was buggy and then there was some Usenet post Jamie Zawinski forwarded me. He said, “They’re calling your baby ugly.” I have real kids now; I don’t have to worry about that.

Further Reading - Curry Howard correspondence. Hindley-Milner type inferences, Andreas gal, Robert O'Callahan debugger - chronomancer, Replay, Smalltalk books, Adele Goldberg, Berkeley Oink framework,Zen and the Art of Motorcycle Maintenance

Joshua Bloch

IM ruins my life. No, email ruins my life—IM is just a distraction.
I think Dijkstra, God rest his soul,was entirely wrong about that. I know so many really good programmers who got their start programming BASIC because that’s what was available to them.
I consider inheritance a mixed
The more things you learn and the younger you learn them, the better off you are.
Generally speaking, I find that, contrary to popular belief, the cleaner and nicer the program, the faster it’s going to run. And if it doesn’t, it’ll be easy to make it fast. As they say, it’s easier to optimize correct code than to correct optimized code.
when you choose a language, you’re choosing more than a set of technical trade-offs—you’re choosing a community. It’s like choosing a bar. Yes, you want to go to a bar that serves good drinks, but that’s not the most important thing. It’s who hangs out there and what they talk about.
I think, to some degree programming was a refuge from aspects of life that I couldn’t handle.
The need for math is much greater in the community that writes libraries, compilers, and frameworks. If you write web applications on top of frameworks, you have to understand communication, both verbal and visual.
The fundamental rule is, write the code that uses the API before you write the code that implements it.
I am doing test-first programming: I’m testing the quality of the API, when I code up the use cases to see whether the API is up to the task.
The fundamental theorem of API design is, when in doubt, leave it out.
I do disagree with Martin (Fowler) on one point: I don’t think tests are even remotely an acceptable substitute for documentation.
The other thing is—how can I put this delicately—I tend not to buy into religions, any religions, whole hog. Whether it’s object-oriented programming or functional programming or Christianity or Judaism—I mine them for good ideas but I don’t practice them in toto.
Companies establish their DNA very early on. It can make them tremendously successful, but it can also make it hard for them to escape when what served them well in the early days doesn’t serve them so well any more.
there was this sort of cultural meme at Google that Java is slow and unreliable. And it’s obvious where it came from: Blackdown Java on Linux, around 1999, was slow and unreliable. And old ideas die very hard.
Even today, writing unit tests for concurrency utilities is an art form.
students should learn low-level languages. In fact, they should learn assembly language, and even chip architecture. Though chips have turned into to these unbelievable complicated beasts where even the chips don’t have good performance models anymore because of the fact that they are such complicated state machines. But they’ll be much better high-level language programmers if they understand what’s going on in the lower layers of the system.
I don’t think STM will succeed as a tool that lets the application programmer stop worrying about locks and live in a beautiful world where threads don’t interfere with one another. It’s just not going to happen.
Intelligence is not a scalar quantity; it’s a vector quantity. And if you lack empathy or emotional intelligence, then you shouldn’t be designing APIs or GUIs or languages.

Further Reading - Parnas information hiding, Elements of Style, Hacker’s Delight, The Elements of Programming Style, The Mythical Man Month, Java Concurrency in Practice, How to Design a Good API and Why It Matters” at OOPSLA, On the Cruelty of Really Teaching Computing Science by Djikstra, Java Puzzlers, Engineering a Sort Function, The Feel of Java - James Gosling, Nearly All Binary Searches and Mergesorts Are Broken, The Psychology of Computer Programming

Joe Armstrong

The funny thing is, thinking back, I don’t think all these modern gizmos actually make you any more productive.
the problem with objectoriented 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.
Bottom up. I write a little bit and test it, write a little bit and test it. I’ve gone over to this writing test cases first, now. Unit testing. Just write the test cases and then write the code. I feel fairly confident that it works.
Prolog is so different to all the other programming languages. It’s just this amazing way of thinking. And it’s not appropriate to all problems. But it is appropriate to an extremely large set of problems. It’s not widely used. And it’s a great shame because programs are incredibly short. I think I went into shock when I wrote my first Prolog program. It’s a kind of shocking experience. You just walk around going, where’s the program—I haven’t written a program. You just told it a few facts about the system, about your problem. Here it is figuring out what to do. It’s wonderful. I should go back to Prolog—drop Erlang.
Oh, if you’re no good at English you’ll never be a very good programmer.
Spend 20 percent of your time learning stuff—because it’s compounded.
It’s kind of feng shui. I like minimalistic code, very beautifully poised, structured code. If you start removing things, if you get to the point where if you were to remove anything more it would not work any more—at this point it is beautiful.

Further Reading - Hamming’s advice to young researchers

Simon Peyton Jones

my main insight about small companies: to be an entrepreneur you need to get energy from stressful situations involving money, whereas my energy is sapped by stressful situations involving money.
computer science is very fractal—almost everything turns out to be interesting, because the subject grows ahead of you. It’s not like a fixed thing that’s there that you’ve got to discover. It just expands.
I think in some ways a PhD is an odd preparation, even for research.
I characterize functional programming—that is, purely functional programming, where side effects are somehow really relegated to a world of their own—as a radical and selegant attack on the whole enterprise of writing programs.
I see it as, when the limestone of imperative programming is worn away, the granite of functional programming will be observed.
What are programming languages for in the end? They’re to make it easier to program. They’re the user interface of programming, in effect.
laziness is cool; what a great programming idiom.
People often ask, “What’s the equivalent of UML diagrams for a functional language?” And I think the best answer I’ve ever been able to come up with is, it’s the type system.
types are like a very compact specification language.
I don’t even have any very sophisticated Emacs jiggery-pokery.
I hate it when those hourglasses appear.
So the thing about STM is you want to make sure that one person, or one team, gets to implement STM and everybody else gets to use it. You can pay them a lot of money and shut them in a small dark room for a year to try to make sure they do a really good job. But then that work is usable by everybody through a very simple interface. That’s what I think is nice about it. What I want to avoid is having that level of expertise in everybody’s head.
there’s this horrible danger that people who are any good at anything get promoted or become more important until they don’t get to do the thing they’re any good at anymore.
GHC is pretty large—it’s not large by industrial standards; it’s large by functional programming standards—it’s about 80,000 lines of Haskell, maybe a bit more. And it’s long-lived—it’s 15 years old now.
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 most depressing thing about life as a programmer, I think, is if you’re faced with a chunk of code that either someone else wrote or, worse still, you wrote yourself but you no longer dare to modify. That’s depressing.

Further Reading - Robin Milner, Arthur norman, David Turner’s papers on S-K combinators, John Backus "Can Programming Be Liberated from the von Neumann Style", John Hughes’s paper, “Why Functional Programming Matters.”, Journal of Functional Programming, Zipper data structure, Quickcheck haskell library, Pepe Iborra interactive debugger, Software transactonal memory, Tim Harris - STM in Java, Jon Bentley’s Programming Pearls, Beautiful Code (book), Chris Okasaki’s book Purely Functional Data Structures, Structure and Interpretation of Computer Programs - Abelson and Sussman, Compiling with Continuations - Andrew Appel, A Discipline of Programming by Dijkstra, Per Brinch Hansen’s concurrent operating systems, The Secrets of the GHC Inliner, The Computer Scientist as Toolsmith - Fred Brooks, retrospective on Haskell - POPL 2004.

Peter Norvig

It took me four years to get sick of school and only two years to get sick of work, maybe I like school twice as much.
When I was in school, working as a team was called cheating.
I think a lot of programming is being able to keep as much as you can inside your head, but that only goes so far, at least in my head. Then you have to rely on other people to have the right abstractions so that you can use what they have.
I see tests more as a way of correcting errors rather than as a way of design. (TDD)
I remember one of the great lessons I got about programming was when I showed up at the airport at Heathrow, and there was a power failure and none of the computers were working. But my plane was on time.
There’s some saying in German about the perfect being the enemy of the good; I forget exactly where it comes from—every practical engineer has to learn that lesson.
I never liked any of these UML-type tools. I always thought, “If you can’t do it in the language itself that’s a weakness of the language."
Rather than tweak it a little bit at a time, I’ll just throw away a couple hundred lines of code, rewrite it from scratch, and often then the bug is gone.
Seibel: What about The Art of Computer Programming? Some of the people I’ve talked to on this have absolutely read it from cover to cover. Some people have it on the shelf and use it as a reference. And some people just have it on the shelf. Norvig: At one point I had it as my monitor stand because it was one of the biggest set of books I had, and it was just the right height. That was nice because it was always there, and I guess then I was more prone to use it as a reference because it was just right in front of me.
One of the interesting things we found, when trying to predict how well somebody we’ve hired is going to perform when we evaluate them a year or two later, is one of the best indicators of success within the company was getting the worst possible score on one of your interviews. We rank people from one to four, and if you got a one on one of your interviews, that was a really good indicator of success.
We have hundreds of millions of users and we can make a difference for them, and we can launch new services for them quickly. I think that’s great. I can’t imagine anything else I could be doing to have that level of impact.

Further Reading - Christopher Strachey - Scientific American, Knuth's books, CLR algorithms books, Sally Goldmans book on algorithms, Knuth - Literate Programming.

Guy Steele

This experience of being, in effect, both at MIT and Harvard at the same time I now realize was a very unusual experience. I could run back and forth and say, “The professor at the other end of the river says this.” And this one will say, “Oh, he’s full of it; here’s the way you should think about it.” That gave me a very broad education, very quickly.This experience of being, in effect, both at MIT and Harvard at the same time I now realize was a very unusual experience. I could run back and forth and say, “The professor at the other end of the river says this.” And this one will say, “Oh, he’s full of it; here’s the way you should think about it.” That gave me a very broad education, very quickly.
Having access to MIT as a high schooler was another relatively unusual thing. And to be allowed to play with million-dollar computers when I was 15, back when a million dollars was real money.
the biggest change is that nowadays you can’t possibly know everything that’s going on in the computer. There are things that are absolutely out of your control because it’s impossible to know everything about all the software.
If it’s a piece of software that I know how to use and just don’t know how the insides work, I will often pick a particular command or interaction and trace it through.
There have been exactly two times, I think, that I was not able to fix a bug in my TeX macros by reading The TeXbook and it was necessary to go ahead and read TeX: The Program to find out exactly how a feature worked. In each case I was able to find my answer in 15 minutes because TeX: The Program is so well documented and cross-referenced. That, in itself, is an eye-opener—the fact that a program can be so organized and so documented, so indexed, that you can find something quickly.
I think if a program is well written, there will be something about its structure that will guide me to various parts of it in an order that will make some kind of sense. You know, it’s not just what the program does—there’s a story. There’s a story about how the program is organized, there’s a story about the context in which the program is expected to operate. And one would hope that there will be something about the program, whether it’s block comments at the start of each routine or an overview document that comes separately or just choices of variable names that will somehow convey those stories to you. And one would hope that a good programmer, a really good programmer, will have given thought to conveying those stories in addition to the story of what the program actually does.
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.
I got to thinking that maybe for a really successful programming language, you need to design and plan for the social process as much as you design the technical features of the language and think about how those two things are going to interact.
Well, if a language doesn’t die, it is going to grow. There are always evolutionary pressures because needs change and people will want to modify the tool to suit where they are now as opposed to where they were five years ago.- I feel perfectly free, when doing algorithm design, to use a hodgepodge of different languages. As long as I’m just communicating with myself I will go to a whiteboard and write fragments of Java and Fortran with APL mixed in. It doesn’t bother me in the least as long as I can sort out what I’ve written afterwards. For a particular piece of the algorithm the notation is buying me something that I think another language wouldn’t be nearly as clear or useful for.
I don’t think it’s worth fighting over, but I think it’s reasonable to have opinions about what is a more effective tool for a given task. (on programming language wars)
It’s really hard to make a language that’s great at everything, in part just because there are only so many concise notations to go around. There’s this Huffman encoding problem. If you make something concise, something is going to have to be more verbose as a consequence.
I think the decision to be backwards-compatible with C is a fatal flaw. It’s just a set of difficulties that can’t be overcome. C fundamentally has a corrupt type system. It’s good enough to help you avoid some difficulties but it’s not airtight and you can’t count on it.
It’s much easier now to write the kinds of programs we were trying to write 30 years ago. But I think our ambitions have grown tremendously. So I think programming is probably a more difficult activity than it was 30 years ago.
I will say that about once a month I get the feeling that I wish that in designing Fortress we had started with Haskell and tried to move it toward Fortran and Java, rather than starting with Fortran and Java and trying to move it toward Haskell. We are finding ourselves taking more and more of a functional approach as we design the Fortress libraries as we encounter the difficulties of trying to make efficient parallel data structures.
Programming is a highly unnatural activity, I’m convinced, and it must be carefully
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.

Further Reading - The lambda papers - Guy Steele and Gerald Sussman, Gerald Weinberg on The Psychology of Computer Programming, Fred Brooks’s Mythical Man-Month, “Growing a Language” at OOPSLA 1998, Fortress language, Peter van der Linden - Expert C Programming, CACM - parallel garbage collector - David Gries && Susan Owicki

Dan Ingalls

Seibel: Alan Kay has said that both Lisp and Smalltalk have the problem that they’re so good they eat their children.
I can think of lots of areas where trying to standardize, trying to all go in one direction, has suppressed creativity. I work at a company that’s supported by Java, so I’m not going to go very far with this, but it is the case that when Java came out—the easiest way I had of measuring it was looking at what went on at OOPSLA—when Java came out not only did work slow down and even maybe come to a halt on other object-oriented programming languages but even in dynamic programming in general. I think that was a loss.
In the spectrum of implementers, I probably err on the side of just making things happen. A lot of that is because I get so much of a thrill bringing things to life that it doesn’t even matter if it’s wrong at first. The point is, that as soon as it comes to life it starts telling you what it is.
Ultimately, nothing that’s really good ever gets really lost.
The world moves forward slowly.
My one wish for the mainstream, in the context of computer science, is that people would go back to first principles a little bit more about ways to leverage computing in the intellectual space.
You have to know that at some point we’re going to cross a threshold where computers will be doing a better job thinking about stuff than we do.
I don’t think that people are playing around with, tinkering with that stuff enough. Because, Lord, the machines we have today—if you have a minor breakthrough there you could do incredible stuff.
It was envisioned as a language for kids—children of all ages—to use Alan’s original phrase. (on Smalltalk)
our turnaround time for making changes in the system from the beginning was seconds, and subsecond fairly soon. It was just totally alive. And that’s something which I, and a bunch of the other people, got a passion for. Let’s build a system that’s living like that. That’s what Smalltalk became.
To think outside the box, you’ve got to be a little outside the box. If there’s something to be taken advantage of that you don’t see in your normal exposure to a language, then you’ve got to have some intuition outside and some understanding of that and the ability to work in a system that has control over that.
Computers incorporate some powerful ideas and can bring some powerful ideas to life. The wonderful thing about computers is they bring mathematics to life. So they can be a great tool that way.
To me, the really exciting thing about computers is they allowed mathematics to become a synthetic, not just an analytic art.
I tried to learn to play piano fairly late in life. People said, “Oh, you should learn when you’re young. You learn so much quicker.” Although I didn’t go very far, my conclusion was that it isn’t that young people learn that much faster; it’s just they have more time. When I would put time in, I made progress.
I work with younger people and it’s great—maybe I spend a bit more time thinking at the level of goals and politics and arranging to make things happen, and they’re making up for what I lack in available time for that deep, deep dive.
Seibel: Do you have any tips on how to be a good technical leader? Ingalls: The first thing is being clear about what you’re trying to do. The job is to get a clear vision. If you’ve been around, you can see actually how you’re going to implement that, so you can start to see how that would work out in terms of what various people can do and how it would all fit together. There have been times when I’ve been working on a project where I could see everything. It felt really powerful because whenever anybody was stuck I could tell them immediately what the next step was, or how to get around it. And people feel that, too, if you know where you’re headed. They can immediately sense it’s all there—he’s got it. And that’s empowering for the team as well.
I kind of feel like the better a language is, the less you need comments.
Smalltalk’s got a lot of strengths but it’s not the answer to everything.

Further Reading - Lively Kernel, Squeak, Hypercard, Seymour Papert - Mindstorms, Val Schorre’s paper on META II

L Peter Deutsch

Music is kind of interesting because on the spectrum of formality it falls between natural languages and computer languages. It’s more formal and structured than a natural language, but it doesn’t have nearly the structure or formality of a computer language.
I do know that the further down in the plumbing the software is, the more important it is that it be built by really good people. That’s an elitist point of view, and I’m happy to hold it.
I think part of the problem with the other kind of programming is that the world of basically all programming languages that we have is so different in such deep ways from the physical world that our senses and our brains and our society have coevolved to deal with, that it is loony to expect people to do well with it. There has to something a little wrong with you for you to be a really good programmer.
The physical properties of matter are such that 99.9 percent of the time you can understand it in aggregate. And everything you have to know about it, you can understand from dealing with it in aggregate. To a great extent, that is not true in the world of software.
Software is a discipline of detail, and that is a deep, horrendous fundamental problem with software. Until we understand how to conceptualize and organize software in a way that we don’t have to think about how every little piece interacts with every other piece, things are not going to get a whole lot better. And we’re very far from being there.
You’d have to throw out all languages that have the concept of a pointer to begin with because there is no such thing as a pointer in the real world. You’d have to come to grips with the fact that information takes space and exists over time and is located at a particular place.
To me the distinction is between people who understand what the questions are that you have to ask in doing larger-scale design and the people who for whatever reason don’t see those questions as well.To me the distinction is between people who understand what the questions are that you have to ask in doing larger-scale design and the people who for whatever reason don’t see those questions as well. (on the mentality to build larger scale systems)
There’s nothing wrong with being a coder. There’s nothing wrong with being a bricklayer, either. There’s a lot of skill that goes into doing it well. But it represents such a small corner of the whole process.
That’s an issue I’ve had with a number of people who are very much into rapid prototyping or any form of software development that doesn’t treat it as engineering. I seriously question how well software not built from an engineering point of view lasts.
One school of thought, which I think is probably pretty close to the way XP looks at it, that basically says that because requirements are going to change all the time, you shouldn’t expect software to last. If the requirements change, you build something new. There is, I think, a certain amount of wisdom in that.
The problem being the old saying in the business: “fast, cheap, good—pick any two.”
Part of the reason that I don’t call myself a computer scientist any more is that I’ve seen software practice over a period of just about 50 years and it basically hasn’t improved tremendously in about the last 30 years.
If you look at programming languages I would make a strong case that programming languages have not improved qualitatively in the last 40 years. There is no programming language in use today that is qualitatively better than Simula-67. I know that sounds kind of funny, but I really mean it. Java is not that much better than Simula-67.
I use the word qualitatively very deliberately. Every programming language today that I can think of, that’s in substantial use, has the concept of pointer. I don’t know of any way to make software built using that fundamental concept qualitatively better.
Jim Morris, who’s one of my favorite originators of computer epigrams, once said that a type checker is just a Neanderthal correctness-prover
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. Python has a great language, great libraries, and hardly any tools.
Lisp as a language has fabulous properties of flexibility but really poor user values in terms of its readability.
The other reason why I like Python syntax better, which is that Lisp is lexically pretty monotonous.
Seibel: I think Larry Wall described it as a bowl of oatmeal with fingernail clippings in it. Deutsch: Well, my description of Perl is something that looks like it came out of the wrong end of a dog. I think Larry Wall has a lot of nerve talking about language design—Perl is an abomination as a language. But let’s not go there.

Further Reading - Seven Fallacies of Distributed Computing, Ghostscript code, Leo Guibas work, Gordian Knot, E - the language based on capability, Dave Gifford - FX language

Ken Thompson

Most of the time, it sits in the back of my mind—nothing on paper—for a period of time and I’ll concentrate on the hard parts. The easy parts just fade away—just write ’em down; they’ll come right out of your fingertips when you’re ready. But the hard parts I’ll sit and let it germinate for a period of time, a month maybe. At some point pieces will start dropping out at the bottom and I can see the pyramid build up out of the pieces. When the pyramid gets high enough in my mind, I’ll start at the bottom.
Modern programming scares me in many respects, where they will just build layer after layer after layer that does nothing except translate. It confuses me to read a program which you must read top-down. It says “do something.” And you go find “something.” And you read it and it says, “do something else” and you go find something and it says, “do something else” and it goes back to the top maybe. And nothing gets done. It’s just relegating the problem to a deeper and deeper level. I can’t keep it in my mind—I can’t understand it.
Code by itself almost rots and it’s gotta be rewritten. Even when nothing has changed, for some reason it rots.
Documenting is an art as fine as programming. It’s rare I find documentation at the level I like. Usually it’s much, much finer-grained than need be. It contains a bunch of irrelevancies and dangling references that assume knowledge not there. Documenting is very, very hard; it’s time-consuming. To do it right, you’ve got to do it like programming. You’ve got to deconstruct it, put it together in nice ways, rewrite it when it’s wrong. People don’t do that.
I think MIT has always had an inferiority complex over Unix.
I didn’t think that Lisp was a unique enough language to warrant a machine. And I think I was proved right. There’s no need to build a Lisp machine that’s not faster. There was just no reason to ever build a Lisp machine. It was kind of stupid.
Seibel: So you basically wrote an OS so you’d have a better environment to test your file system.
Ninety-nine percent of the time something simple and brute-force will work fine. If you really are building a tool that is used a lot and it has some sort of minor quadratic behavior sometimes you have to go in and beat on it. But typically not. The simpler the better.
Typically a complex algorithm requires complex code. And I’d much rather have a simple algorithm and simple code than some big horror. And if there’s one thing that characterizes my code, it’s that it’s simple, choppy, and little. Nothing fancy. Anybody can read it.
Compilers stink. You look at the code coming out of GCC and it’s awful. It’s really not good. And it’s slow; oh, man. I mean, the compiler itself is over 20 passes. It’s just monstrously slow, but computers have gotten 1,000 times faster since GCC came out. So it may seem like it’s getting faster because it’s not getting slower as much as computers are getting faster underneath it.
Garbage collection fights cache coherency massively. And there’s no garbage-collection algorithm that is right for all machines. There are machines where you can speed it up by a factor of five or more by messing around with the cache. They should be tied to the machine much more than they are. Usually they treat them as separate algorithms that have nothing to do with machines, but the cache coherency is very important for garbage-collection algorithms.
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. (on interviewing).
I write mostly in C. I do all my test stuff and toy stuff in C while Google is C++, strictly C++. It’s no big deal programming in C++, but I don’t like it. I resist it.
I would try out the language as it was being developed and make comments on it. It was part of the work atmosphere there. And you’d write something and then the next day it wouldn’t work because the language changed. It was very unstable for a very long period of time. At some point I said, no, no more. In an interview I said exactly that, that I didn’t use it just because it wouldn’t stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language. I never said it was a bad language. On and on and on. Since then I kind of avoid that kind of stuff. (on C++)
By and large I think it’s a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, “I wrote it; here, take it.” It’s way too big, way too complex. And it’s obviously built by a committee. (on C++)
Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said “no” to no one. He put every feature in that language that ever existed. It wasn’t cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that. (on C++)
I love yacc. I just love yacc. It just does exactly what you want done. Its complement, Lex, is horrible. It does nothing you want done.
It’s much more reliable—there’s no doubt about that. And I’ve looked at the code occasionally. I don’t look at it as much as I used to. I used to, for Plan 9. They were always ahead of us—they just had massively more resources to deal with hardware. So when we’d run across a piece of hardware, I’d look at the Linux drivers for it and write Plan 9 drivers for it. Now I have no reason to look at it. I run Linux. And I occasionally look at code, but rarely, so I can’t really tell whether the quality has gotten better or not. But certainly the reliability has gotten better.
The programming style here at Google is so bizarre. They take a subroutine call, package it as an RPC, and store it somewhere static. Which means anybody can call it at any time for any reason. And then they call generic listening kind of code and somebody somewhere gets a message, goes off and finds that, and makes that subroutine call.

Further Reading - Plan 9, ACM Turing address

Fran Allen

By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are . . . basically not taught much anymore in the colleges and universities.
Languages like C totally overspecify the solution of problems. Those kinds of languages are what is destroying computer science as a study. The core thing is that it specifies location of data. If you look at these other languages, they stayed away from specifying the location of data and how to move it, where to put it in the machine. It was ultimately about its value at any point.

Further Reading - Edith Schonberg

Bernie Cosell

One of the things about a real-time system is everything has to be timed out. You can’t wait forever for anything because there’s no forever in a real-time system.
You can’t explore a new idea in doing something if you are not craftsman enough to make the computer do what you had in your mind.
I had two convictions, which actually served me well: that programs ought to make sense and there are very, very few inherently hard problems. Anything that looks really hard or tricky is probably more the product of the programmer not fully understanding what they needed to do and pounding it with a hammer ’til they got code that looked like it did the right thing.I had two convictions, which actually served me well: that programs ought to make sense and there are very, very few inherently hard problems. Anything that looks really hard or tricky is probably more the product of the programmer not fully understanding what they needed to do and pounding it with a hammer ’til they got code that looked like it did the right thing.
A case in point was when the Rubik’s Cubes arrived. We had just heard rumors about this wonderful puzzle and one of the guys was on a business trip to England and brought back a satchel of them. No books, no documentation, not yet a phenomenon in the U.S. at all. Just a strange little group theoretic puzzle. And we started to play with it. Several of us solved the puzzle in different ways, but it was interesting that we were able to cope with a puzzle like that. It’s just that that group of BBN people back then had the right stuff. That was what I used to look for.
I think that the actual production of code—of working, logical, good code—requires an intensity and a mental agility in terms of picking up new things that I, at least, find hard to do now. The other side of the coin is that you get a certain wisdom about things that you certainly didn’t have when you were younger. I know better now how to do things.
It’s hard for me to think of any folks in the really stellar category who did it just a couple hours a day as if it were a job. Almost everyone I know would do it with this burst of maniacal focus and intensity and then get it done. But the focus is hard. It really wears you out. It certainly used to wear me out.
The artist part decides that the design should be elegant. Those fit together because in computer programs the artistry affects the longevity of it. Part of what I call the artistry of the computer program is how easy it is for future people to be able to change it without breaking it. That doesn’t have anything to do with constructing its functionality but with its life as an existing thing.
It has been such a boon in systems programming. The idea that we would write our systems in assembler and all our applications in Pascal sent shivers down my spine. I don’t think that was the right answer. But writing both systems and applications in C, I would have to say has proven just not to work very well. It’s just too hard.
I remember the wars in the days of Pascal. The argument was that computers should help you; that C was too dangerous a language. The two big voices I remember were Wirth and Dijkstra. On the other side was every systems programmer I know, including me. I wrote everything in C. So C sort of steamrolled the zillions of languages back then.
I am still stunned almost every day that it borders on the impossible to write a program of any real complexity in C and not have a security problem.
Java didn’t feel right. My old reflexes hit me. Java struck me as too authoritarian. That’s one of the reasons why I mentioned that Perl felt so good, because it’s got the safety and the checks but it is so damn multidimensioned that the artist part of me has a lot of free board to express things clearly and to think about the right way to do things. I have some freedom.
Maybe the world has gotten so dangerous you can’t have a good, flexible language that one percent or two percent of the programmers will use to make great art because the world is now populated with 75 million run-ofthe-mill programmers building these incredibly complicated applications and they need more help than that. So maybe Java’s the right thing. I don’t know.
Each generation of programmers gets farther and farther away from the low-level stuff and has fancier and fancier tools for doing things. The good part is they can do cleverer things. The baseline is so good that the next thing is spectacular and that then becomes the baseline and two years later it becomes even better. The trouble is that these baselines are getting more and more complicated. The PDP-1 instruction set was like a walk in the park compared to some of the stuff that’s happening.

Don Knuth

I think that’s a fundamental error made by scientists in every field. They don’t realize that when you’re learning something you’ve got to see something at all levels. You’ve got to see the floor before you build the ceiling. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it.
I’m constantly torn between saying, “Well, this is too complicated; you’d better not talk about it at all,” and the other feeling that people are saying, “But all you’ve put in your book is just so trivial; there’s nothing good.” I can argue at any particular time that I should cut everything out or that I have way too little.
I consider it amazing that some people do go cover to cover in my books. In most cases I know that people are going to pick and choose the parts that they like. But they know that if they dig further then they’ll get something that has only one subset of jargon describing it instead of all different kinds of notations and terminology—if I didn’t write the books it would be much harder for people to find stuff out. That’s what turns me
One of the things I learned was how much software occupies the brain. It was a much more difficult task than I expected. I couldn’t teach classes full-time and write software full-time. I could teach classes full-time and write a book full-time but software required so much attention to detail. It filled that much of my brain to the exclusion of other stuff. So it gave me a special admiration for people who do large software projects—I would never have guessed it without having been faced with that myself.
I think programming is a lot like religion; people have their beliefs. Some people like to force their beliefs on others. Others say, you know, here’s what I think; I can’t prove that this is the best thing, but it sure works for me. Then you hope that other people will try it and come to the same conclusion. But I don’t like going out and telling people what they ought to believe.
So literate programming is based on this idea that the best way to communicate is to say things both informally and formally that are related. And it just provides a natural framework for switching between the natural language, English, and the formal language, C or Lisp or whatever is your formal language, and putting this together. So that, to me, has to be a win for documentation.
This is what literate programming is so great for—I can talk to myself. I can read my program a year later and know exactly what I was thinking.
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.
To me one of the most important revolutions in programming languages was the use of pointers in the C language. When you have nontrivial data structures, you often need one part of the structure to point to another part, and people played around with different ways to put that into a higherlevel language. Tony Hoare, for example, had a pretty nice clean system but the thing that the C language added—which at first I thought was a big mistake and then it turned out I loved it—was that when x is a pointer and then you say, x + 1, that doesn’t mean one more byte after x but it means one more node after x, depending on what x points to: if it points to a big node, x + 1 jumps by a large amount; if x points to a small thing, x + 1 just moves a little. That, to me, is one of the most amazing improvements in notation.
Pointers have gone out of favor to the point now where I had to flame about it because on my 64-bit computer that I have here, if I really care about using the capability of my machine I find that I’d better not use pointers because I have a machine that has 64-bit registers but it only has 2 gigabytes of RAM. So a pointer never has more than 32 significant bits to it. But every time I use a pointer it’s costing me 64 bits and that doubles the size of my data structure. Worse, it goes into the cache and half of my cache is gone and that costs cash—cache is expensive.
I hope that the idea of an individual programmer writing programs in order to learn something is not a dying breed.
Well, I’ve been a nitpicker all my life. So if I can get my kicks out of finding errors then I just have to make sure that I forget that I was the author of the program. I try to imagine that somebody else was the author. But otherwise it’s fairly easy for me to get into attack mode. I don’t know why.
If we restrict ourselves to the things that are really easy, then that’s not satisfactory because our appetite is always to push the boundary and go until it gets to something we can barely do. And once we’ve got to there, then we’re going to want to push that boundary and so on.
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.
Oh my God, yes. I’ve got this need to program. I wake up in the morning with sentences of a literate program. Before breakfast—I’m sure poets must feel this—I have to go to the computer and write this paragraph and then I can eat and I’m happy. It’s a compulsion; that I have to admit.
When I put in the calculation of prime numbers into the TeX manual I was not thinking of this as the way to use TeX. I was thinking, “Oh, by the way, look at this: dogs can stand on their hind legs and TeX can calculate prime numbers.”
The idea that people knew a thing or two in the ’70s is strange to a lot of young programmers.
It’s inevitable that in such a complicated field that people will be missing stuff. Hopefully with things like Wikipedia, achievements don’t get forgotten the way they were before. But I wish I could also instill in more people the love that I have for reading original sources. Not just knowing that so-andso gets credit for doing something, but looking back and seeing what that person said in his own words. I think it’s a tremendous way to improve your own skills.
A couple of years ago I found an old Sanskrit document from the 13th century that was about combinatorial math. Almost nobody the author knew would have had the foggiest idea what he was talking about. But I found a translation of this document and it was speaking to me. I had done similar kinds of thinking when I was beginning in computer programming.
It was just basically the way you solve some kind of an unknown puzzle—make tables and charts and get a little more information here and make a hypothesis. In general when I’m reading a technical paper, it’s the same challenge. I’m trying to get into the author’s mind, trying to figure out what the concept is. The more you learn to read other people’s stuff, the more able you are to invent your own in the future, it seems to me.

Further Reading - Computing Reviews, Programming Proof of a Program: FIND - Tony Hoare,The Errors of TeX, Lions Book, Bill Atkinson’s programs