link

Gregor writes in his weblog about a conversation he had with Prof. Eberhard Hilf:

hilf demonstrated how equations as jotted down by einstein in 1905 would be almost incomprehensible to modern scientists today. over the years, verbose notations have been replaced by increasingly more succinct ones, new symbols have been introduced. i immediately had to think of leaky abstractions. hilf was adamant that physics was not prone to those problems because it is grounded in solid math.

good for them physicists, and too bad computer science cannot claim the same currently.

Hilf may have misunderstood what leaky abstractions are really about. Had he understood, he probably would have seen that physics and other natural sciences have the exact same problem, and that the mathematical rigor he claims is at best equivalent to the formal definition of computer programs and therefore not even relevant to the problem of leaky abstractions.

First, let me explain the problem of leaky abstractions. As originally explained by Joel Spolsky, leaky abstractions are a challenge to software engineers. Much like mathematics and theoretical science, new achievements in software development build on the foundations already in place. These foundations are abstractions that package up the complexity of other tasks. For example, if you are building a program to download a file over a network, you can use the web protocol, HTTP. Then you can choose a program to serve the file from a number of existing applications, and instead of writing the code to connect to the server, follow the rules of the protocol, and write the file to disk yourself, you can simply invoke an existing piece of software that does this. In highbrow engineering circles, this is called reuse and is highly desirable because it saves development time and avoids creating new code that must be debugged and maintained. It also helps to cement existing standards so that software makers can compete on the basis of innovative features rather than "we crash less".

An abstraction becomes leaky when some of the details it claims to handle leak through and become your problem. Continuing the file-fetching example, what happens if the network is down? You depend on some piece of fetch software to get files, which depends on a network protocol to ensure that two computers can communicate reliably, which depends on a network to allow computers to fling bits at each other. If the network can't handle that job right now, it can tell the network protocol. But the protocol can't do anything about a network that's physically disconnected, so it shrugs. The fetch software you invoked can't do anything about a protocol that won't let it connect, so it shrugs. Your program depends entirely on this piece of software, so you shrug. A leak in the bottommost layer of abstractions has sprung through every other layer, and has to be dealt with outside the realm of the automatic. "Plug in your network cable," your computer says. Do you ever get that message when your cable is still plugged in, but your cat has stepped on a power strip and turned off your network hub? Another leak!

You may already see that leaky abstractions can show up outside of computer science. Do business transactions always go as they should? Have you ever come to a restaurant expecting to get a meal, only to find that they couldn't seat your group? Have you tried to drive home from work in the usual 30 minutes only to find that weather or a car crash dragged that out to 2 hours?

Of course, these are all informal abstractions. In Physics, the abstractions are all mathematically defined. A more rigorous abstraction of driving home from work wouldn't leave any room for leaks. Right?

Well—not exactly wrong nor right. It depends how you look at it. If you're developing the theory alone, you're not going to find that suddenly F = m*a doesn't hold up because e.g. it isn't defined for a = 3 m/s/s; the requirement that definitions be rigorous prevents that. But if you're trying to develop a theory that accurately describes the interaction of actual physical objects, the classical Newtonian abstraction above breaks down at certain points, like when mass is really really small or you're moving really really fast. (More knowledgable readers are welcome to correct/improve my Physics.)

What we see here are two ways to judge the rigor of an abstraction, which I'll call theoretical rigor and applicative rigor. The mathematical foundations of physics ensure its theoretical rigor, but when applied to the description of nature, we can find failures in applicative rigor. Newton's models, though we call them laws, do not accurately describe everything they were once claimed to describe. And applying these laws to real life situations requires accounting for a number of other factors—wind resistance and its ilk. We could qualify the law by describing the highly idealized world it assumes, but that would take too long. We'll settle for expecting the laws of physics to describe limited, idealized versions of what actually happens in real life.

Now back to computing. Most programming languages require that you write well-defined programs—you can't leave out a step and expect the computer to ask you what to do when it gets there. The language usually provides a sensible default, like doing nothing, but this is a way to compress the notation, not to escape rigorous definition. So programming languages, at least those that have an actual deterministic implementation on a computer, actually enforce the constraints of theoretical rigor at least as well as the Physics research community.

But when we take those theoretical tools and apply them to solve problems, we find many leaky abstractions: broken networks flummox our web browsers; buggy data compression libraries leave security holes open in our servers. Each of these bugs is like a wind resistance we hadn't thought of. We hackers had been assuming a simpler world, and so the model of the world we coded for doesn't exactly correspond with the world we're selling software too.

But that's OK: it happens to Physicists too.

• The Curry-Howard Isomorphism describes a relationship between logical proofs/proof systems and computer programs/programming languages. It is described in this Wikipedia entry and at length in this online book.
• I also made a comment in a nerdy discussion on programming language design and the isomorphism at the About Kim weblog.
• Gerald Weinberg's An Introduction to General Systems Thinking teaches you how to think scientifically, including how to respect the limitations of abstraction.
• Joel Spolsky's original essay, The Law of Leaky Abstractions, is a good read and isn't too long.

link

link

Via Gregor's blog, a concise and useful template for planning your career. Nothing groundbreaking in here, but a straightforward approach to writing a plan that will force you to reflect intelligently on your goals and accomplishments.

I've been thinking about making a plan like this for a little while. On one hand, it seems kinda lame; something that ambitioneers (think Harvard undergrads) do in high school and follow to a T. That always seemed dangerous to me, because it would preclude risk and serendipity. I like serendipity. If you could fit that word onto a license plate (SERNDIPT?) I'd seriously consider it.

But planning starts to become appealing once you've left school. The conception of life as an unending journey of 6-month classes suddenly vanishes. After college, I became much more individualistic; the things I do have their most important consequences not for school or for the company, but for my abilities, fitness, happiness, and wealth. Of course, it was always the case that I was in school to better myself, not out of some obligation to the education system; I could have easily dropped out and made enough money to sustain myself. But I never thought about it that way before. In retrospect, schooling is like building personal infrastructure. Now that I'm not 100% focused on my infrastructure, I can take some time to leverage my accumulated education and wisdom and build some really kickass stuff on top of it.

Building really kickass stuff requires a plan. In school, you have little control over your schedule. Sure, you can choose which classes to take, but the choices are extremely constrained. In plain old life, you can switch careers, be unemployed, take long breaks, travel, seduce women, work 80 hour weeks for a year or two, commit crimes, devote yourself to family, or even go back to school. Many of these options are appealing, while others are idiotic. In deciding which is which, the key problem is your limited resources. Too many things are worth doing, and there's not enough time to do them all. In a way, it is about accepting mortality.

But it is also immensely empowering to realize the degree of control you have over the outcome of your life. There's nothing fundamentally different about famous, successful people: they were just lucky or smart at the right times. I've met a few people I consider famous/successful since moving to Boston, people whose achievements I'd be quite proud to match. They are smart, intriguing folks, but they're not infallible. Stack me up against one of them, and I think I'd win on some counts. If they did it, so can I. I just have to make a good attempt. That means I'm making a plan and following it until it seems stupid. And then I'm making a better plan.

link

Zooming in writ large: from outer space to quarks, by orders of magnitude.

link

Evokes the XML overengineering gag response. But I guess you are looking at "faceted metadata".

link

Describes the nested-set model of trees in SQL, which is how trees should be represented in frassle. I did it the simple adjacency list way though, since it was marginally easier and this is prototype software.

link

Visualizing thought tracking/interconnection tool. Maybe. Worth trying, according to Gregor.

link

Linking up the physical world to crazy new ontologies! Maybe… need to read more closely.