If you were going to do it, how, or what would you do?

I’ve been playing with the above three options as I’ve trying to figure this out myself. I’ve done a few straight HotCocoa applications (SilverLining, Rife and Postie) and, while they worked out well, I found the need to do all the layout by hand tedious and boring. I really like Interface Builder for ease of UI creation.

Taking that, I tried the XCode/Interface Builder solution and went to the bundled MacRuby XCode templates. When programming Objective-C I really enjoy XCode, it makes things easy when doing purely native Mac applications. That said, XCode irks me when doing Ruby development. Maybe it’s muscle memory, not sure, but I like using TextMate to do my Ruby work.

The approach I’ve been using in my latest fiddlings (Touchstone) started with the XCode templates but I broke out, stole some of the rake tasks from HotCocoa, and switched to TextMate and the command line.

The biggest issue I’ve run into is the Interface Builder integration kinda sucks. It does work, but you have to reload the class files manually all the time. A bit frustrating.

On the flip side, I can organize my code however I want. The tendency for Objective-C programs to have all their code in the root directory drives me up the wall. Sure, XCode hides this, you can change it, but, by default, everything ends up in the root folder. Maddening.

With Touchstone, I’ve put all the application code, similar to Rails, under App/Controllers, App/Models, App/Helpers and App/Views. The same structure is copied into the .app file when it’s generated. Everything feels much cleaning. The .xib and .xcdatamodel files get compiled and moved as needed.

I know I could have used the XCode build stuff but having to launch XCode and getting the debugging output in an XCode window didn’t feel right for me. I wanted something a bit more contained.

Coming back to the original question, I think what I want to see, is something similar to Touchstone but with the convenience of HotCocoa. The HotCocoa mappings make a lot of things feel more Rubyish, feel more natural. Those bindings, combined with Interface Builder, I think, would make a kick-ass Cocoa programming environment.

Again, how would you do it?

In order to get into gear I’m going to start writing about each of the articles as I finish them. Hopefully, this will be incentive enough to get through them a bit quicker. My current plan is to read one or two articles a week. I may do more, I may do less (I do have a baby on the way in two months).

If you’ve got some good articles, not necessarily on programming, that you think more people should read, leave a comment or shoot me an email.

Todays articles from my pile are:

• Reflections on Trusting Trust
• Minimalism: Omit Needless Code

Ok, onwards and upwards.

The first article was Reflections on Trusting Trust by Ken Thompson. The idea is simple. How can we trust computer programs to not be malicious. In the article, well, the speech, Ken goes through the steps of injecting a Trojan Horse into a C compiler. The interesting thing being, the Trojan doesn’t exist in the source code of the compiler. An initial compiler is trained to insert the trojan when it compiles a specific sequence of code.

The moral is obvious. You can’t trust code that you did not totally create yourself.

One of the ideas behind Open Source code is that all bugs are shallow. Many people looking at the code makes bugs and trojans more easy to spot. The problem being, even with the source available, how many people just install the binaries from their distribution. The trojan may not exist in the source code while existing in the compiled version.

The second article was Minimalism: Omit Needless Code by Kevlin Henney. In Omit Needless Code, Kevlin makes the comparison between programming and writing. How, when writing, you want to omit needless words and make your text as trim as possible. Programming should be done in a similar fashion. You should strive to keep your code minimal. Find the shortest, maintainable route to getting your code to work.

This doesn’t mean obfuscate the code. It means using the features provided by your language to make your code as short as possible. This brevity will better highlight the overall meaning of the program.

In all fields of communication we must recognise the importance of idiom. Compression appeals to common idiom without resorting either to private language or to lowest common denominator baby talk — don’t write code for novices unless you are writing code for novices.

Both articles are wroth a read or two. Keep your code to a minimum and don’t trust anything you didn’t write yourself. Both good ideas, both hard to execute.