CoreData and RAD tools under OS X

I've never been a RAD tool enthusiast. However, I recognize they have their utility. Especially when the "rapid" part comes from a well done library and not from drag and drop mumbo jumbo. Besides, I'm a big fan of drag and drop: I just don't think software should be built with drag and drop. About the "rapid" as in library part, I love Django. I was quite fond of Rails as well, but since Django reached the metaphorical age of consent I just dropped the whole Ruby thing.

Back to Cocoa... I'm mostly an OS X user and I'm quite into OS X development as well. Not that I often write desktop software, but when I do, it's often Cocoa stuff (possibly with Python bindings). And when I received Hillegass book (Cocoa(R) Programming for Mac(R) OS X (3rd Edition) ) I knew it was time to tackle Core Data.

Core Data is a nice technology. There is plenty of examples when you create not-completely-trivial applications only with drag and drop. Which looks good (though I never understood what kind of programming language/framework benchmark is writing a hello world program as most software is not constituted of hello world applications -- and you don't get paid to write hello worlds). Well... the drag and drop thing works as expected: even if you don't know about programming more than what I know about Votic literature, you may surprise your suspenders wearing hacker friends (at least until they ask you how the damn thing works).

Unfortunately enough, everything that is not that trivial (which accounts for most software projects, indeed) needs a bit more attention. The first thing you learn is that you must know the underlying technologies. This seems reasonable enough (after all if you want to work in the IT world you must learn a lot of things -- votic excluded). And when we talk about "learning", we are talking about long term investments. You learn Core Data, KV-coding and Cocoa Bindings and you use them for good. Or at least until Apple screws the whole thing up.

Even though when things become complicated you need to write real code, there is a lot of drag and drop/checkbox checking development done in Interface Builder. Of course you could write that code programmatically, but then you don't qualify for the RAD buzzword thing. The point is that bugs in code are usually signaled with tests, code lints or lawyer dispatches about that blown up nuclear plant you wrote the software for. If you don't write a function, the compiler or the interpreter will complain. If you forget to write part of a function, the software will crash (or the tests will fail, if you are a savvy programmer).

Unfortunately, it is dramatically easy to forget to check checkbox (how many checkboxes would a woodchuck check?) or to fill some textbox in Interface Builder, especially if you have a rather complicated UI with lots of elements (and this accounts for most software you want to sell). Error messages are as cryptic as the Delphi oracle (with no known reference to a nice RAD tool and to the most popular commercial DBMS in the world). Cryptic means that most of the time you have no way to understand which UI element wasn't properly connected and generated the error message, you have to browse the bindings of all the widgets. You probably have to set some debugging option (if so I missed the paragraph where this was explained).

Key Value Validation transcends my understanding. As far as I can see it's dramatically easy to do things wrong and put the system in an inconsistent state. Probably I just did not get the rationale behind it. But... Django seems far easier. Sigh.

About learning Cocoa

I first learnt about ObjectiveC and Open/GNUStep when I was basically a Linux user. That was quite a lot of time ago. I was a WindowMaker fan, and that was the way I learnt about GNUStep. However, I did not learn ObjectiveC nor GNUStep programming. In fact there was plenty of "wonderful" languages out there and I felt no need for another one. The few GUI applications I did were made with GTK1 and C (yes, GTK 2 did not exist yet and wx was not really widespread; the first time I installed Audacity on Slackware 8.1 I had to google for them) or Qt with C++.I was quite skeptical with interpreted languages too: I knew a bit of Lisp (more for academic reasons than for "real programming" -- that is to say I would not be able to write a piece of useful software; well, this isn't changed, anyway) and quite a lot of Perl (still I did not use to do what I considered "serious work": a few cgi and some system scripting). But I'm going off topic.

One day one of my friends showed me the Powerbook G4 and MacOS X (it was Jaguar, for those who care). After some time I bought my first Mac with MacOS X. Before being a Linux user I was a big fan of MacOS Classic (and the first machine I installed GNU/Linux on was an iMac), so I was really happy with the "new deal" of Apple. Still I planned to "install GNU/Linux as soon as possible". In fact this never happened (but one of this days when I have time and airport support is stable enough...).The first thing I did was to learn Objective C. I took a look at Carbon, but I wasn't amazed. I read Apple's guides about the language. They were clear and well done. Still to code GUI applications I needed a more detailed book (I'm kind of a perfectionist) since the Tutorial, although well done, is designed for absolute beginners. Anyway the Apple guide for the language ObjectiveC is here.

I still have no idea why I chose to learn it. In fact I was a "cross-platform gui". I still thought I would use both systems, so having my own applications on both of them was probably quite desirable. Moreover the QT MacOS port was young (it was released a couple of months after I bought the Mac, IIRC).In the same period I was learning Python too, and almost everything else (system tools, web sites, cross platform gui applications with awful Tk) was made with it. I found some similarities between the two languages (in fact I think they were more similarities between Python and Smalltalk, and only indirectly between Python and ObjectiveC). Still one thing was different. Python is a very high level language, but does not force you in anyway into some kind of framework.

In fact you can perfectly "translate" command line from C using the same POSIX APIs or, for example, "convert" a Qt + C++ program. The language Objective C in fact has the same properties. In fact I wrote a few command line utilities and found that the Foundation kit was a well designed environment that abstracted some POSIX interfaces. I quite liked it. And quite liked ObjectiveC.

The only thing I truly missed were namespaces (or analogue things). I spend a couple of days understanding the memory model and that was everything. I bought two books, "Cocoa in a Nutshell" (today I would not buy this) and "Cocoa Programming" by Anguish Buck and Yacktman. They were both good books. I do not use the Nutshell because Apple documentation is more recent today, not because it's not well done."Cocoa Programming" is a "big" book. There are lots of infos. Some of them are advanced topics (for example there are Chapters about optimizations -- you know, optimization hinders evolutions, but we want to run our software on something more portable than a mainframe).

The book focuses on how Cocoa was thought with Design Patterns (expecially those from the famous book), even if they change their name (and Anguish/Buck/Yacktman show which Cocoa pattern corresponds to a GOF pattern). I was already acquainted with DP, I read the "Design Patterns: EORSD" some time ago (and recently I bought the book and I'm reading it again). In fact Cocoa developing needs understanding of design patterns, but you can have a less theoretical approach to Cocoa.

I recently read Hillegass's "Cocoa Programming for MacOS X" and that is what I mean. It's more like a tutorial, but not as elementar as Apple one. It shows you some "real life" small applications that use key tecnologies. It shows Cocoa structure, main "patterns" (for example how to deal with a NSTableView -- and introduces the concept of delegation).While "Cocoa Programming" shows how much Cocoa can be powerful, Hillegass shows how much Cocoa is easy. There are many things that are not explained in the latter (even if it covers some topics I didn't find in the other book).

You may need (you probably need) a book like Anguish/Buck/Yacktman's "Cocoa Programming", but I strongly advise to start with "Cocoa Programming for MacOS X". It's not recent, but it's well done and complete. You can build a whole lot of applications reading it, and for example explains the Document Based Applications in a very simple yet complete way (for example in "Cocoa Programming" the authors implement classes that act quite like the NSDocument and friends to show you in details how it works, still I was not really able to understand how easy it is programming Doc-based apps with Cocoa; in fact I thought it was hard, since many explanation about how the "true" class works are embedded in the explanation of how to rewrite a subset of it.Another reason for reading "Cocoa Programming for MacOS X" is its length. Much shorter than the other one, you can read it in less than a week, and dive into programming with more skills. Some useful subjects in "Cocoa Programming" are not at the beginning and you must already know you have to skip chapters and go and read them.In fact I find the two books complement each other well. I've got a third book (well a fourth), but I'm not gonna speak about it this time.

1. "Cocoa Programming" - Anguish/Buck/Yacktman
2. "Cocoa Programming" for MacOS X" - Hillegass