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.
No comments:
Post a Comment