Quotes of the week

[Posted March 14, 2012 by corbet]

Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care.

-- Andrew Morton

Dammit, I'm continually surprised by the *idiots* out there that don't understand that binary compatibility is one of the absolute top priorities. The *only* reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the *worst* offense any kernel developer can do.

-- Linus Torvalds

Kernel developers have thick heads, in most cases thicker than processor manuals.

-- Borislav Petkov

Quotes of the week

Posted Mar 15, 2012 9:41 UTC (Thu) by rvfh (guest, #31018) [Link] (1 responses)

Linus' message is really worth reading in its entirety. I really loved the end of it :-P

Quotes of the week

Posted Mar 16, 2012 11:46 UTC (Fri) by ebirdie (guest, #512) [Link]

I loved the most second sentence, where I read hidden message "serve user-space well or the user-space will come haunt to kernel-space, then anyone will not have fun".

My add: In the end one better to make it clear, on top of user-space and everything sits (or shits) the user. Crap have to flow both ways, if it is plays between.

My addition has a reference to quote of Andrew Morton above Torvald's.

Telling the computer vs telling the reader

Posted Mar 17, 2012 20:08 UTC (Sat) by giraffedata (guest, #1954) [Link] (5 responses)

I go further than Andrew. I say the human reader is the primary consumer of a program. In fact, I say a proper program written in high level language is not instructions to a computer but rather a description of the solution to a computational problem. A compiler's job is to understand that solution and generate instructions to cause a computer to compute it.

I know a lot of programmers have trained themselves to think like computers (or maybe it's that people who already think like computers are the ones who can tolerate programming), so that the two views are one and the same.

Telling the computer vs telling the reader

Posted Mar 22, 2012 10:44 UTC (Thu) by elanthis (guest, #6227) [Link] (4 responses)

In a purely academic sense, I agree with you, and wish that were the way of the world. Unfortunately, sometimes those two views just do have to be one and the same. At sufficiently human-friendly high levels of abstraction, general solutions to computational problems do not directly map to the way that computers actually work, and any form of automatable translation from that solution to computer instructions with today's technologies (much last yesterday's) will be inherently inefficient. For use cases where even small linear efficiency improvements matter, it's critical to write code that a computer can execute efficiently, and for trained programmers to be able to both write and read that code.

That of course includes much/most kernel code.

Note that there's still a big difference between unmaintainable efficient code and readable sane efficient code. In cases where it's hard to make code both, use comments and heavily describe the black magic in the code.

Telling the computer vs telling the reader

Posted Mar 23, 2012 2:14 UTC (Fri) by giraffedata (guest, #1954) [Link] (3 responses)

It's more of a direction than a destination, so other factors such as runtime efficiency do weigh in.

But if you looked at my C code and typical C code where both do the same thing, even if there is no appreciable difference in execution cost, you would see an obvious pervasive difference. The author of the typical code was thinking of von Neumann CPUs when he wrote it; you can almost see the program counter turning in your head as the lines of C go by. It treats variables like registers, you can clearly see branching going on, and you won't see "const" anywhere, since that doesn't affect generated code.

const absolutely affects generated code

Posted Mar 30, 2012 21:03 UTC (Fri) by cbf123 (guest, #74020) [Link] (2 responses)

Declaring something as const allows the compiler to make assumptions about it that it would otherwise not be able to make. This can result in more efficient object code.

That said, I'm firmly in the "comment why you are doing something, not what you are doing" unless the mechanics of what is being done is non-obvious enough to need explanation. It needs to be readable by the next person to look at it (which may be yourself in ten years by which time you've forgotten all the details).

const absolutely affects generated code

Posted Mar 31, 2012 2:31 UTC (Sat) by giraffedata (guest, #1954) [Link]

I know the theory that the compiler can do better optimization with const, but I've never been able to isolate a particular case where it does. In any case, I know the vast majority of my consts won't affect generated code, and the main reason is that they are on variables private to the compilation unit, so the compiler can see without my help whether the variable gets set or not.

"assert" is similar. The original theory behind a coded assertion is that it could help the compiler generate better code, but I'm pretty sure that has never been realized. I use lots of asserts and the purpose is neither to generate better code nor to make the program crash when the assertion fails. Like const, it's to help the reader read the code.

const absolutely affects generated code

Posted Apr 2, 2012 13:08 UTC (Mon) by jwakely (subscriber, #60262) [Link]

In a few rare cases, yes. But usually adding const doesn't change anything.

If the variable definition and everything you do to the variable is visible to the compiler (either because it's all in one file or you have global optimisation) then the compiler knows if it's modified or not, adding const doesn't help optimisation. If the definition is in one translation unit but most operations on it are in different translation units which get a pointer-to-const (or reference-to-const) those other TUs can't know whether the variable was really declared const, adding const to the definition doesn't help optimisation.

http://www.gotw.ca/gotw/081.htm

Quotes of the week

Posted Mar 24, 2012 19:54 UTC (Sat) by oldtomas (guest, #72579) [Link]

It's as the old masters say:

Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

Donald Knuth, Literate Programming