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
Part of the reason for my reluctance to learn Cocoa to develop Mac applications is that it's radically different from what I'm used to. When I first started programming in 2003, I used AppleScript Studio for some small projects; this environment runs on top of Cocoa and uses Apple's developer tools, but it's really only suitable for basic applications. As a result, when I really began digging into programming and wanted to do more complicated things, I moved into languages like Tcl/Tk and Python. Significantly, I settled onto Tk as my GUI toolkit of choice, and I've spent the past three years or so developing expertise in that system.
What this means is that I've delved very deeply into a specific process of programming, with a particular mental model. I write GUI's all in code, by hand, using a text editor, and continually test them and refine them in code. Once the GUI is set up, then I define the processes that the GUI will run. If I need to lay out the GUI a certain way, I look at various extension packages to see what's available. In this fashion, I've developed a library of code, and a repertoire of techniques, that allow me to be productive. Adding a second programming language, such as Python, to my toolbox was relatively simple because I could map the particularities of Python onto what I already knew of Tk.
Cocoa doesn't fit into any of the mental models I already use. Even though I have a basic understanding of the standard Cocoa language, Objective-C, the Cocoa approach to programming is radically different from what I know. First of all, the development environment is more complicated. You use one program to create your interface (Interface Builder), and another to write code and manage your project (Xcode). This makes it harder to manage things, because you have to click so many buttons and navigate through so many windows.
Next, you don't have as much control over what you are doing. The GUI is laid out visually, not in code; you drag and drop things like buttons, text fields, and other widgets onto a window, spending a lot of time fiddling and getting them lined up just so. Then you name the methods/functions that these widgets will call, and draw connections between the various widgets (button A triggers a specific action, and then displays the data in text field B). After all that's done, then you write your code. Writing code is simple enough, but because the widgets can only be displayed in another application, it's easy to lose track of all the connections and actions and outlets.
I've followed this Cocoa tutorial and have also spent some time with an introduction to Objective-C programming. I understand the component parts--Objective-C isn't too different from other languages I've programmed in, and it's pretty cool laying out a nice-looking UI just by dragging stuff around--but so far the larger whole, the coherent mental model of what's going on, how each part fits, has eluded me.
I understand that some programmers find all the tools that Apple provides for Cocoa programming to be powerful and helpful, and not an impediment. But wading through all these windows and programs and connections, I feel a bit lost. And being lost isn't conducive to writing programs that you can sell.