In many of our interactions with the outside world (solipsists can stop reading now, if indeed they ever started) we enter into contracts with diverse entities, some up front, some lurking below the surface. The commonly construed contractual theme is a mutual agreement where each party accepts certain costs and responsibilities, and in return can rely on certain benefits and rewards. Some sort of symmetry is implied, in that the rational parties favored by the economists (when they come out of their recessionary hiding holes) will weigh the positive and negative impacts of the agreement before "signing." I will put aside the notions of Hobbes, Rousseau, Rawls, and that crowd that in merely being born—a mixed blessing to which nobody freely consents—we enter into some form of social contract with the combined prevailing laws of nature, nurture, and parliamentary whoredom.
We do our best, of course, to discern, codify, and obey the often-conflicting rules set by Life's Grand Game. I refer you to the vast literature on ethics, altruism, selfish genes, crime and punishment, and the dangers of universal gravity, hot pokers, and programming in Basic. But where is the free choice, predictability, or mutuality? Einstein was doubly mistaken. Nature does play dice, and, be warned, the dice are randomly loaded! Einstein was right about space-time: geometry is cruelly bent. Don't be fooled by Playfair's axiom.1 I support the Irish Olympic luge captain who demanded a level playing field.
In laypersons' terms, why do rotten things happen to nice people like us? The Woody Allen option of "Returning to the womb. Any womb!" has practical problems if taken literally. Lest you detect some senile pessimism as I approach my four-scored birthday (refuting all the warnings against a wicked lifestyle), I must add that I would not have missed Life for all the World. It's avoiding that possible Afterlife Inferno that keeps me going. Do I get to see the Erdös Book of perfect proofs, or will St Peter's Clipboard (also known as the Lamb's Book of Life) record that I used 3,141 GOTOs in 1968 alone, and left a particularly expensive ELSE a-dangling on September 15, 1985? (She has never forgiven me.) Such sins, they reckon, will consign me to an eternal Dantesque zero-Kelvin ice block alongside some obscure pope or famous software methodologist.
Interrupting this tasteless digression, I note that the word contract is stress-related, both phonetically and medically. Using that overworked apostrophe as a syllable-stress marker, we can see that con'tract and contract' occupy remarkably disparate semantic areas, even though conventional etymologies offer no clue as to why a shift of stress should shift the meaning so violently. We (or rather I) have no idea whether the Romans varied the syllabic stresses in contraho/contractum to indicate our current distinction between contract' (to draw together, reduce the compass of, abridge) and con'tract (an agreement or covenant between two parties; or to enter into such).
Logophiliacs are bound to chuckle over this blatant semantic somersault, given that their most recent encounter with con'tracts was probably a multipage, unabridged, uncontract'ed agreement with some software vendor, scrolling off the screen for days in shouting CAPs. Furthermore, the final options presented were: Agree? YES/NO. Surveys, if conducted, would show that 98.39 percent (with an error margin to be announced later) of us click YES without reading the furthermores and wherefore-to-afters. At least, with these contracts, we can't complain of sneaky small-print clauses. We know that clicking NO usually aborts the installation, and we are anxious to try out our new purchase. We have already broken the cellophane wrapper (there, that's giving my age away again!), which some lawyers say amounts to waiving our 28th Amendment rights: "The People shall have the inalienable right to Free Healthcare, Free Car Insurance, Free High-speed Internet Access, and Provably Bug-free Code." (The full details should be ironed out by the time you read this column.)
Yet, deep down, many of us sympathize with the vendors' convoluted precautions. They face an over-litigious culture like the rest of us. We are all potential software vendors these days, and already have on our desks or laps2 (and/or floating above in the clouds3) the physical and mental equipment needed to become the next Microsoft or Google (or the next AOL if things don't work out). For each Facebook there are many Friends United (or never meeting, as the case may be). For every Apple there's a Lemon.
Which reminds me to recommend a most challenging article on Steve Jobs ("The god of cool things") by the perfectly named Bryan Appleyard (Sunday Times magazine, August 16, 2009). I leave it to your judgment whether Jobs's medical tribulations (of truly Biblical proportions) deserve the normal reticence accorded to those who seek privacy on their health status, or whether the prospects for a post-Jobs Apple, and its impact on shareholder speculation, should override the conventional decencies. Appleyard does offer a reasonably balanced account of Jobs's remarkable ups and downs, adding a few psychological insights (Michael Maccoby's "productive narcissism?") that may be new to Apple followers. Of Jobs's iconic "rock-god status" and "insanely great" ego, we read, "'He would have made,' said Jef Raskin, the brain behind the Mac, 'an excellent King of France!'"
Relevant to my theme of Everyman the Code-Warrior is the amazing success of iPhone and iPod Touch applications. Appleyard suggests that Apple has been "stunned" by the response to opening up the iPhone to outside software developers. Apple keeps tight control over the distribution of apps (now approaching 100,000 with more than 2 billion downloads), but the break with Apple's traditional antipathy to third-party software has surprised the market. In regard to the unpredictability of the NBT (Next Big Thing), Jobs quotes approvingly Henry Ford's motto: "If I'd asked my customers what they wanted, they'd have said a faster horse."
I too ducked the NBT prediction quiz in a recent interview with Jan Samols, editor of the CamRing journal, which aims at keeping ex-members of the Cambridge University Mathematical Laboratory in touch with those working at its successor, the William Gates Computing Laboratory.
Q What's going to be the Next Big Thing?
A Liverpool FC's 14th league championship? Think Red, not Black Swan! A boom in property values? Economical energy from fusion? But on the medium-/near-term technological front, you've posed the essentially unanswerable question, in so far as the answer might well vitiate the prediction.
(For those who noticed the error, Liverpool has been awaiting its 19th league championship for 20 years. I evaded blame by saying 14 was written using my favorite base, 15.)
Are you ready to exploit the huge programming opportunities and create the NBT? The 1929 recession saw distressed bankers selling apples on the Wall Street sidewalk (a hard myth to disprove). The current recession could be a distressed you flogging Apple apps at a yard sale.
q
LOVE IT, HATE IT? LET US KNOW
STAN KELLY-BOOTLE (http://www.feniks.com/skb/; http://www.sarcheck.com), born in Liverpool, England, read pure mathematics at Cambridge in the 1950s before tackling the impurities of computer science on the pioneering EDSAC I. His many books include The Devil's DP Dictionary (McGraw-Hill, 1981), Understanding Unix (Sybex, 1994), and the recent e-book Computer Language—The Stan Kelly-Bootle Reader. Software Development Magazine has named him as the first recipient of the new annual Stan Kelly-Bootle Eclectech Award for his "lifetime achievements in technology and letters." Neither Nobel nor Turing achieved such prized eponymous recognition. Under his nom-de-folk, Stan Kelly, he has enjoyed a parallel career as a singer and songwriter. He can be reached at [email protected].
© 2009 ACM 1542-7730/09/1200 $10.00
Originally published in Queue vol. 7, no. 11—
Comment on this article in the ACM Digital Library
Dennis Roellke - String Matching at Scale
String matching can't be that difficult. But what are we matching on? What is the intrinsic identity of a software component? Does it change when developers copy and paste the source code instead of fetching it from a package manager? Is every package-manager request fetching the same artifact from the same upstream repository mirror? Can we trust that the source code published along with the artifact is indeed what's built into the release executable? Is the tool chain kosher?
Catherine Hayes, David Malone - Questioning the Criteria for Evaluating Non-cryptographic Hash Functions
Although cryptographic and non-cryptographic hash functions are everywhere, there seems to be a gap in how they are designed. Lots of criteria exist for cryptographic hashes motivated by various security requirements, but on the non-cryptographic side there is a certain amount of folklore that, despite the long history of hash functions, has not been fully explored. While targeting a uniform distribution makes a lot of sense for real-world datasets, it can be a challenge when confronted by a dataset with particular patterns.
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx in Action
DevEx (developer experience) is garnering increased attention at many software organizations as leaders seek to optimize software delivery amid the backdrop of fiscal tightening and transformational technologies such as AI. Intuitively, there is acceptance among technical leaders that good developer experience enables more effective software delivery and developer happiness. Yet, at many organizations, proposed initiatives and investments to improve DevEx struggle to get buy-in as business stakeholders question the value proposition of improvements.
João Varajão, António Trigo, Miguel Almeida - Low-code Development Productivity
This article aims to provide new insights on the subject by presenting the results of laboratory experiments carried out with code-based, low-code, and extreme low-code technologies to study differences in productivity. Low-code technologies have clearly shown higher levels of productivity, providing strong arguments for low-code to dominate the software development mainstream in the short/medium term. The article reports the procedure and protocols, results, limitations, and opportunities for future research.