Consider these two C++ classes:

class SimpleFrobulotron
{
  public:
 
	SimpleFrobulotron(const string &name);
	string getName();
 
  private:
	string m_Name;
};  
 
class FastFrobulotron
{
  public:
 
	FastFrobulotron(const string &name);
	void getName(string * outName);
 
  private:
    string m_Name;
 
};

The main difference between the two designs is simple: The SimpleFrobulotron is easier to understand and use, but somewhat slower than the FastFrobulotron. For example:

void printFrobulotronNames()
{
	SimpleFrobulotron simple("tweedle dee");
	FastFrobulotron fast("tweedle dum");
 
	//display the simple frobulotron's name
	cout << simple.getName() << endl;
 
	//display the fast frobulotron's name
	string fastName;
	fast.getName(&fastName);
	cout << fastName << endl;
 
}

Is FastFrobulotron really that much faster than SimpleFrobulotron? A test on my machine shows that FastFrobulotron runs in 27% of the time that SimpleFrobulotron runs in. So it is clear that there’s a trade off here: Simplicity versus Speed. Code that squeezes every last bit of performance out of the machine is harder to understand. What side of this trade off do you favor, and why?

In this case, I think the answer is obvious: returning a string from a function is much slower than assigning it through a pointer. This is a simple enough optimization that most good programmers should be able to look at the code and understand what’s going on. Therefore it’s best to make use of it. Things can get much more complicated than this simple example, though.

Writing code that does what it’s supposed to do is something most programmers can do (unless you give them the halting problem.) Writing code that’s easy to understand, however, is not. Neither is writing code that is as efficient as possible. The problem is that these two goals (simplicity and efficiency) seem to be at odds with each other. How do you balance between the two?

I was wrong. Once it got to the right edge of the bar, the cursor just wrapped around and appeared at the left edge again. I understand the point of having some sort of animated graphic to indicate that work is being done, but why a progress bar? A progress bar should only be used if it shows the extent to which the work has been completed. To indicate … progress. A better design would be to have some kind of spinning wheels or gears, to make it clear that you have no idea how long you’re going to be waiting until you can listen to “I Wanna Sex You Up” by Color Me Badd. If, you know, you wanted to listen to that song.

To understand why, we must first delve into the languages of computers. When humans program computers, they usually write in “high level languages”, which look like a series of mathematical formulas and instructions.  Here is an example of a simple function to compute the nth Fibonacci Number, written in a high level language called C:

//computes the nth fibonacci number
unsigned int fibonacci(unsigned int n)
{
	unsigned int term1 = 1;
	unsigned int term2 = 1;
        unsigned int result = term2;
 
	unsigned int i = 1;
	while (i < n)
	{
		result = term1 + term2;
		term1 = term2;
		term2 = result;
		i = i + 1;
	}
 
	return result;
}

The Computer cannot understand this program as it is written. It must be translated into instructions that make sense to the computer. This  translation process is called compiling. The compiled program will look different depending upon what computer it is compiled on, but all computers basically operate the same way: they can read from and write to memory locations, and they can add, multiply, divide, and subtract numbers.  Here is an English-language translation of what the compiled Fibonacci function might look like. Provided to make things more clear is a mapping of variable names to their memory locations:

# set the value in location 1 to 1
# set the value in location 2 to 1
# set the value in location 3 to the value stored in location 1
# set the value in location 4 to the 1
# if the value in location 4 is not less than the value in location 0, go to instruction 11
# set the value in location 3 to the result of the value in 1 plus the value in 2
# set the value in location 1 to the value in location 2
# set the value in location 2 to the value in location 3
# set the value in location 4 to the value in location 4 plus the value 1
# jump to instruction 5
# return the value in location 3

Each of the above instructions would be represented with a single word, which on a top-of-the-line modern computer is 64 bits of information. The human genetic code is also a sequence of simple instructions, interpreted not by a central processing unit, but by intracellular organisms.  Instead of dealing with changing values in memory locations, the genetic code’s instructions are for amino acids used to build proteins.  There are approximately 6 billion instructions in the human genome, making it roughly 10 million times as complex as our simple Fibonacci function.

Notice that the machine language program is  no where near as easy to understand as the C program. If I gave you a machine language program with 100 million lines of code, you’d have a heck of a time trying to figure out how it worked.  Poking around and changing single instructions, then determining what happens when you change those instructions probably wouldn’t be a good start. Unfortunately, as I understand things, that is exactly how biologists are proceeding.  They are stepping through the genetic code piece by piece,  using experiments to try and figure out what different sequences of instructions do.

There is, I think, a better approach. The key to understanding this approach is a simple fact about computer programming: It’s easier (and more fun) to write your own program than it is to read someone else’s program and figure out what it’s doing. Instead of trying to reverse engineer existing DNA code, which evolved over millions of years and is therefore probably extremely convoluted and hard to follow, we’d be better off trying to ‘write’ our own organisms.  Biologists could start by writing DNA ‘programs’ to code simple proteins.  After getting good at this, they could invent a ‘high level language’  for DNA programming (AKA GeneticC) which could be used to speed up the development progress. The next step would be to write a single cellular organism, and then more complicated organisms.

Interestingly enough, this process of building our own organisms could provide a lot of insight into the question of whether there is some being who designed us.  Once we have a better understanding of genetic programming,  we could look at the quality of the code that builds human beings. If it’s clean, neat, and straightforward,  that would be strong evidence of a creator at work. If it’s messy, garbled, hacked together, redundant and nonsensical in parts, we could conclude that the code evolved over time.  Either that, or god is a perl scripter.

htons


No Cheating via Google! Click for the answer …

The answer is “Host To Network Short.” It’s a function from the Berkeley sockets API. It’s needed because different computers use different methods for storing information, and htons converts a number from whatever format that machine uses, to the ‘network short’ format.

This is a perfect example of terrible software engineering.  Maybe I’m totally out of line to criticize something created by people who are far more educated than I am, but how can writing cryptically short function names that give the reader absolutely no clue what they do be considered good engineering? What excuse could you possibly have? That you want to save time in typing? A reasonable name for the function, like, say, HostToNetworkShort, would take 5 seconds to type, as opposed to htons, which takes 1.  Any programmer who spends the majority of his time typing should probably be fired for posting too much on slashdot.

The script is below, for your edification. It only works on windows, but it could easily be modified to run on a UNIX based system. It is presented without any warranty, express or implied, not even that of suitability for a specific purpose.

import os
import sys
 
def findFileGenerator(rootDirectory, acceptanceFunction):
  for aCurrentDirectoryItem in [ os.path.join(rootDirectory, x) for x in os.listdir(rootDirectory) ]:
    if os.path.isdir(aCurrentDirectoryItem):
		if acceptanceFunction(aCurrentDirectoryItem):
			yield aCurrentDirectoryItem
		for aSubdirectoryItem in findFileGenerator(aCurrentDirectoryItem, acceptanceFunction):
			yield aSubdirectoryItem
 
def acceptSVNChildren(theFileOrDir):
	return theFileOrDir.find('.svn') != -1
 
def removeSVN(rootdir):
	"""recursively removes the SVN bindings from the directory specified in the argument"""
 
	for dude in findFileGenerator(rootdir,acceptSVNChildren):
		if os.path.isdir(dude):
			print "rmdir /S /Q", '"'+dude+'"'
 
def main():
	"""Removes the SVN bindings from the commandline dir specified in the argument.
	If no argument is specified, the root directory is used."""
 
	dirToClean = os.getcwd()
	if(len(sys.argv) == 2):
		dirToClean = os.path.join(os.getcwd(),sys.argv[1])
	elif (len(sys.argv) > 2):
		print "Usage: remove_svn.py <dirToClean>"
 
	removeSVN(dirToClean)
 
if __name__ == "__main__" : main()