Skip to main content

Learning to Code: The Month (and More) of Cocoa Begins

This week I am beginning a month (and more) of intense "Cocoa" immersion. Cocoa, for those outside the OS X/iOS development realm of Apple, is the framework created by Apple's wizards to make programming for Apple hardware a (tiny) bit easier.

Since I want to develop applications for Macs and iOS devices, I need to learn the Cocoa frameworks. It's going to be a long journey, and a fun one. On this blog, I'll be posting about programming as an educational experience. I'll also continue to explore programming as a form of writing.

I'm surely not going to do the topic justice, but allow me an attempt to explain how computer languages and frameworks are similar to other languages. When we write in any language, we start with a core of basic words and grammar. Computer languages are more concrete and simplistic than living languages, but you might compare them to the languages children speak.

I am not going to go über-geek in this post and explain the translation of a computer language to executable code. Let's just accept that the simplistic brain (CPU and other computer components) does like the human brain and converts words to thoughts and actions. (I will in a later post, which I have already outlined.) I'm going to keep this discussion at the higher level (relatively speaking) of the programming languages most mortal coders use. The art of assembly language coding is limited to a sect of high priests of hardware in the modern coding universe.

Most programmers developing for Apple hardware use the Objective-C programming language. As with human languages, Obj-C represents an evolution from other languages. Scholars can trace the family tree of English, and we can trace the family tree of Obj-C. Most programming texts for OS X/iOS include a short history of Obj-C, explaining that the language was developed as an extension of the "C" programming language, borrowing ideas from Smalltalk and other object-oriented languages.

See:


Computer languages evolve, even after they are initially designed. Objective-C, already C with ideas from Smalltalk, continues to pick up words and syntax elements from other languages. American English adds words from other languages, and new words are created. Objective-C has done the same. And, sometimes, a language loses a word or the syntax changes over time. The original Obj-C was extended when Apple introduced OS X, based on the NeXTSTEP (or NextStep) operating system. Obj-C was updated again significantly in 2006, but overall the language core has remained relatively stable (unlike the cores of some other languages).

By itself, Objective-C is okay but not very useful for creating complex OS X/iOS application. Apple developers need to use the Cocoa frameworks to craft applications. Because Cocoa is so fundamental to Apple programming, many refer to all coding for Macs and iOS devices as "Cocoa programming" — an accurate description, since calling Cocoa code is essential to the process. The Cocoa frameworks are numerous and seemingly ever-expanding as Apple adds to their libraries.

For example, Apple's Cocoa frameworks include the "Cocoa Touch" framework for touch-screen development. Instead of creating a new way to deal with touch screen interactions, a programmer uses the Cocoa Touch framework. Again, when I write about computer languages later this month, I will explain how frameworks (for better and worse) extend programming languages. For now, you can read Apple's pitch to developers:


This first post is short; you can expect me to explore the preceding topics in greater detail throughout the month. Writing about what I learn and observe will help me — and my readers.

Comments

Popular posts from this blog

MarsEdit and Blogging

MarsEdit (Photo credit: Wikipedia ) Mailing posts to blogs, a practice I adopted in 2005, allows a blogger like me to store copies of draft posts within email. If Blogger , WordPress, or the blogging platform of the moment crashes or for some other reason eats my posts, at least I have the original drafts of most entries. I find having such a nicely organized archive convenient — much easier than remembering to archive posts from Blogger or WordPress to my computer. With this post, I am testing MarsEdit from Red Sweater Software based on recent reviews, including an overview on 9to5Mac . Composing posts an email offers a fast way to prepare draft blogs, but the email does not always work well if you want to include basic formatting, images, and links to online resources. Submitting to Blogger via Apple Mail often produced complex HTML with unnecessary font and paragraph formatting styles. Problems with rich text led me to convert blog entries to plaintext in Apple Mail

Learning to Program

Late last night I installed the update to Apple's OS X programming tool suite, Xcode 4. This summer, in my "free" time I intend to work my way through my old copy of Teach Yourself C and the several Objective-C books I own. While I do play with various languages and tools, from AppleScript to PHP, I've never managed to master Objective-C — which is something I want to do. As I've written several times, knowing simple coding techniques is a practical skill and one that helps learn problem solving strategies. Even my use of AppleScript and Visual Basic for Applications (VBA) on a regular basis helps remind me to tackle problems in distinct steps, with clear objectives from step to step. There are many free programming tools that students should be encouraged to try. On OS X, the first two tools I suggest to non-technical students are Automator and AppleScript. These tools allow you to automate tasks on OS X, similar to the batch files of DOS or the macros of Wor

Learning to Code: Comments Count

I like comments in computer programming source code. I've never been the programmer to claim, "My code doesn't need comments." Maybe it is because I've always worked on so many projects that I need comments  to remind me what I was thinking when I entered the source code into the text editor. Most programmers end up in a similar situation. They look at a function and wonder, "Why did I do it this way?" Tangent : I also like comments in my "human" writing projects. One of the sad consequences of moving to digital media is that we might lose all the little marginalia authors and editors leave on manuscript drafts. That thought, the desire to preserve my notes, is worthy of its own blog post — so watch for a post on writing software and notes. Here are my rules for comments: Source code files should begin with identifying comments and an update log. Functions, subroutines, and blocks of code should have at least one descriptive comment.