Reenigne blog

Usually the best way to make a major change to a piece of code is to try to break it down into small changes and to keep the code working the same after each such small change. The idea being that if you make too many changes and break the code too badly, you might never get it working again. Without working code it can be difficult to figure out what the next step should be.

But sometimes, incremental changes just don't work. In particular, if you're making major architectural changes, trying to construct something that is 90% original architecture and 10% new architecture is going to involve just as much extra work to try to make the incompatible pieces fit. In these cases, sometimes the only thing you can do is take the whole thing to pieces and put it back together again the way you want it.

I went through quite a few design revisions to get to the pipeline architecture I described yesterday. Some ideas I tried out and then abandoned:

• Giving the filters the responsibility of keeping the data they needed.
• Filters telling other filters how many samples they should consume or produce.
• A FilterGraph object which held all the buffers and which had methods to make and break connections.
• All the reader and writer methods being on the buffers.
• Lookahead reader methods for filters.
• Filters encapsulating other filters that they communicate with.
• Having separate consume() and produce() methods.
• Having the Reader and Writer functionality as part of the Consumer and Producer classes (this introduced a surprisingly significant overhead)
• A Connection object to encapsulate the buffer.

It's rather difficult to tell what's going to work well and what isn't until you actually write some code. And then it takes some trial and error work to hit upon the right pattern. Assumptions must be called into question. Prejudices must be discarded. Darlings must be killed. But you know when you've got it right because the rest then practically writes itself.

The usual distinction between high-level and low-level languages is that high-level languages provide more abstractions. Assembly language is clearly a low-level language, and provides few very abstractions over the raw binary format consumed by the processor. Javascript is very high-level because it abstracts away almost all the details about the particular machine and operating system that it runs on, making it much easier to write actual end-user applications in (but impossible to write, for example, device drivers in).

One particular place where the distinction is particularly obvious is how different languages handle memory. There seem to be three basic strategies for handling memory:

1. Implicit or explicit memory management (assembly language, C, C++) - calls to malloc() and free() (or equivalent) are inserted into the code by the programmer or by the compiler.
2. Garbage collection with explicit state (C#, Java, Python, millions more) - no malloc() or free() are possible - all memory is "owned" by the garbage collector. Memory management is abstracted away.
3. Referential transparency (Haskell) - there is no state, the concept of memory itself is abstracted away.

The boundaries can blur a little - you can plug a garbage collector into C++ for example, and high-level languages often provide "unsafe" functionality that allows one to escape to lower-level features.

I was interested to read that the cores of Intel's new Larrabee graphics architecture are based on the old P54C design, originally used in the second generation of Pentium chips (dating back to before even MMX made its first appearance). The core has since been updated with the latest instructions (including x86-64) but is missing performance features such as out-of-order execution. This vindicates what I wrote in devolving the CPU - that individual cores will get simpler and slower again as they get more numerous.

When writing a program, I generally don't just write it in any old way that might work, I set myself some constraints. Generally these constraints are particular programming principles that I have found make my life easier in the long run, such as choosing appropriate names. Sometimes I'll try to maximize speed or minimize memory usage. For Argulator I tried to minimize the number of SQL queries I made to satisfy any given request (which led to some convolutions to do appropriate data caching on the PHP side.) I also tried to make the page sent by the server as close as possible to the page that actually gets rendered (i.e. make Javascript not needed to display the page, just to interact with it). I mostly succeeded, at the expense of having some code duplication between the server side and the client side (though the argument creation UI is partially created by Javascript).

Sometimes I'll try to eschew certain operations, such as eliminating the square root operation in the algorithm to determine if a point is in the Mandelbrot cardioid. Often I'll try to eliminate subtraction and division and write algorithms in terms of addition and multiplication instead. This might seem to be a strange thing to do but the resulting algorithms are often more concise and it's easier to tell that they're correct. This can also eliminate division by zero errors.

The text editor interface I talked about yesterday is so good I find myself wanting to use for things other than text editing. In particular, I'd love to be able to use it as my command line interface. Most command line shells are annoying because you can't use the keyboard to move the cursor up into a program's output to copy it - you generally have to resort to the mouse. I think it would be far better to treat the entire command-line session as a document. One way to do this would be to have a text editor with a special key combination (say Ctrl+Enter) which takes the contents of the current line, executes it as a command, and pastes the resulting output into the document immediately below, followed by a prompt, followed by the cursor.

One useful aspect of command line interfaces is tab completion - it would be nice if there were a way to make this continue to work in the editor interface. Perhaps tab could be interpreted to mean "tab completion" if the line above the cursor was a prompt (maybe prompt lines are "special" in some way, though that counteracts the principle that there should be no "hidden" information). If prompt lines are special, then maybe pressing Enter on the line below would suffice for running commands, instead of a special key combination for this.

A variation on this idea would be to allow editing of multiple files in a single buffer. Suppose you're using the editor interface and "cat" (Unix) or "type" (Windows) the contents of a file, causing it to be inserted into the buffer. I think it would be tremendously useful if that file was then "live" and could be edited by just moving the cursor up into its contents, changing things, and then hitting some other key (perhaps Alt+S?) to save it. Again this goes against the "no hidden information" principle, though. Perhaps one of the ASCII control codes that aren't usually found in text files could be repurposed to have special meaning to the editor, to signify a line that is a prompt or contains the path to an embedded file.