This BBC headline reads “Cambridge cycling: one in three journeys is on a bike.” But is that true? If you actually live and work in Cambridge, and compare the numbers of motor vehicles and cyclists on the roads, or the numbers of car and bicycle parking spaces, that figure does not seem right. Certainly there’s a lot of cycling—more than in any other city on the UK—but one in three journeys does not seem credible.
When I wrote “The tabular method” I drew a figure showing all the ways to triangulate an oriented convex polygon, from the unique way to triangulate a triangle up to the 14 ways to triangulate a hexagon. I drew it by hand using Inkscape, but I felt there was something unsatisfactory about that: if I can write a program to count the triangulations, ( I ought to be able to write a program to draw them! )
A lesson I had to learn several times when I worked in video games is that the addition of user options has to be consciously resisted. The desire to add a user option often indicates that you have skimped on a important piece of usability work and are trying to put off doing it. ( Now, you’re probably already saying, “but what about—” at this point )
In Vernor Vinge’s 1999 novel A Deepness in the Sky the protagonist learns what it means to become a programmer–archaeologist:
Programming went back to the beginning of time… Behind all the top-level interfaces was layer under layer of support. Some of that software had been designed for wildly different situations. Every so often, the inconsistencies caused fatal accidents. Despite the romance of spaceflight, the most common accidents were simply caused by ancient, misused programs finally getting their revenge.
“We should rewrite it all,” said Pham.
“It’s been tried. But even the top levels of fleet system code are enormous. You and a thousand of your friends would have to work for a century or so to reproduce it. And guess what—even if you did, by the time you finished, you’d have your own set of inconsistencies. And you still wouldn’t be consistent with all the applications that might be needed now and then. The word for all this is ‘mature programming environment’.”
( I often think of this passage when taking on a new project… )
Dynamic programming is an important technique for writing combinatorial algorithms, in which you divide a problem into sub-problems, like in good ol’ divide-and-conquer, except that the sub-problems may overlap, so you build up a table of these problems and their solutions in order to avoid repeated work. But the name sucks: the technique is no more or less ‘dynamic’ than many other techniques, and ‘programming’ is a fossil: as we’ll see below, the ‘program’ referred to is the output of the technique, not the implementation of the technique itself. I can recall being confused by the name when studying algorithms as an undergraduate: I knew that ‘linear programming’ referred to the optimization of linear functions under linear constraints, but what did the ‘dynamic’ in ‘dynamic programming’ refer to? The name was a small but genuine barrier to understanding the technique.
There’s a conventional piece of software development wisdom, to the effect that if writing your own programming language is an absurd and wasteful activity, because developing a programming language is a hideous time-sink, and because some existing language is almost certain to satisfy your needs perfectly well. ( There’s a good deal of truth in this advice... )
p4.el, the Emacs/Perforce Integration, provides an interface to the Perforce software version management system from the Emacs text editor. Written originally by Eric Promislow, with important contributions from Rajesh Vaidheeswarran, Peter Österlund, and many others, it’s a piece of software that I have used more or less every day for the last thirteen years.
( However, the SourceForge repository hasn’t seen any development since 2005, and it has been looking a bit ragged around the edges for a few years now. )
This is a problem that had me puzzled for a while, but has a really simple solution, so I’m writing it up here in case it might be useful to other developers who find themselves in this slightly bizarre situation.
Imagine that you are developing a web site using the Django framework. ( The underlying database has been in production for some years... )
The very first sentence of Peter F. Hamilton’s Great North Road (2012) reads:
As midnight approached, the wild neon colours of the borealis storm came shimmering through the soft snow falling gently across Newcastle upon Tyne.
How is that possible? Auroras take place high in the sky, in the thermosphere (above 80 km), but if it’s snowing then it must be cloudy in the lower troposphere (stratus clouds have a base around 2 km), so it would seem very unlikely that you could see an aurora “through snow”. Some more explanation is needed, and it’s not provided. So is this just an unlucky slip, or an example of systematic failure to think through the consequences of the settings and events in the novel? ( Let’s read on and find out. )
Inspired by David Jones’ “My Favourite Bugs”, here’s one of my own war stories.
Console video games are demanding pieces of software to write: in addition to being entertaining, they must be playable by six-year-olds and self-explanatory to adults. They must be able to gracefully handle corrupted save files. They must never run out of memory, be unresponsive to user input, or take longer than 16 ms to draw the next frame. Oh, and you typically only get one chance to get it right: when the game has to go out to manufacture on cartridge or DVD there’s no chance to fix things with a version 1.1.
The Hydrogen Sonata is the ninth novel in the Culture series by Iain M. Banks. It is set in the civilization of the Gzilt, which is on the verge of ‘subliming’—that is, departing the physical universe to become immortal beings of pure energy. As the big day approaches, one question still niggles: what was the origin of the Gzilt’s suspiciously well-informed ‘Book of Truth’? ( Genuine religious inspiration or hoax by ancient meddling aliens? )
Hereditary aristocrats order the building of palaces; plan colonies and wars; plot, scheme, and murder each other; all while watching for signs of rebellion among the slaves who make their life of luxury and backstabbing possible. ( But unlike in the Roman Empire, on the planet Cyteen the slaves cannot even dream of freedom. )
Imagine that you have in your hands a mysterious book titled Just Walk. ( It seems to be some kind of manual of advice on how to walk, and includes useful tips like these... )
In his last novel Fiasco, published in 1986, Stanisław Lem returned to one of his idées fixes, the impossibility of meaningful contact with aliens. In Solaris (1961) scientists studied a living ocean but found only their own preoccupations reflected back; and in His Master’s Voice (1968) the meaning of a radio signal from the stars became more elusive the more effort went into decoding it.
Bad reviews are a basic fact of literary life, you might have thought. There are so many different kinds of literary taste, that no book can be all things to all readers. One person’s comfort reading is another’s trash, and what’s thought-provoking to one is high-faluting nonsense to another. But the essential subjectivity of taste is hard to keep in mind when it’s your favourite book that’s getting a pasting: what seemed to the reviewer to be a careful and evidence-based summary of the book’s failing, seems to you to be an attack on your taste, your culture, and your personality. To criticize something you like is tantamount to criticizing you, and that’s personal, damn it!
Jim Chisholm asked me to write an article for the newsletter of the Cambridge Cycling Campaign about the public perception of law-breaking among cyclists, how this arises and persists through cognitive biases, and some consequences for campaigners. I think most of the material will be pretty familiar to my readers here, but you never know.
( There’s a general belief in this country that cyclists are a bunch of scofflaws )
A list of Don’ts for women on bicycles, c. 1895 has been doing the rounds. It consists of about 20% good advice (“don’t criticize people’s ‘legs’”) to 80% sexism (“don’t use bicycle slang: leave that to the boys”). But what on earth does this mean:
There’s something about reviewing that has been troubling me for a while: ( how do you decide by which aesthetic standards to measure the work under review? )
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
zvi and krja
