Apple has a page devoted to their iPhone Developer Program, but you still need to sign up before they will tell you any details. Some are complaining about the restrictions Apple has put on native programs written for the iPhone but they don’t sound that limiting to me. I imagine that the more severe ones, such as restrictions on private API’s and open source software, will be eased over time.

I had read before that Apple intended to ban emulators on the iPhone, but I can’t find any official confirmation of that. Apparently there’s no blanket ban, at least according to this: StyleTap officially bringing Palm emulator to the iPhone / iPod touch.

Of course, programming for the iPhone using Xcode isn’t really that different than using the Windows CE, Pocket PC, or Smartphone support built-in to Visual Studio. I’m sure that anyone who has ever used Visual Studio has created at least one “Hello world” program for the emulated smartphone. But has the Pocket PC ever excited as many people as the iPhone?

At this point, my interest in iPhone development remains just curiosity. A few problems remain:

• I don’t own a Macintosh (necessary to run Xcode and the iPhone emulator)
• I don’t own an iPhone (necessary to test programs)
• If I did own an iPhone, I would have travel around 100 miles to use it (according to the coverage maps)

The first two problems could be remedied without too much trouble, but the third would be a bit more difficult.

There seem to be two caveats:

• The SDK and tools run only on the Mac.
• You can test your programs on the emulator for free, but you need an Apple Developer program membership (which costs $99) if you want to run them on a real iPhone or sell them at the Apple iPhone Marketplace.

Both seem to be pretty reasonable restrictions. It sounds as if it is pretty easy to experiment with iPhone development, which I’m sure is exactly what Apple wants.

Protocol Buffers are a flexible method for handling serialized data, generally for use with a database. Google has been using them internally for some time, and has now made it available for all to use. You can examine the documentation and download the package from Google.

The documentation is very detailed and is actually pretty interesting reading. It also shows that Protocol Buffers were created to fit a specific need within Google. I think that they are bound to appeal to anyone who has struggled with fitting XML into this particular type of application.

The philosophy behind literate programming is that computer programs should be written for human readability, much like a work of literature. I’m using CWEB, a literate programming tool written by Donald Knuth and Silvio Levy. I create a source file that contains both documentation (written in TeX) and source code (written in C). The CWEB terminology is descriptive: you “tangle” to create C source files and “weave” to create TeX output.

I initially found it quite difficult to wrap my mind around the literate programming approach to writing. It took a while to find my “voice” and not just mimic ordinary commenting. I think I am finally getting the hang of it and I am beginning to see the benefits.

One of the things I like best about literate programming is that it lets me structure my program the way I want. I always like to block out program logic in broad terms and then fill in the details later. Using CWEB, I can actually write my programs in exactly that way. There is a great freedom in being able to place my code where I think it belongs rather than where the C compiler requires it to be.

I also like the mental discipline imposed by literate programming. That is more difficult to describe, but it is different than the ordinary planning that always goes into programming. Everyone knows that it is fairly easy to write code that looks correct but is fundamentally flawed. I find that design errors jump out at me when I try to describe my program in a narrative form.

One example illustrates my point. I was having a lot of trouble with one section of code even though it seemed pretty simple. I couldn’t figure out why I was having such problems with it until I spotted a design error. It was a fundamental mistake and I must have recognized that it was there on some level because I kept stumbling when I tried to describe the design. Remember that if I had written that code using non-literate techniques, the code would have looked correct. I only would have found the error later on. It took some extra time now, but literate programming saved me debugging time later on.

(I should point out that I always liked FORTRAN. Many of the failings people ascribe to FORTRAN-77 are related more to bad programming than the language itself. Also, Fortran-90 later addressed most of the actual weaknesses of FORTRAN-77.)

Jeff Atwood at Coding Horror wrote an interesting post called XML: The Angle Bracket Tax concerning his dislike for the way XML is being used (or abused) by many programmers. He says:

I realize that we have to use something to represent reasonably human readable data stored in a text file, but XML sometimes feels an awful lot like using an enormous sledgehammer to drive common household nails.

I have found that when many people successfully solve a problem once, then they feel they must standardize on this solution and apply it to all future problems they encounter. Sometimes this makes sense, but much of the time it doesn’t. Each new problem should receive an appropriate solution, not the one that worked for different problems in the past.

I think that this describes the current problems with XML. If XML worked for you once, that doesn’t necessarily mean that you have to use it for everything you do in the future. Many times, programmers struggle against the complexities of XML when they would have had an easier time with a simpler format. They are only using a tiny subset of the features of XML, so why not just simplify their tasks by using a simpler format?

This isn’t to say that XML is useless. On the contrary, I think that it is incredibly important and will remain a dominant file format for years to come. I think that future-proofing your data is one of the best arguments for XML and one that is rarely mentioned. It is unlikely that XML will be forgotten anytime soon, which is something you can’t say for many other formats. Parsers will be available for all platforms for years to come. This is very important for data that must be archived and accessed in the future. But is future-proofing really that important for a simple initialization file?

Quite some time ago, I needed to examine a program that had been written in C++. This was not long after object-orientated programming had become a hot topic, and the author of that program had apparently decided to embrace everything object-oriented. In that code everything, and I mean everything, was an object. Not just things you would expect, such as lists, queues, or even strings (this predated the standard library). But absolutely everything, including simple operators, small portions of algorithms, even variables and constants! The sad part is, rather than promoting code reuse, the style actually meant that I doubt any part could have been used again.

I could have been convinced by that one bad example that C++ and all object-oriented languages were worthless and just a fad. But that program was not a good example of how to use C++, and did not reflect on the merits of C++ in the slightest way. The strange thing is that I don’t believe the author was a bad programmer, just overzealous in embracing C++  (It might also have been intended to make a point, but that’s a whole other story).

No matter the programming tool or feature, there will always be a way to abuse it and you can be certain that someone will. You can write truly awful code in any language, and I can guarantee you that someone already has. But bad examples shouldn’t reflect on a tool or language, no matter how bad they are.

I’ve seen many Flash-based and Java-based games (and even written a few), but I’ve never seen a JavaScript-only action game. But a quick search shows that there are many other examples. For instance, Breakout4K is a 4K Breakout clone. Another example is 3D TOMB 2, a 4K DOOM-like game. None of these games are going to challenge the Xbox or the PlayStation, but I am always impressed by what is possible using limited resources.

I have been doing some programming recently with Microsoft’s .NET framework. For those who aren’t familiar with the .NET Framework, it is a complete departure from the Microsoft’s former WIN32 programming model. Similar to Java in some ways, it is composed of two parts: the Base Class Library (BCL) and the Common Language Runtime (CLR). The Base Class Library is similar in concept to the C runtime library, only much larger in scope. The Common Language Runtime is an implementation of the Common Language Infrastructure (CLI) standard. It handles tasks such as memory management and exception handling and also runs bytecode called the Common Intermediate Language (CIL), formerly known as MSIL (Microsoft Intermediate Language). The bytecode is compiled using a just-in time (JIT) compiler. (This strikes me as far too many acronyms.) This is an simplified view of the whole architecture; there are many quirks and nuances involved, but this is the general idea.

The Common Library Runtime is actually a virtual machine, and the Common Intermediate Language is a type of assembly language for this virtual machine. The just-in-time compilation means that your code is compiled on the fly into your processor’s machine language. This means that anyone could (in theory) target a different processor just by writing a new just-in-time compiler to run your existing code. Currently, code does work without change on both 32-bit and 64-bit versions of Windows.

There are many programming languages available for the .NET Framework. Visual Studio comes with C#, Visual Basic .NET, and C++/CLI (which is a version of C++). You can download F# (a variant of ML) for free from Microsoft and F# will be an official Visual Studio language in the future. A quick search shows that other languages available for the .NET framework include Pascal, COBOL, APL, Lisp, Forth, Ada, Python, Prolog, Smalltalk, Haskell, Eiffel, and Ruby, among others. I’m sure that all of the versions of those languages are not equally usable, but they are available.

Because all of the .NET languages use the same Base Class Library, you can combine different programming languages in ways that weren’t possible before (at least in Windows). You can even use a decompiling utillity such as Reflector to convert compiled programs from one language to another. Perhaps we are moving to a future when a programmer can pick the best programming language for a problem, instead of being limited to one or two choices.