Vivek Haldar

Operations should be in the computer science curriculum

Tue, 29 May 2012 05:58:02 -0700

CS 2013 is a proposal to update the computer science curriculum. Anyone interested in learning or teaching computer science should read the whole thing. I think it does an admirable job not just of providing coverage, but also outlining the principles for selecting topics, and impressing upon the reader the complexity and nuance of this task.

That said, I want to point out one glaring omission. I realized its importance only after working in the real world for a few years, and being schooled in how inadequately prepared my CS education had left me in this arena.

That topic is operations. It encompasses all the activities required to keep a computing service deployed, performant and available. Chances are, if you work in the industry today, even if your title is something like “programmer” or “software engineer”, operations will be some component of your job. The fraction of time you spend on operations might fluctuate between 0% and 100%, but it will certainly exist.

In broad strokes, operations includes the following:

Production design: okay, your shiny new system is code complete. How exactly will it be deployed? How many machines? What kinds of machines? What resources does it need? What are the failure modes of your system? What happens if x% of your machines go down? What happens if all your machines go down? Under what failure circumstances can the service continue to limp along, as opposed to being completely unavailable? The answers to all these questions makes up the production design of your system.
Deployment: how would you automate the process of pushing new code? Of taking the entire system up and down? Taking subcomponents of the system up and down? How will you do a rolling restart of all your machines?
Monitoring: how will you get visibility into the performance and health of your system? This includes inserting hooks to measure key characteristics (qps, latency etc.) as well as collecting and visualizing them automatically, in a way that will make sense to a bleary-eyed person who has been woken up by a page at 3 AM.
Alerting: okay, you’ve done a great job of monitoring the health and performance of key system metrics. Now how will you notify yourself when something goes wrong? This includes figuring out the exact thresholds of the metrics after which the system is deemed unhealthy. This really needs to be foolproof. You don’t want your system to be down, and not even get paged about it.

In short, being responsible for the uptime of your own code gives you a whole new perspective when you write it. You start thinking about what could happen in there that might page you at 3 AM. You also realize how writing code is but one step in the never-ending cycle of deploying, tweaking, and writing again.

Where might this fit into a computer science curriculum? One option would be to make it an additional component of existing programming exercises, by having students deploy their programs on test systems and simulating failures, and then seeing how well their monitoring and alerting holds up. An interesting twist might be to have students be responsible for the upkeep of not their own but other students’ programs.

Also see: the CS assignment I wish I’d had.

At just the right time, the cloud cover actually let us see the...

Sun, 20 May 2012 21:43:57 -0700

At just the right time, the cloud cover actually let us see the solar eclipse with naked eyes.

Executable Thought

Sun, 20 May 2012 12:15:10 -0700

Imagine that you were a teacher in ancient Greece. Your expository traditions were firmly rooted in the practice of oral argument and knowledge transfer. And then along came this newfangled thing called “writing”. It pulled thoughts from your brain and committed them to something more permanent, and even more terrifyingly, allowed others who understood these symbols to receive those thoughts without your presence. To top it all off, it encouraged your brain to become feeble, now that it did not have to hold the entirety of human knowledge. You were resistant to this new medium. Your current ways of creating and conveying thoughts were doing just fine.

If, in the above paragraph, you substitute “writing” for “oral argument”, and “coding” for “writing”, it will sum up the current debate on whether you should learn how to code.

But the whole debate on learning to code is missing the larger point of the thought processes and mentality it takes to code. Like Dijkstra said, computer science is as much about computers as astronomy is about telescopes.

After all, why should the mayor learn how to code? Is he now going to start writing apps?

The current debate also entirely misses the question of gradation. Take mathematics for example. It is pretty important for the population at large to understand arithmetic, and possibly also some algebra. That’s why everyone learns those topics in school. But is it equally important for the entire populace to be well-versed in the intricacies of group theory and vector spaces? Probably not.

Instead of talking about coding, we should be talking about computational literacy. Being fluent in a programming language is just one aspect of that, and a pretty advanced one. There are other topics and ways of thinking that need to come first in the curriculum of computational literacy. And perhaps, some of those ideas and ways of thinking that come before coding in this ladder are sufficient for the general population.

Note that computational literacy has absolutely nothing to do with being able to fluently use computers. Just like being a good driver doesn’t mean you have a good grasp of mechanical engineering.

Jeanette Wing refers to this as computational thinking, and makes the case for it being a useful interdisciplinary mode of thought¹.

To build the case for broadly teaching computational thinking, we need to look at the major transitions in modes of human thought through the history of civilization.

The earliest known mode was perhaps what we now know of as the Greek school, when knowledge was held in brains and created and transferred through an intricate and time-consuming culture rooted in oral debate and discussion. This was spoken thought.

The next big transition was to written thought. This was the first major leap in the scalability of thoughts. Their total number was not limited to the capacity of human brains. They could be transferred without the presence of the original thinker.

The next leap along the same lines was printing–which made thoughts orders of magnitude easier to reproduce and spread. This is what truly cemented the supremacy of written thought.

And now we’re seeing the beginnings of the next major mode of thought–executable thought.

Executable thought arises when written things can be automatically consumed and manipulated. This breathes life into what previously was just an inert string of symbols. The most obvious example of this is a computer compiling and executing something written in a traditional programming language. This is also the thing that most often hooks people into becoming programmers–the idea of converting pure thought into action.

But it does not have to stop there. The form of the idea does not have to be “code” in the traditional sense. Take, for example, something as innocuous as a hyperlink. If you were to think about it with the old written thought frame of mind, it would be just a citation. But if you were to think about it computationally, and with a rudimentary understanding of page rank, that one link would become the trigger for a sequence of computational actions that have implications for the authority, trustworthiness and findability of both sides.

Another example: biologists have been better able to understand a number of processes when wearing their computational, rather than the life sciences, hats².

This idea of thought being executable already permeates most of the commercial and physical infrastructure of the world around us, and very soon, someone who cannot think this way will feel like an alien in it. To put it another way, computational thought will become a necessary prerequisite to function in a computational world.

Jeannette M. Wing, Computational Thinking; Communications Of The ACM March 2006/Vol. 49, No. 3. ↩
Saket Navlakha and Ziv Bar-Joseph, Algorithms in nature: the convergence of systems biology and computational thinking; Molecular Systems Biology 7: 546 ↩

The need for Easter eggs

Thu, 17 May 2012 06:50:03 -0700

I have often wondered what drives programmers to insert Easter eggs into their creations. If you really dig deep, the need to insert Easter eggs offers an incisive look into the psychology of programmers.

At its core, an Easter egg is a programmer’s way to show off his artistry in an overt and obvious way.

The artifact that the programmer creates–a word processor, a spreadsheet, a search engine–is meant to be utilitarian. The code he crafts towards that end might possess a beauty seen only by his eyes, but to the rest of the world it is only a means towards an end, and that end is to serve a specific, well-defined function. The world judges his beautifully crafted code purely by its utility. To them, he is an anonymous constructor.

This is where the Easter egg comes in.

It breaks through the calculus of utility and presents something purely frivolous. It serves no purpose, other than to declare “I make cool things! I made this!”

It is a secret, revealed only to a select few. Out of the hordes of users a program might have, it calls out to the select few who have the curiosity and inclination to peel back the covers. “You want to see something cool? Here it is!”, it says to them.

But the fundamental urge an Easter egg satisfies is to declare to the world–there is art over here! You might not see it everyday, but if you pull this lever just so you will be treated to something awesome, and it will change the way you see this functional piece of software. You will get a glimpse into the artistry and the humanity of those who made it. This is their signature.

The 7 stages of debugging

Wed, 16 May 2012 05:45:21 -0700

(with my deepest apologies to the 7 stages of grief.)

Shock & Denial: But… but… how can this happen? I have unit-tests! And they even pass!! Besides, look at the code, it’s obvously correct. Really, this shouldn’t be happening. Can you even reproduce this?
Pain & Guilt: OMG. The other guy just gave me a reliable reproduction. My code sucks! I’m a worthless moron! How many other bugs are lurking in the code I shipped? I should just quit programming and go into sales.
Anger & Bargaining: To the bug reporters: are you sure you’re calling my code with the right parameters? Maybe there’s a bug in your code. I think my module works as per spec. Maybe you should change the way you call it. Frickin’ morons!
“Depression”, Reflection, Loneliness- Life sucks. I feel like puking everytime I see a chirpy colleague checking in code by the shovel-full. I don’t even feel like going into the office anymore.
The Upward Turn: Ohhhh… I see what might be wrong. Hack, hack. Oh! I see where the bug is!
Reconstruction & Working Through: Hack, hack. It’s fixed! It’s fixed! I’m a rockstar coder again! I’m getting back to shipping regular code again.
Acceptance & Hope: I know code will always have bugs, no matter what. Do your best. Test, test, test. And never feel invincible.

My setup

Sun, 13 May 2012 21:12:41 -0700

I want to describe my computing set up, both hardware and software. But I want to take a slightly different tack than most set up posts out there. Rather than go through the list of all the items I use, and gush about why they are the coolest in the world (there might still be some gushing), I want to go into why exactly I chose those items, and what trade-offs were involved. Hopefully, this approach will make this post useful even to those who disagree with my specific choices.

Goals

Before I even get into the details, I must describe the overall goals that I want and need my computing set up to achieve.

Simplicity

As time goes on, time becomes precious. I spent years in college and grad school maintaining my own Linux boxes and servers, tweaking their every detail, compiling my own custom kernel, installing all the latest packages, and happily staying up all night to do so. Believe me, it gets old. I guess it was a good learning experience, but that is certainly not something I want to include in my regular set up. I want it to be as hands-off as possible. If there are services that meet my needs and handle things for me, I want to use them. I want to minimize the number of moving parts, both in hardware and software. I want things to work out-of-the-box. I want to spend the minimum amount of time possible tweaking and maintaining my setup.

Functionality

As functionality goes, my needs are quite pedestrian. Of course, I need my set up to be programmer-friendly, seeing as that is my day job. I don’t do anything that might be considered heavy duty, like editing large videos. I do deal with the constant stream of images and videos that my setup ingests from digital cameras and phones, but that is a mainstream requirement. By and large, the vast majority of my digital activity centers around consuming, creating and massaging text, be it structured in the form of programs, or unstructured in the form of prose.

Preservation

After you go through a few machines, you realize that they are nothing but shells, and in the grander scheme of things, completely inconsequential. What does matter above everything else is your data. In your digital life, you don’t just do things, you make them, and save them. Everything else is moot if all this data cannot be safely and verifiably be backed up for the long term. Think about what your life expectancy is. Now think about something recent from your digital trail that really matters to you. It might be vacation pictures, a journal entry, a blog post, anything. Would you like to have that digital item available for your perusal when you are 80 years old? Now try to remember the oldest digital artifact that you can still retrieve, and more importantly, decode and view. Can you? How old is it? That should give you some idea of how hard and full of unknowns the problem of long-term preservation is.

Your body

I’ve talked about taking measures to proactively avoid RSI previously on this blog. Long story short, if a significant fraction of your working life is spent working with computers, and you do not yet have even the mildest RSI, you should consider yourself extremely lucky, but not immune. Act like you do have RSI, and change your set up right now to avoid it. It will happen sooner or later, and you might as well tackle it before it actually happens, so that you have a good chance of completely avoiding it.

After years of experimentation, I have found that the following works for me:

Absolutely no mice. As early as college, my right wrist was completely ruined by excessive mouse use. I moved to using the mouse only with my left hand, and also doing as much as possible with the keyboard, but I could feel the pain creeping into my left hand as well. I tried trackballs, vertical mice, ergonomic mice, everything you can think of. Eventually, I was saved by the magic trackpad.
Use a split keyboard. Using a split keyboard, the kind that has an inverted V shaped space down the middle, lets me type without bending my wrists at an unnatural angle. I use the GoldTouch keyboard.
Use dictation software. Of course, this does not work for programming and fine text surgery, but for tasks where I just need to transfer a large number of words from my brain into a computer, this works wonderfully and keeps my hands completely out of the loop. It still feels strange sometimes, because my entire life up to now the circuit that moves words from my head to the screen has been silent, and it takes some adjusting to speaking them out loud. But maybe that is just a ghost in my head. I use DragonDictate, the Mac version, and have been a happy user for almost 2 years.

This is what my keyboard/trackpad setup looks like:

Hardware

The piece of hardware that I physically interact with the vast majority of the time is the 13 inch MacBook air, the model from mid 2011. It has 4 GB of RAM, and a snappy 128 GB flash drive. Once you taste the sweet speed of a flash drive, you will never go back, and the smaller capacity compared to spinning rust drives will feel like an inconsequential sacrifice. It is by far the sweetest, most lickable piece of hardware I have ever had.

Before my current Mac phase, I had used Windows for several years. I honestly don’t see what the fuss is about–I’ve moved back and forth between the 2 worlds relatively easily. Maybe that’s because all the software that I regularly use runs equally well on both sides. The major advantage of the Mac side of things is that they tend not to suffer from the bit rot that makes a Windows machine completely unusable after about 2 years.

I’m 90% ready to make the jump to pure netbooks, with nothing but a browser and a net connection. About the only thing holding me back at this point is good dictation software.

For serious, heads down work, the MacBook is connected to a large 30 inch monitor, and an external keyboard and trackpad. I use the Apple Magic trackpad, and the Goldtouch split keyboard.

Most of the real work on the job happens on a humongous, powerful machine, that sits under my desk, fed only by a power cable and ethernet. This, of course, runs Linux. I just ssh and X11 into it from the laptop wherever I am and go about my work.

So those are the 2 major pieces of hardware I regularly use–the large machine that stays put, and the feathery laptop that goes around with me. It’s pretty simple. The laptop is the pretty front-end, and the desktop serves as the heavy backend.

I like this setup because I get the UI sweetness of MacOS X, while being able to use the dev setup on the Linux box.

Other miscellaneous pieces:

the Logitech H555 headset for dictation, and video conferencing, and occasionally listening to music.
Bose QC15 noise canceling headphones for the times when I really need to block out the outside world. They definitely go on flights with me. They are kind of expensive for headphones, but they really do make a huge difference. In a regular office environment, it’s as if–whooosh–the whole world just fell away. And on planes, the loud drone becomes a whimpering hiss. This is the one gadget that still amazes me every time I use it.
An external USB drive, for backups. I use the Western Digital Passport 1 TB.

Software

Editors

This is where the religious wars usually start. And rightfully so. If, like me, your digital life mostly revolves around text, then you need to have a religious fervor for your text editor. When I meet a geek who does not feel strongly about their choice of text editor (or worse, uses notepad or gedit), all my “fake geek” alarms go off. As far as software goes, this is the centerpiece of the entire set up.

You know what’s coming–Emacs and vi–those are the only serious contenders. I have some measure of objectivity here, because I have used both for a number of years, and feel comfortable with either. In the end, I fell towards the Emacs camp. What finally tipped me over was the customizability. People keep talking about the look and the key bindings and how many keystrokes it takes to do something. But all that is not important. What is important is whether you can make this editor your own. In the final analysis, Emacs is not really a text editor, but a platform on which to build your workflows. It just happens to be really good at text.

But–I’m not advocating a particular editor here. It really doesn’t matter which one you end up with. What does matter though is that you are a power user of it. It should feel like second nature to you. You should have no trouble making it do your bidding. It should make you feel powerful and light and frictionless. When people look over your shoulder at you going about your work with it, it should look like an incomprehensible buzz to them.

Also, don’t be a text editor mono maniac. I love Emacs, sure, but I confess to dropping down to other tools when they are better suited to the task. For example, for dictation I usually use TextEdit, because MacSpeech Dictate can’t really work with Emacs’ text control. When I’m writing Markdown, I often use Byword. Also, for tracking my tasks, I use Omnifocus. I know, that can be subsumed by Org-mode in Emacs. Org-mode can subsume everything. Doesn’t mean it should.

Web browsing

Actually, I lied about the text editor being the centerpiece of my setup. I ran a time tracking utility, and found that even on days and weeks when I’m mostly heads down programming, the application I spend the most time in is my browser. So it’s pretty important to get this one right, and to tweak it exactly the way you want it.

I have settled on using Chrome. The one indispensable plug-in I use is Gleebox, because it gives me keyboard control over common actions such as selecting and clicking links, and switching tabs.

Terminal/Shell

I use bash. I don’t use a terminal application. I just run all my shells in Emacs. That way, they are simply text buffers, like everything else. Once you do this, you will never understand why people use terminal programs where the only editable line is for the command you are entering.

Digital photographs

I like to meticulously name the directories in which I save digital photographs. Usually, I also give each individual picture a short, descriptive filename.

For browsing them, as well as making small edits, I use Picasa. It is overall a great application. But what really attracts me to it is that, unlike most other photo managing apps, Picasa works with your directory hierarchy, and never messes with it. It is a read only application, unless you explicitly modify something yourself.

This is a useful litmus test for almost every application I use. It should work with my directory layout, and provide a view over that. It should absolutely never create its own directory layout with jumbled names that are opaque to me, and have me depend on that one specific app to view my data.

Backups and preservation

I keep all my digital artifacts in a version controlled repository. There is a “master copy” that I commit new items to, and check out from. This holds everything, including binary blobs such as digital photographs. The repository is the Golden copy. It is backed up many different ways. Rsync helps a lot with that.

This means that what is on my laptop is just a cache, a checked out (small) subset of the entire repository.

I know what you’re thinking–what version control system do I use for this? I use CVS. There, I said it. Back when I started my repository in 1999, CVS was cool and the state of the art. And now, I have so much precious data in my repository that I’d rather not migrate it to something else. CVS also has the nice property that it’s repository (the “,v” files) are human readable.

Common flows

Reading

Most of my reading comes through my RSS subscriptions, and then there are the occasional longform pieces I stumble across. But here is my twist: I listen to almost all of my reading. I dump it out to text, and then use Mac OS X’s speech synthesizer to “speak” them out into sound files, which I then listen to on my iPod. Why? It started because I wanted something interesting to listen to during my commute. But then I realized what a better experience listening to something is when compared to reading it on the screen. It’s easier on the eyes, of course, but also free of all the distractions that a screen brings. It also leaves you free to do other tasks, like driving, that don’t divert from the cognition required to comprehend the piece.

Wish list

The number one thing on my wish list is a high-resolution large (13 inches or more) display. I want something that comes close to the retina resolution levels of the iPad. This point was driven home to me when a full resolution screenshot of the new iPad did not fit on my 30 inch monitor.

Next wish: more storage. You can never have enough storage. Right now, I’m compelled to only carry a small fraction of my repository on my laptop. It would be great to have the whole thing, preferably at flash-like speeds. But I would even settle for a hybrid approach where the OS and apps live on a fast flash disk, and my deep archives are on slower spinning rust disks.

"Humanities students should be more like computer-science students… My computer-science..."

Sat, 12 May 2012 11:00:45 -0700

“

Humanities students should be more like computer-science students…

My computer-science colleague guest-lectured in my class on approaches to literature and culture, showing my students all the different programs he uses to work with texts, to mine them for the interesting information … He told them that for every hundred experiments he tries with texts, perhaps one yields information worth following up. One.

Humanities students are not used to failure. They want to get it right the first time. When they are new to the game, they want to get good grades on what are essentially first drafts.

”

- Next Time, Fail Better, By Paula M. Krebs

Rocky.

Fri, 11 May 2012 09:36:11 -0700

Rocky.

Big science funding

Mon, 07 May 2012 10:01:23 -0700

In The Crisis of Big Science, Steven Weinberg describes how basic science is getting bigger and bigger, and now requires vast amounts of funding, often from public entities such as Congress that understand neither the technology nor the value of it.

It looks like the bottleneck for advancing science is now not so much the presence of brilliant brains, but the presence of an advocate with charm and clout and connections, who can coax funding out of reluctant public bodies, and then charm them over many years while the project continues.

But even when such a person is at the helm, funding is always a struggle. Weinberg is pessimistic about public funding of big science in general:

What really motivates elementary particle physicists is a sense of how the world is ordered—it is, they believe, a world governed by simple universal principles that we are capable of discovering. But not everyone feels the importance of this. During the debate over the SSC, I was on the Larry King radio show with a congressman who opposed it. He said that he wasn’t against spending on science, but that we had to set priorities. I explained that the SSC was going to help us learn the laws of nature, and I asked if that didn’t deserve a high priority. I remember every word of his answer. It was “No.”

What does motivate legislators is the immediate economic interests of their constituents. Big laboratories bring jobs and money into their neighborhood, so they attract the active support of legislators from that state, and apathy or hostility from many other members of Congress. Before the Texas site was chosen, a senator told me that at that time there were a hundred senators in favor of the SSC, but that once the site was chosen the number would drop to two. He wasn’t far wrong. We saw several members of Congress change their stand on the SSC after their states were eliminated as possible sites.

I was hoping he would also delve into some alternative models for funding big science. He proposes raising taxes, but that itself is another political battle. Perhaps the X Foundation and its quest to move space exploration forward with private funds is one model.

Bug finding and static analysis in the real world

Wed, 02 May 2012 22:04:22 -0700

If you want to get a good idea of how industry currently uses static analysis and bug-finding tools, you should read these 2 papers:

What both these papers have in common is that they document the experience of computer science academics applying their tools to real, and large, code bases. The first one talks about Bill Pugh’s sabbatical at Google, which he spent applying his FindBugs tool to the massive mountain of Java code there. The second describes Dawson Engler’s experience commercializing his group’s research in extensible static analysis for bug-finding.

If you are curious about the details, you should just read the whole papers, but these are some of the things that stood out to me:

FindBugs did find a large number of bugs, but only very few of them were serious or caused production problems. The authors attribute this to the numerous other “filters” that code has to go through at Google: code review, unit tests, integration tasks, canary deployments etc. The major value of regularly using such a tool would be to filter out some of these bugs earlier, as opposed to the usual selling pitch for static analysis tools, which is to avoid catastrophic bugs.
Both tools are unsound: they make their best effort to find genuine problems, but might also report false positives. This is a major departure from most academic research, which looks down on unsoundness.
In the case of Coverity, I found it very amusing to read how and why their tool had to be essentially dumbed down, because complex bug reports that were genuine but not understood by developers were simply dismissed as false positives. They also have a number of juicy quotes from clueless programmers.
There are two broad kinds of properties of code that tools can try to infer. Liveness properties say that the code is good: does what its supposed to, makes progress etc. Safety properties speak about the absence of bad things: no null pointer references, out-of-bound reads etc. Both these tools, as well as every other one I know of, completely give up on liveness and focus on safety. This makes sense, because, in general, liveness properties are much harder to prove, and also require programmers to provide a rigorous description of what the code is supposed to do.
These tools are context-insensitive: they examine a piece of code locally, without taking into consideration all the paths that could lead there. Context-sensitive analysis is too hard and explodes combinatorially for large codebases.

The cost of a bug

In this context, it is useful to ask: what is the cost of a bug? Sure, we would like to eliminate every bug if possible, but what are the tradeoffs?

Let’s take a serious class of bugs: those that crash your application. Not quite as serious as something that destroys data, but something in the middle, and that happens frequently.

The question then becomes: what is the cost of a crash? This is where the economics become interesting.

For client applications, the cost of a crash is pretty high. A crash makes your users unhappy and complain and leave, and justifiably so, because the application they were using just crashed on them! On top of that, you do not control the environment in which your application runs, and have to bend over backwards to get crash information to help you debug.

Things are very different for server-side applications served over the web. They are typically request-oriented, served by lots of instances. If one of them crashes, and the application stack is smart enough with retries, there is no user impact at all. What’s more, you control the environment the crash ocurred in, and have all the debugging and trace information you need. And you can push a fixed binary at your pleasure without anybody even noticing.

This means that the cost of a crash is much, much higher for client software than for server software.

The future of bug-finding

The major roadblock for no-holds-barred context-sensitive analysis of code is the exponential blowup in the space being analyzed. But this is only a hurdle if you are holding on to the single-machine model of building and analyzing code, i.e., that you have one machine (albeit a monster) that builds your code and tests it and analyzes it.

But what if you could throw a cluster of a few hundred machines at the problem, and have them running continuously? How much deeper and fine-grained could your analysis be?

Fractal.

Tue, 01 May 2012 17:53:50 -0700

Fractal.

"The long tail is famously good news for two classes of people; a few lucky aggregators, such as..."

Mon, 23 Apr 2012 19:31:44 -0700

“

The long tail is famously good news for two classes of people; a few lucky aggregators, such as Amazon and Netflix, and 6 billion consumers. Of those two, I think consumers earn the greater reward from the wealth hidden in infinite niches.

But the long tail is a decidedly mixed blessing for creators. Individual artists, producers, inventors and makers are overlooked in the equation. The long tail does not raise the sales of creators much, but it does add massive competition and endless downward pressure on prices. Unless artists become a large aggregator of other artist’s works, the long tail offers no path out of the quiet doldrums of minuscule sales.

”

- 1000 true fans, by Kevin Kelly.

"Death assumed many shapes in the novels of Ernest Hemingway… But death, as I think of my..."

Sun, 22 Apr 2012 18:13:00 -0700

“

Death assumed many shapes in the novels of Ernest Hemingway… But death, as I think of my friend and the foe that obsessed him, becomes a sniper in a tree.

It always kept him within range. The sniper made all the trips he took and accompanied him on every voyage. The tree was there where no trees grew. Concealed and still, the assassin waited with a hunter’s patience which Hemingway respected. Death was the enemy and he hated it, but he admired it for its hunter’s skill.

”

- The Ernest Hemingway I knew, by Jimmy Cannon, New York Post, 1961.

An obituary fitting the great writer.

Sadly, I could find no online copy. This is reproduced in the collection “Deadline Artists.”

Church numerals in Python

Sat, 21 Apr 2012 10:30:50 -0700

Just coz I feel like canoodling around with abstract representations of the natural numbers on a Saturday morning.

I love that lambda support in Python is great enough to be able to do this.

Church numerals are an encoding of the natural numbers in pure lambda calculus. It’s fascinating to see how you can build up everything from this bare simplicity.

The code is here, and reproduced below.

#! /usr/bin/python
#
# Church numerals in Python.
# See http://en.wikipedia.org/wiki/Church_encoding
#
# Vivek Haldar <vh@vivekhaldar.com>
#
# https://gist.github.com/2438498

zero = lambda f: lambda x: x

# Compute the successor of a Church numeral, n.
# Apply function one more time.
succ = (lambda n: lambda f: lambda x:
        f(n(f)(x)))

one = succ(zero)

# Add two Church numerals, n, m.
add = (lambda m: lambda n: lambda f: lambda x:
       n(f)(m(f)(x)))

# Multiply two Church numerals, n, m.
mult = (lambda m: lambda n: 
        lambda f: lambda x: n(m(f))(x))

# Exponentiation: n^m
exp = lambda m: lambda n: n(m)

# Convert a Church numeral into a concrete integer.
# n = 0, f = (add 1 to a number)
plus1 = lambda x: x + 1
church2int = lambda n: n(plus1)(0)

# Convert a concrete integer into a church numeral.
def int2church(i):
    if i == 0:
        return zero
    else:
        return succ(int2church(i - 1))

# Eval and print a string
def peval(s):
    print s, ' = ', eval(s)

peval('church2int(zero)')
peval('church2int(succ(zero))')
peval('church2int(one)')
peval('church2int(succ(one))')
peval('church2int(succ(succ(one)))')
peval('church2int(succ(succ(succ(one))))')
peval('church2int(add(one)(succ(one)))')
peval('church2int(add(succ(one))(succ(one)))')
peval('church2int(mult(succ(one))(succ(one)))')
peval('church2int(exp(succ(one))(succ(one)))')
peval('church2int(int2church(0))')
peval('church2int(int2church(1))')
peval('church2int(int2church(111))')

c232 = int2church(232)
c421 = int2church(421)
peval('church2int(mult(c232)(c421))')
print '232 * 421 = ', 232 * 421


c2 = int2church(2)
c10 = int2church(10)
peval('church2int(exp(c2)(c10))')
print '2 ** 10 = ', 2 ** 10

The carrier-messenger wars

Tue, 17 Apr 2012 08:29:19 -0700

James Gleick’s The Information has an interesting anecdote from the early history of telegraphy. Telegraphs were charged by the number of characters. So messengers had an incentive to shorten their messages as much as possible while still being able to communicate. Carriers had the opposite incentive—to make messages as long as possible, to maximize their revenue.

Heavy-duty messengers, such as railways, devised their own intricate codes with short forms for messages they commonly needed to communicate. These codes were then spread throughout the organization, to be used by both telegraph senders and receivers. And telegraph operators tried their best to outlaw the use of such codes.

That was an early form of the same carrier-messenger war we are currently seeing with issues such as net-neutrality. Carriers want to shape the content on their pipes to suit their business needs. And messengers want the carriers to not care about their messages and never look at what is running through the pipes.

The components of a university

Mon, 16 Apr 2012 07:00:17 -0700

In about five years, if not sooner, the entire education complex is going to face the same existential crisis that journalism and newspapers are going through right now. Their product will be unbundled from the unified package in which it is conventionally sold, and will be served a-la-carte and free over the net.

For journalism the package was the newspaper, a collection of articles. For colleges, the package is the degree, a collection of courses.

Of course, with Khan Academy and Udacity and OCW and many others, the courses are free. This, among others, is a major part of the argument of growing anti-college brigade who say that you’re better off not going to college, saving your money and not getting saddled with debt, and instead getting work experience for those four years, perhaps moonlighting with online courses.

Degrees

Colleges retort with: “we certify you! A degree is a stamp of some sort of minimum competence.”

But on the demand side, employers (at least in software) have almost completely soured on degrees. Their hiring decisions are based completely on how well you do on the interview, not on what degree you got from which college. And the interview focuses completely on the thing you’re being hired to do (e.g. programming). You would be amazed how many people with CS degrees simply cannot write programs.

Cost structure

The thing is: colleges are stuck in a death spiral of costs increasing, and increasing costs turning off applicants.

Why are costs high? Because it takes a lot of people, and they have salaries and health benefits, and retirement plans. But also because of the resortification of colleges. Larger fractions of funds are going towards building lavish facilities and buildings and recreation centers and dorms that are not dorms but fully furnished apartments. Those are now the baseline for attracting applicants.

Return to basics

So what will become of colleges?

I like to expand the question to encompass the thing that contains the college: the university. University and college have been synonymous for a long time, but a college is only one component of a university, which is a much broader institution.

It not only disseminates knowledge, but also creates and curates it. It’s the dissemination part that is being unbundled and dis-intermediated. That is the part that can be put online, for free.

The fact still remains though, that colleges survive on the money from undergraduate tuitions. And that is exactly the part that is beginning to go away.

Just like newspapers, the money from new sources of revenue will never come up to the level from the sources that are going away.

So what gives?

Remember that universities started out as essentially learning monasteries. You went there if you had a thirst for knowledge, but there wasn’t a pre-packaged “degree” to be had.

Likely, universities will go back to their smaller, simpler roots, concentrating more on unstructured knowledge creation.

I was reading this immensely enjoyable piece about Kanye and JayZ when I noticed an echo. Contrast...

Sun, 15 Apr 2012 18:01:34 -0700

I was reading this immensely enjoyable piece about Kanye and JayZ when I noticed an echo.

Contrast this snippet…

Those same iPhones illuminate the Garden like the cigarette lighters of yesteryear. There is the real Kanye West on the stage, with a giant close-up of his sweaty face projected above, and there are thousands of tiny Kanyes dancing and rapping in the palms of the audience: it’s the Watch the Phone tour, I realize, a weird, technologically mediated experience that makes the concert at once more intimate and more distant.

… with this one, taken from Stephenson’s “In the beginning was the command line”, written in 1999:

I was in Disney World recently, specifically the part of it called the Magic Kingdom, walking up Main Street USA. This is a perfect gingerbready Victorian small town that culminates in a Disney castle. It was very crowded; we shuffled rather than walked. Directly in front of me was a man with a camcorder. It was one of the new breed of camcorders where instead of peering through a viewfinder you gaze at a flat-panel color screen about the size of a playing card, which televises live coverage of whatever the camcorder is seeing. He was holding the appliance close to his face, so that it obstructed his view. Rather than go see a real small town for free, he had paid money to see a pretend one, and rather than see it with the naked eye he was watching it on television.

Reproducing papers

Tue, 10 Apr 2012 07:37:24 -0700

It turns out that a good fraction of results documented in peer-reviewed scientific papers cannot be reproduced.

This comes as a huge surprise to everyone except the scientists, grad students and post-docs who actually performed these experiments and wrote them up.

This is not failure of ethics. Scientists are not trying to publish fabricated results. It is a failure of process and documentation. If you teleported into the lab while the experiment was being done, you would actually see the same results that were written up.

But then going to another lab and trying to set it up just so, and get the exact same result? Good luck with that.

Ask any grad student and they’ll tell you just how delicate these setups are. They work for months just to get a stable setup, and then when it works, they try not to breathe too hard on it and pump it for as much data as possible and publish a paper. They aren’t going for reproducability, just producability.

Why?

Because the paper is the ultimate goal of all this. Grad students need them to graduate with a PhD. Professors need them for tenure and funding. The department needs them for prestige.

Like I’ve argued before, the paper as a unit of dessimination of modern scientific results is outmoded.

A paper doesn’t even contain all the information and data required to reproduce a result. Because if it did, it would be the size of a book. It usually has just the high-level points and a summary of the data.

Instead, what if the paper was replaced by a publicly-visible activity log? A long series of small steps, each one small enough to understand and debug and… reproduce.

If you see a stylus, they blew it. Not.

Mon, 09 Apr 2012 06:00:13 -0700

Steve Jobs is famous for saying “if you see a stylus, they blew it.” I think he is wrong because of the following:

Every time I sit down to think something through with pen and paper, I make so much more progress and have so much more clarity of thought, in a much shorter amount of time, compared to using any electronic device.

The downside, of course, is that paper is analog. It has life separate from your digital universe, which by now is most of your universe.

The solution isn’t to make screens and keyboards behave more like paper. The better way to go is to think of ways to make the act of moving a pen–like instrument across a flat surface something that can be digitized.

One way to do that would be to make the surface, the “paper”, digital. This is the approach that Windows tablet PCs took in the last decade. You could use a stylus to write on the screen itself. The handwriting recognition was smart enough that your notes could be searched just like text, perfectly integrating them into your digital world.

Unfortunately, Tablet PCs faded, largely because they treated the stylus as a poor 2nd class citizen, shoehorning it into the regular mouse and pointer and clicking based Windows UI, without trying to make an interface that felt more natural with a pen. Also, tablet PCs were basically just Windows laptops with capacitive screens–not the lightest and easiest things to carry around.

Another approach is to make the instrument, the pen, digital. This is what Livescribe has done. You use one of their pens to write on regular paper¹, and it captures what you wrote. Later, you can connect the pen to your computer, and get an electronic copy of everything you wrote or doodled.

Having an electronic pen and using it with analog paper has a bunch of advantages over having an electronic screen. When you’re actually writing, paper is a lot more convenient than the screen. Also, the pen is much smaller and easier to carry around. I’ve been using this for about a year, and I love it.

You do need paper that has special micro dots printed on it. You can either buy this from Livescribe, or simply print it yourself. ↩

"Otherwise, I’ll go to Vegas. If you’re not drinking or gambling, Las Vegas is a surprisingly good..."

Sat, 07 Apr 2012 10:02:43 -0700

“Otherwise, I’ll go to Vegas. If you’re not drinking or gambling, Las Vegas is a surprisingly good city for writing: when you get stir crazy, you can walk somewhere new. There are lots of restaurants, and no one looks at you strangely for being alone.”

- John August, on his writing routine.. Who woulda thunk — Vegas has a contemplative side.