

Regarding Objective-C & Copland 2010 - ryannielsen
http://kickingbear.com/blog/archives/168

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

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

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

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

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

------
protomyth
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]

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

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

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

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

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

