I wrote a post some months back about the new trend to make computers appear more and more like appliances instead of exposing their programming guts. I am still trying to figure out if that is a good thing or not, but here is an interesting article I read with someone else’s perspective. It is about a chance encounter between a yuppie and one of the computer greats in a Seattle coffee shop:
However, the rot is even deeper; while we bemoan the inability of the lay public to understand the programming aspect of computers, as opposed to, say, the video displaying, music playing, web browsing aspect, even programmers are getting into familiar ruts of thinking.
My education about the arcane aspect of programming was at the hands of who I think is Chennai’s most innovative programmer, K S Sreeram, the inventor of the Clay programming language. K S and I meet up for the occasional beer and I always return enlightened.
Some time back, K S was on a trip about ‘live’ programming systems. In most computing systems, a team of programmers makes a program, which is sold as a package to a customer. On the customer’s computer, the program runs, processing input and producing output. However, there exist systems where the user has control not only over the input but also over the program itself, and has the power to change the way the program behaves through the program itself. This is called a live system.
The usual example that people give when asked to name one such system is the programmer’s editor, emacs. At the shallow end of the pool, a user can use it as a notepad replacement. However, with experience, a user can create so-called macros in emacs that are sort of mini programs which add functionality to emacs. These macros are written in a language called lisp, which can be executed by emacs. And the beauty of this program is that emacs itself is written in lisp, with all its accompanying data structures. So an emacs expert could use emacs to modify itself.
So computer programs could, at the extreme case, be like emacs. However, there are a number of other models possible. When I started learning digital circuits, for example, I learnt VHDL, which is (in some sense) a programming language. VHDL is meant to model the behavior of hardware. So it has one interesting feature: instead of the various statements of a program running one after another, they all run concurrently. This gives rise to some very interesting program structures, which can all be eventually converted into a circuit diagram through a process of synthesis. The circuit will, of course, duplicate the behavior of the program.
But there’s another very interesting program model which combines data and code, and that’s the spreadsheet. In Microsoft Excel, for example, you could enter formulas into different cells which produce outputs, which are themselves dependent on other cells. So the data and the ‘code’ that produces the data can be tightly coupled into intricate loops. And formulas are not limited just to what you type in a single line – you could write an entire program in a language like Visual Basic that would perform complex calculations before updating a cell. It is by exploiting the tight interdependence of data and code that people have, for example, written flight simulators in Excel!
I think these ideas are important because we are now no longer limited to ‘standard’ computers, which execute a series of instructions one after another. Multi-processor systems could execute several strands of instructions in parallel. But more interesting types of computers emerge; for example, Fredkin and Toffoli proposed a billiard ball computer that (at least theoretically) would execute programs without consuming any power. It is only by expanding our definition of what a computer program looks like, that we are able to take advantage of the computational power inherent in the universe around us.