lindsey: Dispite the title of the article, Dijkstra isn't arguing against using identifiers that have meaning for the reader e.g. his negative example "disposable." In the very same article he co-opts the term "plural" to mean integer greater than or equal to 2, because of its analagous common meaning. The difference between the two examples, Dijkstra states, is that the first term is used without giving it a precise definition, relying on the reader to make assumptions about what it means. While the latter term is precisely defined when it is used.
Similar things should look different
On the topic of chosing names for api functions that do almost the same thing as each other, the rule of thumb on this is the more similar two things are then the more different their names should be. This is counter-intuitive. Shouldn't the similarity of the names reflect the similarity of their meanings? The answer is no. If both the names are similar and the meanings are similar it is very hard to remember which name goes with which meaning. I learned this from Larry Wall, and I assume he learned it through the hard experience of mistakes in perl's past (chomp, chop).
Similar things should look the same
Sigh. Life is never simple.
name[strlen(name)] = '\0';
Found in a codebase that will remain nameless (variable names have been changed to protect the innocent).
I wrote a patch to give glibc support for profiling multiple shared libraries at once. Right now if you set the environment variable LD_PROFILE to the name of a shared library, glibc will generate gprof style profiling information for that library without you recompiling anything. But that only works with one library at a time. I sent a patch to fix this limitation to the glibc maintainer before the New Year and I've heard nothing back from him yet. Bummer... I don't know if there was something wrong with it, or if it's just not something he's interested in.
I guess I can put the patch up on a web page and let people find it through google. But it seems almost pointless, as it's only a matter of time before the offical codebase moves on and the patch gets stale.
kwoo:If your only problems with Scheme are that the library is too small, and the function names are too long, then getting where you want to go could be as easy as writing a few macro definitions, and some glue code to hook up the missing libraries you want.
The way the weblog space (blogspace) is developing reminds me of the web back in 1994. In the very beginning the web was composed of weakly connected islands of pages. The way you found new pages was through external links, like posts on usenet, or addresses published in print mags like WIRED. Likewise when people first started keeping weblogs, you found them through web pages that were not weblogs themselves. There was not any weblog space to speak of yet.
The web quickly formed its own internal entry points, this was the "Cool Site of the Day" model. Weblogs paralleled this, but in a more distributed manner when they started linking to each other. The way you found new weblogs was when the ones that you already read linked to others that they found interesting. This creating a "browsing" user experience.
The next step the web took was with directory sites like Yahoo. Although directory sites originally intended to provide direct links to information you wanted, they ended up augmenting the browsing proccess by making it faster and more efficient, instead of replacing browsing completely. The weblog space parallels this with backlinks, blogrolling, and other technology enabled by RSS. This is the present state of weblogs.
graydon speaks as if a test is a boring type of proof. I disagree that a test is a proof, and here is why. He formalizes the notion that testing some case, is equivalent to generating a proof for that case:
any test can be translated into a proof in a silly logic easily: the proof is simply the trace of your processor executing your program's code on your test's input, and the logic is one in which each machine transition that happened is an axiom. but that proof is boring
But remember that a test can fail to terminate. We are not converting the test to a proof, but the execution trace of the test. And that is an impossible task for tests that do not terminate.
Although it could seem like this is a silly technicality, it is big enough that you should not consider a test itself any kind of proof, unless it comes with a proof of termination. To me what distiguishes a proof from anything else, is that there is a totally routine way of checking if it is valid or not. A process that might fail to terminate, does not qualify as totally routine.
raph mentions Dijkstra's quote that testing can only show the presence of bugs, never their absence
Implied in this is that if you develop a formal proof that a program is correct, then the testing becomes superfluous. But in fact, some types of testing can reduce the burdon of developing the proof.
Instead of proving that a program is always correct, you prove a weaker condition. That is: if the program is correct in one case then it is correct in all cases. Then you write a test to establish that the one case you did not prove actually works.
One specialized version of this technique is, using a proof to establish the induction step of a proof by induction, but then writing a test in order to establish the base case.
Directories are a conflation of the distinct, and sometimes conficting, requirements of naming and classification.
For naming, we want identifiers that are globally unique and stable over time.
For classification, we want categories that are meaningful and can change over time.
The two sets of requirements are conflicting. In particular, we want categories to have globally unique identifiers, but we can not assume that they will have one globally-unique and unchanging meaning.
A lot would need to be done to replace the current system of directories in UNIX. It has a lot of inertia. Practically every program that interfaces with files expects them to be addressable with some variation of /foo/bar/baz. Plus it took a long time to create the stable, fast, and scalable implementations of the system that we have today.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!