3 ms·

Consider toying around with Objective-C. I was pleasantly surprised. I had never used SmallTalk, and I had a good time with the idea of "message passing". This

• antonovka 17y ago
  I've been doing Objective-C for a long time, and I can barely stand the language. I use it because it's the most pragmatic choice for Mac (and now iPhone) development, but if I could I'd have dropped it in a heartbeat. It's incredibly verbose and almost the antithesis of "don't repeat yourself" -- as an arbitrary example, declaring an Objective-C 2.0 properties requires three different declarations: 1) Declare the instance variable in your header file: NSString * var; 2) Declare the property that matches the ivar in your header file: @property(nonatomic, retain) NSString * var; 3) Add the synthesize line to your implementation file: @synthesize var; I mean, seriously Apple? Seriously? You couldn't compress that down to a single @property declaration? That said, Apple has now added closures, which provides a highly effective tool for cutting through the usually highly repetitive, verbose code of Obj-C (except, perhaps, for property declarations :) and writing something a quite bit more palatable. My only remaining complaint is the lack of GC. It's not that I mind reference counting (it's not very hard to get it right), but that cyclic references cause leaks, and there's lots of places where it's easy and beneficial to create cyclic references -- especially with closures. If MonoTouch means I can write well-performing native applications for the iPhone in F#, god damn! I'm there.
  • Zev 17y ago
    If you think ObjC is verbose, take a look at this example of MonoTouch: http://img.skitch.com/20090914-cuu9mkrnjg864k88ywijur5ebk.jpg http://img.skitch.com/20090914-cuu9mkrnjg864k88ywijur5ebk.jp... The equivalent ObjC code is: IBOutlet UIWindow *window; IBOutlet UILabel *label; Also, your example isn't quite accurate. With the iPhone runtime, you only have to make the @property declaration in your interface and then @synthesize the variable in your implementation. #1 in your example isn't required. However, the Mac runtime doesn't support this — so by doing this, you're limited to only testing on a physical device (iPhone or iPod directly). Stick this class into a .m and compile it in Xcode targeting your iPhone and the Simulator respectively: @interface Foo : NSObject { // id bar; // Only required on Mac runtime or if you want to use the iPhone Simulator } @property (nonatomic, retain) id bar; @end @implementation Foo @synthesize bar; - (void) doSomethingWithBar { self.bar = @"baz"; NSLog (@"%@", self.bar); } @end @synthesize is useful to have because, well, what if you want @dynamic? As for the rest of the verbosity? To take a canonical example, string = [someString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]]; is much clearer to me then string.strip(); Or is there another example of its verbosity that you don't like? I don't find myself writing code that repeats itself very often. If I do, I'll refactor the code. And I like that it has a tendency to have explicit method names: I can actually read my code months later when I need to go fix a bug. But thats my personal preference. If you disagree, its not my place to tell you otherwise.
    • wvenable 17y ago
      string.strip() is a convenience, you can find a horribly verbose way to do it C# as well.
    • antonovka 17y ago
      The equivalent ObjC code is: ... MonoTouch appears to support Interface Builder as well. Also, your example isn't quite accurate. With the iPhone runtime, you only have to make the @property declaration in your interface and then @synthesize the variable in your implementation. However, the Mac runtime doesn't support this ... The reduction of three duplicate entries to two is admirable, but still ridiculous. Moreover, "However, the Mac runtime doesn't support this ..." is the key point here. You can't use them on the simulator or the Mac 32-bit runtime (which are the same). Additionally, prior to being corrected in 10.6, you couldn't access the synthesized ivars directly. @synthesize is useful to have because, well, what if you want @dynamic? Set an attribute on the @property declaration. Or is there another example of its verbosity that you don't like? I don't find myself writing code that repeats itself very often. If I do, I'll refactor the code out to its own method. Just like I would with any other language. I've never had trouble reading my Java, OCaml, or F# code years after I wrote it, but YMMV. In addition to the syntax, which stands on its own as a testament to monstrous verbosity, here are a few more off the top of my head: 1) Delegate/target pattern -- alerts, timers, etc. Your classes become a morass of delegate methods and hinky hijinks to pass what should be closure-captured state across disparate method calls. I don't want to make a mess of my classes by refactoring code to a distinct method if it doesn't belong in a distinct method. 2) Initializers. You wind up writing 3-6 different init methods, and then have to write 3-6 different class method short-cuts so you don't have to write '[[[Class alloc] initWithEverything: everything] autorelease]' everywhere. 3) Repeating myself. All the time. Why do I have to write header files? Java, C#, F#, OCaml, Python, Ruby -- none of them require me to duplicate my interface and implementation in two places. I understand that this is Objective-C, but in 2009, perhaps Apple should reconsider the C part?
    • mdeicaza 17y ago
      The code that you showed is automatically generated from the XIB file, the user never has to type it. When you discuss the @property compiler directive, you did not show the generated code, instead you opted to show the shortcut. With MonoTouch there is no need for any shortcuts; The entire backing store to any outlets are compiler generated.