Skip to main content

Learning to Code: Starting Point for Objective-C

As readers of this blog know, the more I delve into programming, the more convinced I am that it should be a standard school subject — not merely an elective sought after by a few enthusiastic students. Programming skills reinforce the value of breaking problems into simpler pieces. In the end, a computer must reduce problems to simple tasks. Good writers, historians, chemists… we all break problems into little, digestible, solvable tasks.

And just as a musician must practice scales, the basics of programming need to be practiced and sometimes revived. It is no secret that my C skills have atrophied, so I am starting from the beginning. My journey towards Cocoa Goodness begins with two books:


In the early pages of Clair's text, he mentions that you need a good understanding of C to work effectively in Objective-C. Turning to my bookcase, I found several C books, but settled on the Absolute Beginner's Guide because it is operating system and compiler agnostic. It is an old and simple book (1994 being the ancient past in computer time), yet it is precisely what I needed for a quick review.

I'm strange, I realize. Not many people like to go back and read basic grammar books, yet I always enjoy recalling the little bits about English I forget. Any time I teach a writing or literature class, I review the materials and feel like I'm discovering something new. Programming has that same feel.

As Clair reminds readers of the basic syntax and common functions in C, I turn to the Perry text and read the short chapters on the same topics. Clair assumes that his readers know C, C++, Java, and similar languages. He also stresses that Objective-C is closer to C than C++ — so you need to unlearn (C++) and relearn (basic C) as you move into Objective-C.

Many, many years ago, when I was an undergraduate, USC had several NeXT computers. The language used to program the NeXT was Objective-C and the operating system was NeXTSTEP (with the silly all-caps but "e" format). As I start writing about Obj-C, you'll be able to recognize this legacy. I graduated from USC in 1990, so a fair number of years (22+) have elapsed since I last used Objective-C. Even as a Mac owner and user, I clung to other tools for as long as possible. Now, I must go back to the future.

Programmers might wonder why I'm not turning to that fabled classic, The C Programming Language by Brian Kernighan and language creator Dennis Ritchie. Or maybe an O'Reilly book, such as C in a Nutshell. The Absolute Beginner's Guide is a better text for me. It's much better than a "Dummies" or "Idiots" text, sparing readers the attempts at humor. Perry keeps chapters focused on one topic. At the end of the book, there is a code listing for a complete blackjack game. I like that the code heads towards a real project, something I can play with and modify.

Going back and forth between a dense technical text (Clair) and a more project-based text (Perry) helps me consider issues from two perspectives. Beginners don't think about pointers and memory, which is an essential aspect of coding. The better you understand computing theory, I believe the better your code. You don't need to understand the finest details, but enough to appreciate what is happening "under the hood" when you create an application.

Young writers can get overwhelmed when we focus too much on grammar and mechanics. Beginning programmers can also be overwhelmed by too much deep theory. Focusing on ideas first, then developing an appreciation for how a language works seems perfectly logical to me. We don't teach children grammar before they speak! We teach them about nouns and verbs, periods and commas, long after a child is speaking.

As a programmer, I like to see how problems are solved, and then I study the code. After I study the code, I enjoy going that extra level or two deeper — which is why I love learning about the magic performed by compilers.

A good enough comparison: When I learned BASIC, I didn't need to understand what the interpreter or compiler was doing. As I learned C, it helped to learn how memory worked. Later on, I learned how to optimize C code, based on what the compiler would do and how a particular CPU worked. Yet, learning BASIC was an ideal introduction to programming: I learned to express simple ideas (BASIC) before learning how to write properly structured programs (Pascal, Fortran, and C). Yes, I know you can do a lot with modern BASIC derivatives — but early BASIC, was called BASIC for a reason. BASIC allowed mere mortals to program.

What have I learned as I revisit C and begin to learn Objective-C? I'm going to bore readers with a bit of C in my next post, since that's what I've been revisiting. I'll also discuss how learning something like C helps me as a creative and academic writer. Yes, coding can be poetic. It is certainly inspiring.

Comments

  1. I've never been a fan of K&R. It's a nice historical curiosity, but not as the first introduction to a new C programmer.

    ReplyDelete
  2. I can really identify with your description of coding as poetic: there is a beauty to a well-written piece of code that I find very pleasurable.

    ReplyDelete

Post a Comment

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.