4 ms·

Regarding Objective-C & Copland 2010

48 points by ryannielsen 15y ago

fleitz 15y ago
Regarding concurrency: [[^ (Foo*) (Foo* bar) { return bar; } copy] autorelease] is a pretty ugly way of writing a lambda. It's like arguing that java can pass functions via anonymous classes. Yes, technically you can but it's pretty ugly. Another underlying problem is that the only language that can call Obj-C libraries is Obj-C. .NET and the JVM solved this problem long ago, I know that Python/Perl/Ruby also have this problem outside of the JVM/CLR. As far as GC, Obj-C effectively doesn't have it as most Obj-C outside of Apple is written for iOS which doesn't support GC. You could create a point system and call Obj-C a modern language but working with it feels anything but. Apple doesn't need any serious rewrite, they need to make MacRuby work on the iPhone. That's it.
- ryanpetrich 15y ago
  Any language can call Objective-C via the runtime. In pure C: void *foo = objc_msgSend(objc_getClass("NSObject"), sel_registerName("alloc"))
- panic 15y ago
  In every Objective-C API I've seen that uses blocks, the framework takes care of the "[[... copy] autorelease]" bit. In practice, the code looks something like (to borrow your block with foos and bars): [array transformFoos:^(Foo*) (Foo* bar) { return bar; }]; I'm not sure there is a more succinct way to write a lambda with typed arguments and a typed return value.
- schrototo 15y ago
  Objective-C can sometimes be pretty verbose, yes, but that's a very contrived block example, especially since it doesn't really relate to concurrency in any way. A more real-world example employing blocks with GCD would be: dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0); dispatch_async(queue, ^{ // do some time-consuming work dispatch_async(dispatch_get_main_queue() ^{ // do stuff on the main thread, like updating UI }); }); That's actually pure C. Typical block usage with Cocoa would be something like: [myArray enumerateObjectsWithOptions:NSEnumerationConcurrent usingBlock:^(id obj, NSUInteger idx, BOOL *stop) { // do something with obj concurrently }];
  - headhuntermdk 15y ago
    you forgot a BOOYAH!! at the end of that
  - fleitz 15y ago
    Can you really do the latter in Obj-C? As I understood it you needed to copy and autorelease the block to move it from stack allocation to heap allocation.
    - schrototo 15y ago
      That's right, but if the receiver needs to have the block on the heap for whatever reason, it's his responsibility to take care of that. Blocks are really no different from any other method argument.
- phatbyte 15y ago
  I'm with you on MacRuby, the thing is (anyone correct me if I'm wrong), MacRuby is being maintained by Apple with just one developer, at the last time I checked, so MR still feels like a bastard son, which means, no xcode documentation, or auto-suggest, code browsing like we have with OjbC. But I see it as a good alternative for apple development in a near future, let's just hope Apple sees it as well.
- Leynos 15y ago
  >Another underlying problem is that the only language that can call Obj-C libraries is Obj-C. In practice this is the case, but the Etoile guys have written AppKit applications in Io and Smalltalk, and they have an ObjC -> JavaScript compiler running thanks to LLVM. So given time, I think this statement will come to be eroded away.
- deleted 15y ago
  [deleted]
- stcredzero 15y ago
  Apple doesn't need any serious rewrite, they need to make MacRuby work on the iPhone. That's it. Lua is already on the iPhone, and will probably give you an order of magnitude performance advantage over Ruby.
jballanc 15y ago
In 2005 I heartily agreed with John Siracusa. From early 2006 to late 2010 I worked for Apple. Now, I'd have to say that I disagree. True, technology is a treadmill. What Apple has gotten really good at, though, is moving the treadmill forward instead of running just to stay in the same place. Everyone knows that computers get cheaper, right? See a model you like; wait 6 months; and buy it for 20-50% less. Not with Apple, though. Instead Apple just keeps the price the same and moves the specs up. Same, too, with the technology. While everyone else is out there writing hyper-super-parallel-concurrent-evented-message-passing-functional-object-oriented-metapseudotemplate code, Apple is writing code the same way today that they did in 2000...except this time it's running on the computer in your pocket instead of the tower on your desk. I get it, though. We're engineers. We love design. So we buy Apple kit and we would love to believe that our preferred brand has the same values we do. It certainly did. This is, after all, the company that Woz founded, that employed Raskin and Kay, that still employes Bud Tribble...but I, personally, think that the "glory days" of Apple/NeXT's preeminence in core software are behind them. Of course, UI? UX? Hardware? That's where Apple's engineering focus lies now. Copland 2010 was avoided not because Apple did something about it, but because they changed the rules completely.
ChrisLTD 15y ago
Re: Automatic memory management Siracusa himself concedes in his podcast that Obj-C has garbage collection, but that it was something of a second class citizen. Because garbage collection has been tacked on (and currently not supported on iOS) old pros are unlikely to adopt it. On top of that, newbies who look to the old pros for guidance are going to follow their lead and not use it either. Siracusa also used the same argument against Obj-C's dot syntax.
- protomyth 15y ago
  I think people will adopt garbage collection when it is available for iOS. It is just easier to write without when you might use your libraries in both an iOS and OS X product.
mcritz 15y ago
This is one of the best-written articles on Mac development I've ever read.
Derbasti 15y ago
In his podcast, Siracusa also outlines a possible gradual transition to MacRuby, where MacRuby is more of a bridge at first and gets more and more native implementations of Cocoa classes as time moves on. In the end, Obj-C would get deprecated and all the cool stuff would be happening in MacRuby. Having worked with Cocoa, Ruby and PyQt, I would really really like to see that! As others have said though, this is a somewhat unlikely future right now.
- ddagradi 15y ago
  With multiple MacRuby apps shipping in the Mac App Store right now, and rumors of iOS support in the near future, it doesn't seem completely unlikely.
demallien 15y ago
Objective-C has many good features - native strings is not one of them. There is no syntactic support for appending two strings by a simple '+', for example NSString* myString = @"This is a " + "string."; That simple omission introduces a large amount of pain when working with Objective-C for a large class of applications - especially web-aware, but also including code that parses files. It's the same story with regards to regular expressions - yes there are libraries that can do the job, but they just aren't as pleasant to use as regexps are in the various scripting languages - python, ruby, perl, javascript, etc, where regular expressions are first-class
- naz 15y ago
  NSString *myString = @"This is a" @" string."; Adjacent string constants are concatenated by the preprocessor. Otherwise, I don't think it's too much hassle to call stringByAppendingString:.
  - veidr 15y ago
    True, but adjacent string constants is a totally insane use case that essentially doesn't ever happen. I think the poster was talking about the far more common case of concatenating string variables: NSString *foo = @"Hello, " + userName + @"! (^_^)";
protomyth 15y ago
I like ruby but really don't like the selection syntax mapping used http://www.macruby.org/documentation/tutorial.html http://www.macruby.org/documentation/tutorial.html It doesn't nest as well and you have to look at two different syntaxes to see one selector. I kinda wish they had done something like object.[selector:value selector2:value2]
stephth 15y ago
The Cocoa APIs basically simply ask the developer to fill out a form when they’re asked to do so. I’m not sure how much more higher level and abstracted one can get without relinquishing control of how the data is displayed. It's been successfully achieved with Convention Over Configuration. See MacRuby's HotCocoa.

48 points by ryannielsen 15y ago

Regarding concurrency: [[^ (Foo*) (Foo* bar) { return bar; } copy] autorelease] is a pretty ugly way of writing a lambda. It's like arguing that java can pass functions via anonymous classes. Yes, technically you can but it's pretty ugly. Another underlying problem is that the only language that can call Obj-C libraries is Obj-C. .NET and the JVM solved this problem long ago, I know that Python/Perl/Ruby also have this problem outside of the JVM/CLR. As far as GC, Obj-C effectively doesn't have it as most Obj-C outside of Apple is written for iOS which doesn't support GC. You could create a point system and call Obj-C a modern language but working with it feels anything but. Apple doesn't need any serious rewrite, they need to make MacRuby work on the iPhone. That's it.

ryanpetrich 15y ago
Any language can call Objective-C via the runtime. In pure C: void *foo = objc_msgSend(objc_getClass("NSObject"), sel_registerName("alloc"))
panic 15y ago
In every Objective-C API I've seen that uses blocks, the framework takes care of the "[[... copy] autorelease]" bit. In practice, the code looks something like (to borrow your block with foos and bars): [array transformFoos:^(Foo*) (Foo* bar) { return bar; }]; I'm not sure there is a more succinct way to write a lambda with typed arguments and a typed return value.
schrototo 15y ago
Objective-C can sometimes be pretty verbose, yes, but that's a very contrived block example, especially since it doesn't really relate to concurrency in any way. A more real-world example employing blocks with GCD would be: dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0); dispatch_async(queue, ^{ // do some time-consuming work dispatch_async(dispatch_get_main_queue() ^{ // do stuff on the main thread, like updating UI }); }); That's actually pure C. Typical block usage with Cocoa would be something like: [myArray enumerateObjectsWithOptions:NSEnumerationConcurrent usingBlock:^(id obj, NSUInteger idx, BOOL *stop) { // do something with obj concurrently }];
- headhuntermdk 15y ago
  you forgot a BOOYAH!! at the end of that
- fleitz 15y ago
  Can you really do the latter in Obj-C? As I understood it you needed to copy and autorelease the block to move it from stack allocation to heap allocation.
  - schrototo 15y ago
    That's right, but if the receiver needs to have the block on the heap for whatever reason, it's his responsibility to take care of that. Blocks are really no different from any other method argument.
phatbyte 15y ago
I'm with you on MacRuby, the thing is (anyone correct me if I'm wrong), MacRuby is being maintained by Apple with just one developer, at the last time I checked, so MR still feels like a bastard son, which means, no xcode documentation, or auto-suggest, code browsing like we have with OjbC. But I see it as a good alternative for apple development in a near future, let's just hope Apple sees it as well.
Leynos 15y ago
>Another underlying problem is that the only language that can call Obj-C libraries is Obj-C. In practice this is the case, but the Etoile guys have written AppKit applications in Io and Smalltalk, and they have an ObjC -> JavaScript compiler running thanks to LLVM. So given time, I think this statement will come to be eroded away.
deleted 15y ago
[deleted]
stcredzero 15y ago
Apple doesn't need any serious rewrite, they need to make MacRuby work on the iPhone. That's it. Lua is already on the iPhone, and will probably give you an order of magnitude performance advantage over Ruby.

jballanc 15y ago

In 2005 I heartily agreed with John Siracusa. From early 2006 to late 2010 I worked for Apple. Now, I'd have to say that I disagree. True, technology is a treadmill. What Apple has gotten really good at, though, is moving the treadmill forward instead of running just to stay in the same place. Everyone knows that computers get cheaper, right? See a model you like; wait 6 months; and buy it for 20-50% less. Not with Apple, though. Instead Apple just keeps the price the same and moves the specs up. Same, too, with the technology. While everyone else is out there writing hyper-super-parallel-concurrent-evented-message-passing-functional-object-oriented-metapseudotemplate code, Apple is writing code the same way today that they did in 2000...except this time it's running on the computer in your pocket instead of the tower on your desk. I get it, though. We're engineers. We love design. So we buy Apple kit and we would love to believe that our preferred brand has the same values we do. It certainly did. This is, after all, the company that Woz founded, that employed Raskin and Kay, that still employes Bud Tribble...but I, personally, think that the "glory days" of Apple/NeXT's preeminence in core software are behind them. Of course, UI? UX? Hardware? That's where Apple's engineering focus lies now. Copland 2010 was avoided not because Apple did something about it, but because they changed the rules completely.

ChrisLTD 15y ago

Re: Automatic memory management Siracusa himself concedes in his podcast that Obj-C has garbage collection, but that it was something of a second class citizen. Because garbage collection has been tacked on (and currently not supported on iOS) old pros are unlikely to adopt it. On top of that, newbies who look to the old pros for guidance are going to follow their lead and not use it either. Siracusa also used the same argument against Obj-C's dot syntax.

protomyth 15y ago
I think people will adopt garbage collection when it is available for iOS. It is just easier to write without when you might use your libraries in both an iOS and OS X product.

mcritz 15y ago

This is one of the best-written articles on Mac development I've ever read.

Derbasti 15y ago

In his podcast, Siracusa also outlines a possible gradual transition to MacRuby, where MacRuby is more of a bridge at first and gets more and more native implementations of Cocoa classes as time moves on. In the end, Obj-C would get deprecated and all the cool stuff would be happening in MacRuby. Having worked with Cocoa, Ruby and PyQt, I would really really like to see that! As others have said though, this is a somewhat unlikely future right now.

ddagradi 15y ago
With multiple MacRuby apps shipping in the Mac App Store right now, and rumors of iOS support in the near future, it doesn't seem completely unlikely.

demallien 15y ago

Objective-C has many good features - native strings is not one of them. There is no syntactic support for appending two strings by a simple '+', for example NSString* myString = @"This is a " + "string."; That simple omission introduces a large amount of pain when working with Objective-C for a large class of applications - especially web-aware, but also including code that parses files. It's the same story with regards to regular expressions - yes there are libraries that can do the job, but they just aren't as pleasant to use as regexps are in the various scripting languages - python, ruby, perl, javascript, etc, where regular expressions are first-class

naz 15y ago
NSString *myString = @"This is a" @" string."; Adjacent string constants are concatenated by the preprocessor. Otherwise, I don't think it's too much hassle to call stringByAppendingString:.
- veidr 15y ago
  True, but adjacent string constants is a totally insane use case that essentially doesn't ever happen. I think the poster was talking about the far more common case of concatenating string variables: NSString *foo = @"Hello, " + userName + @"! (^_^)";

protomyth 15y ago

I like ruby but really don't like the selection syntax mapping used http://www.macruby.org/documentation/tutorial.html http://www.macruby.org/documentation/tutorial.html It doesn't nest as well and you have to look at two different syntaxes to see one selector. I kinda wish they had done something like object.[selector:value selector2:value2]

stephth 15y ago

The Cocoa APIs basically simply ask the developer to fill out a form when they’re asked to do so. I’m not sure how much more higher level and abstracted one can get without relinquishing control of how the data is displayed. It's been successfully achieved with Convention Over Configuration. See MacRuby's HotCocoa.