You are not logged in.
These options, sometimes mutually exclusive, are:
a) the choice of the compiler
c) code optimization level
Leave them as the defaults. And if you're writing Objective-C from scratch (no ASObjC), I think ARC is the logical choice .
I liked Aaron Hillegass's book, but it does assume some knowledge of C.
Shane Stanley wrote:
I liked Aaron Hillegass's book, but it does assume some knowledge of C.
I'm with Shane about this. I have the second edition and third edition and both of them are good. It feels good to have a book from a trainer and developer who helped building the Cocoa API. So you want to develop for Lion only I suggest your buying the fourth edition. The fourth edition is for Lion with ARC support but also Xcode 4 screen shots (this last thing I can't confirm but it's told me).
Thank you very much for these hints, if people like you find these books good and useful, they certainly are! I have downloaded the first (now free) edition of Hillegass's book, but I found and bought the third edition. It has a non-negligible advantage: it's a french edition. So I won't pretend "I don't understand this or this because it's in english"
Shane Stanley wrote:
I liked Aaron Hillegass's book, but it does assume some knowledge of C
Thank you for the warning, Shane! Well, my reluctance about C won't probably last longer than the one I had for Pascal when I left FORTRAN… So many programmers cannot be wrong! It's more a personal problem than a language problem. Ok, back to library…
For those of you who've switched from ASOC and Objective-C, is such a "translation" of a script possible, just to begin a new language with a working application as a basis? Is it desirable, or should I reconsider the whole model
Speaking as someone who has actually done that very switch you are thinking about -- less than a year ago, I might bring some perspective and tips. I've been away from this forum for a while so I didn't see your post until now. You are obviously already going, and you have already received lots of responses, so you might not need my response. But for new readers, I hope that it brings at least some new views.
I have a long experience in AppleScript, and I also had an AppleScript Studio app that needed to be completely renewed, so ASOC seemed a natural step, but only after Shane had his ebook for sale. (And somewhat ironically, that is how I first learned Objective-C.)
I have used a number of programming languages (mainly high-level dynamic stuff like Lisp, Prolog, Perl, Matlab, but also odd things like APL, and a bit cheating in Java), but managed to avoid C. After having coded ASOC for several months, Objective-C seemed more and more viable, since, after all, you have to read the Cocoa documentation anyway.
My first reasons for going ObjC was that I feared that a couple of new classes would need more speed than ASOC could deliver, so I wrote that one in ObjC, and was satisfied, so I started to convert other stuff to ObjC. As in your case, this app does not speak to other apps (apart from Finder, System Events etc) so it doesn't really need AppleScript -- I just started with AppleScript because it felt the fastest way to get something done.
Translating an ASOC method to ObjC is reasonably straightforward, but despite the similarity, translating a whole class may not be as easy and fast as one might expect. One big class (my biggest) took me a whole week to translate and to reasonably debug! (And more to polish.)
When I did the transition, I timed many constructs so as to get a feeling of the kind of differences in speed. What is very annoying in AppleScript is that its speed depends strongly on the size of your strings and lists, to the degree that at some point, the script will simply choke and return nothing! That is my historical experience. In ASOC, all those coercions might be fast for a 3-character string, but if it is 500 kB, it is extremely slow (or stalls), and for lists, the situation is even worse.
Like you, I dislike C, but as others have said, most ObjC people only use the "good" parts of C. If your read an old book on C, almost half of the book appears to deal with how to increment pointers and with furious transitions back and forth with * and &. But if you look at, for instance, stackoverflow, people don't fiddle with such things very much any more, unless they really have to.
As for learning, good books have already been mentioned. Apple has a good document "The Objective-C Programming Language" available in the docs and as a pdf on the net. The big drawback with all of Apple's documentation on ObjC is that they take for granted that you already know C, so you have to find some other source to learn C (but my view is that one should skip all things that look ugly, and only learn the basic things about C).
Knowing that ObjC is a strict superset to C is very important I think, because it helped me very much to understand why ObjC looks the way it does, and why you have to add lots of "@" allover.
Now that most of my stuff is ObjC, I can look back and conclude what I think is the practical consequences when comparing AppleScriptObjC and "pure" ObjC:
Perhaps in contrast to DJ's experience, I find that it is much easier to read my ObjC code than my AppleScript code when I revisit it after a few months! That may be a bit surprising, but ObjC tells me much more explicitly what kind (class) the variables and parameters are, whereas with AppleScript that is pretty hopeless unless you name all your things with a suffix indicating its type/class. Also, the ultra-long names in ObjC encourages a style that makes things readable, even to the extent that one can skim through code to get the hang of what it does approximately.
Finally, the way you explicitly distinguish between properties and regular instance variables is actually a good help as soon as you begin to have many of them. And the color coding in Xcode makes it MUCH easier than in AppleScript to distinguish between local variables and instance variables, and to distinguish between your methods and those of the inherited Class.
Because of this clarity, my program comments in ObjC are not so much about what the line does, but rather WHY I need to do it! Or pointing out that the result might actually be nil. WHAT the line does is mostly apparent. This is the opposite of Perl, where you have to comment every line to say what it is supposed to do! (And it is still obscure.)
All languages can be misused. The important thing, however, is what style the language encourages. In that respect, I like ObjC.
ObjC code is easier than AppleScript to restructure into smaller units by using Categories, and the compiler helps enormously whenever I want to rename variables/properties by "refactor" them.
Concerning object oriented: Although AppleScript is OO, it does not really encourage an OO way of writing code. You mentioned that your AS code more resembles old-style procedural coding, and I have certainly had a fair amount of that myself. ObjC, on the other hand, definitely encourages a style that is much more in line with OO and message passing, and it encourages such thinking (which also makes the error messages easier to understand).
Although I have always loved AppleScript's dynamic interpretive nature (just hit run and you see the results), I really dislike the fact that it is so sloppy! There is no definition, and no dictionary, that clearly and unambiguously nails down what is valid and what is not, and exactly what the requirements are on parameters etc. With every new OS version, thousands of AS (apps) stop working because Apple has changed how an empty list is treated, or an empty string, or some undocumented difference between string, text, unicode text, or… zillion of other things. You never know, the best you can do is just "cut and try" -- if it runs, good, but it might be broken in the next OS. With ObjC/Cocoa, I have only come across one real bug I think, and the documentation is MUCH more strict than anything AppleScript. With AppleScript, I always stumble into various bugs, either AppleScript itelf, or Standard Additions, or some app's dictionary (such as Finder). With ObjC, they do at least list what is deprecated, so the chance of getting things to survive the next OS seems higher.
Learning ObjC is a much steeper learning curve than ASOC (if you already know AppleScript) so the start can be troublesome. For small or simple apps, I don't think the trouble of learning ObjC is worth the hassle if you already know AppleScript, but for larger apps, and for apps you intend to maintain for many years, ObjC wins, not only for speed, but I think it is much easier to maintain ObjC code than AppleScript (unless very small).
Xcode 3 could not even point out my missing semicolons, but Xcode 4 usually does, so the syntactic pedantry of ObjC (relative to AS) is not so much of an issue because the compiler helps you.
I now do use also some "pure" C code, but I do NOT increment pointers! And no preincrement of variables!
If I were to recommend a prospective ASOC-to-ObjC converter some small tips, it would be to get hold of some good book on the combination of C and ObjC. The other obstacle that was annoying was all those cases where I need to have a non-object (such as BOOL, NSInteger, SEL, …) in a dictionary or an array. There are methods to wrap them into objects (mostly NSNumber and NSValue), but Apple has not provided any chapter of "wrapping for dummies", so you have to find out yourself the hard way or get some good teaching source.
All of this may appear to be pushing for ObjC rather than ASOC, so perhaps I should end by saying that ASOC is much quicker to get started with to get things done. And for those who need to talk to other apps, it is terrific! And if you do not foresee the app to grow into many thousands of lines of code, or no need for blistering speed with large amounts of data, there might be no need for pure ObjC -- the ASOC bridge may be good enough for many cases.
Last edited by heb (2012-05-11 02:32:22 pm)