Regarding Objective-C & Copland 2010 | Hacker News Reader

Regarding Objective-C & Copland 2010

kickingbear.com

48 pointsryannielsen21 comments

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.

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

   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:.

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 + @"! (^_^)";

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.

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.

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.

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.

I like ruby but really don't like the selection syntax mapping used 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]

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

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.

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.

Any language can call Objective-C via the runtime. In pure C: void *foo = objc_msgSend(objc_getClass("NSObject"), sel_registerName("alloc"))

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.

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
  }];

you forgot a BOOYAH!! at the end of that

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.

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.

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.

>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.

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.

Reply on news.ycombinator.com