

Copland 2010 revisited: Apple's language and API future - ZeroGravitas
http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars

======
cpr
I think John's right to wonder what's next for Obj-C, as much as I like using
the whole Obj-C/Cocoa (Touch) environment.

There's just no easy way forward out of the swamps of C-level memory
management that doesn't break the world in some way. Even turning on GC (as we
have under OS X) isn't a panacea: there are plenty of Core Foundation kinds of
calls that don't participate automatically in GC (you have to manually connect
each such allocation to GC). And with "unmanaged" pointers at the C/Obj-C/C++
level, you'll always have to step gingerly around GC.

And he's right to think ahead 5-10 years and realize that we're probably not
going to be doing manual memory management then.

So what's the way over the chasm? I don't think anyone really knows, even at
Apple.

Perhaps (pure speculation) the MacRuby efforts are part of a back-up plan to
see if a ("managed" by definition) dynamic language could help bridge the gap
without breaking the world. The MacRuby compiler claims performance on a par
with Obj-C or better (using LLVM).

It'll be interesting to see how this plays out.

~~~
weeksie
Good point, but I imagine that a better way forward would be to go to a
dynamic language that can be optimized really well. Lua or Javascript would be
fantastic choices. Ruby is a great language, and one of my favourite to
program in, but it just isn't performant enough for low level work.

~~~
cpr
The MacRuby folks would claim otherwise.

Yes, I'd also love to see JS become "the next step" (since it seems to be
becoming the "machine language" of the future) but it would probably have to
be augmented like Objective-J to make Cocoa (Touch) development plausible.

~~~
weeksie
The MacRuby folk would be wrong.

I actually hadn't looked too closely at MacRuby. It is quite an achievement,
but compared to (particularly) Lua it's just not fast enough. Compare that to
LuaJIT and the differences are remarkable. If MacRuby could be made as fast as
Lua then I'd be all for it, I just don't think it's possible given the
language semantics.

I guess what I'm saying is that the idea of a dynamic language like any of
Lua, Ruby, Javascript, etc. . . being the default systems language on iOS and
Mac OS would be amazing; I just don't like Ruby's chances when paired against
the other two.

~~~
Zev
_I actually hadn't looked too closely at MacRuby._

Might I suggest that you do so?

 _...but compared to (particularly) Lua it's just not fast enough._

I beg to differ; Here's why: [http://christopherroach.com/2010/01/21/ruby-
fibonacci-shooto...](http://christopherroach.com/2010/01/21/ruby-fibonacci-
shootout-2/)

 _I just don't like Ruby's chances when paired against the other two._

I do. JS might give it a run, with WebKit also being Apple-sponsored. But,
there's no Apple-sponsored Lua implementation. And JS from WebKit doesn't have
any sort of (easy to use) way to access Cocoa, like MacRuby does (with
HotCocoa).

~~~
mikemike
Sigh, not that nonsense comparison again.

Apart from using suboptimal Lua code (the author obviously doesn't know about
the Lua keyword 'local'), LuaJIT beta2 didn't compile recursion at all. It
runs more than 4x faster with the current version and beats MacRuby easily.

Oh, and comparing language implementations based on the speed of a recursive
Fibonacci number generator has exactly zero real-world relevance. Try again
with a more realistic mix of benchmarks or something domain-specific like
SciMark (LuaJIT is only 30% slower than GCC on this one).

Judging from [http://antoniocangiano.com/2010/05/16/benchmarking-
macruby-0...](http://antoniocangiano.com/2010/05/16/benchmarking-macruby-0-6/)
MacRuby plays in the same league as the other Ruby implementations. And
[http://shootout.alioth.debian.org/u32/benchmark.php?test=all...](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all)
tells you where that league can be found, relative to LuaJIT. Hint: scroll to
the bottom. :-)

------
jcromartie
Here's my question: how many popular, big-name consumer applications are
written in C# on Windows?

~~~
jcl
That's a good question. Lots of corporate intranet apps are written in C#, but
it's hard to tell what consumer apps are, since it's not something that
companies advertise.

For what it's worth, we do know, however, that .NET technology is an important
component of all games made with Unity.

~~~
jcromartie
Unity is cross-platform (Mac, Windows, Wii, iOS) though, and is really built
on Mono and not Microsoft's implementation. So I don't think that counts,
since Ars is arguing that .NET is competing with Obj-C and Cocoa as the native
language/API of choice for desktop apps.

~~~
jcl
I'm pretty sure it counts... Ars is arguing that Objective-C will be left
behind by a higher-level, managed language, which is precisely what is
happening with Unity, regardless of whether Microsoft implemented it or what
platform it runs on.

~~~
jcromartie
They are arguing that .NET is already that language for Windows, which I don't
think is true.

------
dkarl
On the desktop, Java is the obvious missing elephant in the room. Java was
popular, the non-GUI parts of Java were fast enough, but there were no good
GUI libraries. Java continues to be anathema on the desktop because of the
number of crappy apps written with Sun's officially blessed UI library, Swing.
It didn't have to be that way. I've written a pretty snappy app using the
Eclipse platform, which is based on SWT, which uses platform-specific code. In
retrospect it's clear that Sun's write-once, run-anywhere ideal, which was
Java's biggest strength on the server, was a disaster on the desktop. Sun
should have provided Java bindings to common platform UI libraries and
encouraged their use. If they had done that, Java would have been a much
bigger player on the desktop, and GUI development would not have lagged so far
behind in adoption of modern languages.

------
amanuel
GCD, Klang, LLVM, GC are all huge advancements at the basement level.

Apple's language and APIs weren't the problem in the days of Copland. It was
the kernel/Core OS.

I'm not sure the case of the sky is falling can be made at this time...to do
so you'd have to first argue that Unix is dead/on its way out.

------
zefhous
I couldn't read this without thinking about MacRuby.

It's hard for me to believe that he hasn't heard of MacRuby, but if he had,
how could he not mention it in the article.

MacRuby could be a great answer to a lot of the issues he brings up.

~~~
dkarl
Scripting languages on any platform are a great answer. PyQt is even a good
answer on Linux. They don't establish an "expected" standard, though. If
you're developing on Windows, you need a pretty good excuse to use "unsafe"
code. On Linux and OSX, people use manual memory management without realizing
they've shouldered an unnecessary burden. It's the default.

~~~
Zev
MacRuby isn't a scripting language, though. Or, it doesn't have to be. It can
get compiled down to machine code if you're making an application in it.

------
bambax
I don't understand why mobile devices have so little "RAM" when they have
fixed storage in the tens of Gos that is effectively made of memory chips...?

What is the difference between the two kinds of memory, and why isn't more RAM
added? Is it a cost problem? a size problem? both? Or is the CPU not capable
of addressing more RAM...?

~~~
j_baker
I hadn't considered that before. You would figure that it would be pretty easy
to add virtual memory to ios.

~~~
tpz
But then it would have to swap, the user experience would suffer
unpredictably, Steve Jobs would strangle the engineer responsible and the
feature would never see the light of day.

~~~
neilc
"Virtual memory" does not imply "it would have to swap"; indeed, the iPhone
does have virtual memory, and each application has its own virtual address
space.

------
protomyth
How about Objective-C gets a lot of its juice from Smalltalk. He seems to have
a real lack of experience / understanding on what Objective-C actually is and
how it has evolved in features and use (pre-Apple to now).

It just seems like a really bad article for Ars Technica. This line in
particular makes no sense "Nevertheless, Mac developers and users are not
panicking like they did in the Copland era about memory protection and
preemptive multitasking.". Garbage Collection = Memory Protection ... what
the?

~~~
boucher
I wouldn't question Siracusa's technical chops, he's definitely earned them.
He's intimately familiar with Objective-C and its history.

As for your second claim, I really don't follow. Memory protection has nothing
to do with garbage collection in that quote. He's talking about protected/per
process address spaces.

~~~
glhaynes
I think protomyth is saying that Siracusa's mistake is in assuming that GC is
really _that_ important... the "classic" Mac experience was considerably and
noticeably worse for not having protected memory. Many even "average" users
understood that their Mac didn't have protected memory and so application
crashes could often bring down the whole system, thus they clamored for
protected memory.

There's absolutely no such outcry, though, among Mac OS X or iOS users for
widespread use of garbage collection, and why would there be? In general,
Mac/iOS users think of their apps as being more pleasant to use than those on
other systems _already_. I think Siracusa's mistake is in assuming that just
because a managed system is inevitable (how much retain/release do you think
will be done in 25 years? obviously nearly none) that this means that the
benefits of GC are so great as to be a make-or-break... in actuality, the
benefit of GC in practice seems to be more on the order of having a nice
framework or two built-in.

~~~
dkarl
There are entire categories of applications in the app store that are plagued
by crashes. Check out the Netflix applications; I just went to the app store
to buy one, and they all have 2.5-3 stars. Check the reviews and you see a ton
of one star reviews saying "Crashes constantly," "Crashes," "Useless,"
"Crashes every time you do X." These are popular commercial apps in what I
presume is a pretty popular category of apps. It wasn't the first time I
searched for an iPhone app and found a bunch of $2 and $3 paid apps with tons
of stability complaints. Actually I felt quite lucky to find one lone Netflix
app with a 4-star rating. No point in comparing features or reviews; I'll take
the one that doesn't crash constantly.

