Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
After several false starts, I'm working on adding a third major programming language to my toolkit, complementing Tcl and Python: C. C is the lingua franca of computer languages, a fast, compact, compiled language that is the basis of operating systems (huge portions of Mac OS X, Linux/Unix, and Windows are written in C), other computer languages (Python and Tcl, both dynamic, interpreted languages, are themselves written in C, while such powerful languages as Objective-C and C++ are additions to C), and such workhorse programs as the Apache web server are written in C.
The problem is, learning C is hard--it's much harder, less forgiving than the scripting languages I'm used to working with. It requires the programmer to do such things as manage memory; it forces you to be very strict in how you set up your code. It's also slower to work with. Instead of saving my code to a script file and then running my code in a dynamic language interpreter, I have to compile my code each time; an interpreter runs the code interactively and immediately, which makes it easy and fast to change your code, but compiled code must be re-compiled each time you make a change.
Given these hurdles, I can't say I'm having a lot of fun learning C--even though I'm still doing very basic stuff, and I'm using a textbook by a well-known Mac developer, Marc Liyanage (see http://www.entropy.ch/blog/2004/10/22/Our_New_Book_About_C_Programming_is_Out.html). Working in C reminds me of why I gravitated to scripting languages in the first place.
So why learn C at all?
The chief reason is that scripting languages, for all their power and ease-of-use, have limitations. Their capabilities are baked into the language by C, and if you want to do more than the languages allow, you need to drop down into C. For instance, Tk (the GUI toolkit that I use, with both Tcl and Python) is very flexible and configurable, and I can tweak many parts of it to get my programs looking very native on the Mac. (See here for some discussion of this and a screenshot.)
However, some things can't be done from within the toolkit or language itself: the toolkit itself needs to be changed. A good example is the way Tk displays notebook tabs on OS X. Here's how my programs display notebook tabs:
Does that look a little out of place? Yes, it does--Tk uses a fairly old Apple C function (specifically, the Carbon Appearance Manager API) to display tabs. This particular method has been out of date since Apple shipped Panther (OS X 10.3) in fall 2003. This style of tab still exists in OS X, since removing it might cause programs to break, but the more modern style is displayed below:
Changing the way Tk displays notebook tabs will require some modifications to Tk's source code in C--specifically, to call the newer Carbon HITheme API rather than the Appearance Manager. I'll work up some new code to do this, and once it works, I'll submit it to the core Tk developers as a patch. That way, all Tk programs on OS X will benefit from the update.
That's just one example. There are others, but I can only tackle one project at a time.
Learning C is helpful if I ever decide to delve more deeply into Apple's Cocoa frameworks, because the core language of Cocoa--Objective-C--is based on C. However, it's more likely that I will concentrate on using what I learn from C to enhance Tk.
I haven't yet tested my programs on Leopard, but I don't anticipate any major difficulties. I plan to delay upgrading to Leopard for a brief period so I can do one more release of each program--PacketStream, Phynchronicity, and PortAuthority--to smooth out the transition to the new OS. After that point, my efforts will focus on supporting Leopard, and working to ensure that my programs offer the best user experience on that version of the OS. An older, Tiger-compatible version will continue to be available for download for users who do not upgrade to Leopard, but no new work will go into enhancing them.