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
Jason Slack has posted a website that will document his efforts to port Tk to run on top of Cocoa, instead of Carbon.
To keep abreast of the project, visit http://softwareforeveryone.info, and click on "Projects/Tcl-Tk Work" or "blog."
Thanks, Jason! Your hard work on this project is much-appreciated.
Michiel van Meeteren did a research project for graduate school on the independent Mac development community, called "Indie Fever." The paper can be downloaded here.
It's an interesting overview of the community, and it has a lot of good points, but it has one serious flaw: it assumes that the Mac development community is comprised strictly of Cocoa developers. It even goes so far as to assert that independent Carbon development, for all intents and purposes, is dead.
Not true. I can think of several independent Mac developers, including Skytag Software, LemkeSoft, Black Cat Systems, and Fetch Softworks, who should be counted as vital members of the independent Mac development community. They develop with Carbon, or a Carbon wrapper such as RealBasic.
Why weren't these developers discussed at all in this paper? Why does the paper's author automatically equate Mac development with Cocoa development?
Many Cocoa developers applaud the increasing emphasis that Apple is placing on Cocoa as the main development framework for OS X. They also believe that Apple is making it easier than ever to learn Cocoa, by adding such features as "garbage collection" to the language (which reduces the amount of effort developers have to spend managing memory), and by directly supporting scripting bridges to Cocoa (specifically, PyObjC for Python developers and RubyCocoa for Ruby developers). The consensus about Apple's lowering the barrier to learning Cocoa is even shared by curmudgeonly Cocoa developers, who grumble that Apple is watering down standards, making it too easy to write Cocoa software, which will lead to lots of bad software.
I'm not sure I agree that Apple is lowering the barrier to entry on Mac development.
All the features that Apple is adding to Cocoa will make it somewhat easier to pick up developing with the Cocoa frameworks. However, the increasing emphasis on Cocoa means that it's now pretty much the only show in town for Mac development. And if you don't write in Cocoa, the migration path to Cocoa is not easy. Anyone doing development based on the Carbon frameworks--either directly or with a higher-level toolkit--has a higher, rather than lower, barrier to entry.
But Objective-C, at its heart, is a small suite of extensions to C that add object-oriented capabilities to the language. What this means is that, despite the very different approaches to programming between Objective-C and C, you really need to know C.
Problem is, C is hard if you are coming to the language from a higher-level "scripting" language, as I am.
In general, programming languages work like math. If you remember algebra, you'd have an equation and some variables--x and y--and you've have to find the value of x or y. Programming languages use variables in a similar fashion, to perform manipulations on data.
The difference between a scripting language such as Tcl and C is how those variables, and the operations on them, are established. A scripting language is also called an "interpreted" language--the code in the language is executed by a separate program called an "interpreter." In the case of Tcl, the interpreter is a small program called tclsh. In an interpreted language, variables can be created and manipulated very easily, and the interpreter takes care of all the details of executing the code--making sure there's enough memory for your data, for instance, and making sure that numbers and words are handled appropriately (you can't perform math operations on something that isn't a number!).
In C, and in other compiled languages such as Objective-C, you have to handle a lot of details yourself. When setting up a variable, you have to make sure it's identified as a number (such as an "int," for integer) or word ("char," short for "character"). You have to set up memory for the various tasks your program is going to perform. And then you have to compile your code into an executable program. There's no interpreter involved. (Most interpreted langauges, in fact, are themselves written in a lower-level compiled language such as C--Tcl is written in C.)
So I've been working through an introduction to C programming, co-written by a noted Mac developer, and trying to map what I already know about programming into C. The translation process is an imperfect one, because scripting languages have allowed me to work at a fairly high level of abstraction. I can write code that solves my problems and not worry too much about how my code is actually executed by the computer; the interpreter takes care of that. Picking up a second scripting language (Python) wasn't terribly difficult after I gained proficiency in one (Tcl), because they operate at the same level of abstraction.
Learning C requires a lower level of abstraction. Programming in C requires a lot more interaction with how the computer actually executes your code: allocating memory, for instance. I have to take more steps to allocate and release memory, to make sure all my variables are correctly defined, and so on. It's also slower to develop in C: the code I write in C is actually compiled into machine language, the binary executable that is actually run by the computer's CPU. That explicit compilation step is unnecessary in scripting languages.
Now that I've spent a couple of weeks working through various exercises, it's time to start something real--that's the only way I truly learn something. The current project I'm working on is porting the code I use for generating and validating serial numbers (currently written in a scripting langauge) to C. It's proving harder than I expected, but thanks to some assistance on the comp.lang.c newsgroup, I'm making progress.
Once I get a bit further along, I will be ready to tackle Cocoa more in-depth, because I'll have more of a foundation on the compiled-language level of abstraction. After that, who knows? If I want to do any enhancements to Tcl or Tk, that will have to be done in C.
(Note: I didn't read this article until after I started learning C, but I certainly recognize the attitude contained therein: "Real programmers" program in, or at least know, C. Or, to directly quote the article: "Yep, we C programmers are elitist and proud of it.")