43 ms·

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 o

by cpr 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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-shootout-2/ http://christopherroach.com/2010/01/21/ruby-fibonacci-shooto... 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).
      - weeksie 16y ago
        So there's one fibonacci sequence benchmark that's faster? Come on. The issue with Ruby is that the things that make it so nice (all of the great object model and meta-programming additions) also bring a certain level of overhead. If it was such a simple task to optimize then the MagLev guys would have produced a kick ass speedy Ruby years ago, based on all of the things that they know about Smalltalk VMs. That said, if Apple has the resources to make MacRuby as fast as Objective C then holy crap; I'd be on that like white on rice. I don't believe for a moment that Apple would ever use Lua as their systems language of choice; more that I personally thought it would be a great pick. As much as I love Ruby I seriously doubt that Apple would ever be able to squeeze the required performance out of it; the language itself is the problem, not the implementation. Look at all of the work that's gone into producing fast Ruby VMs over the last several years . . . Really, there's low hanging fruit out there and Ruby just doesn't make sense in this context.
      - mikemike 16y ago
        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-6/ http://antoniocangiano.com/2010/05/16/benchmarking-macruby-0... MacRuby plays in the same league as the other Ruby implementations. And http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all http://shootout.alioth.debian.org/u32/benchmark.php?test=all... tells you where that league can be found, relative to LuaJIT. Hint: scroll to the bottom. :-)

by cpr 16y ago

weeksie 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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-shootout-2/ http://christopherroach.com/2010/01/21/ruby-fibonacci-shooto... 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).
    - weeksie 16y ago
      So there's one fibonacci sequence benchmark that's faster? Come on. The issue with Ruby is that the things that make it so nice (all of the great object model and meta-programming additions) also bring a certain level of overhead. If it was such a simple task to optimize then the MagLev guys would have produced a kick ass speedy Ruby years ago, based on all of the things that they know about Smalltalk VMs. That said, if Apple has the resources to make MacRuby as fast as Objective C then holy crap; I'd be on that like white on rice. I don't believe for a moment that Apple would ever use Lua as their systems language of choice; more that I personally thought it would be a great pick. As much as I love Ruby I seriously doubt that Apple would ever be able to squeeze the required performance out of it; the language itself is the problem, not the implementation. Look at all of the work that's gone into producing fast Ruby VMs over the last several years . . . Really, there's low hanging fruit out there and Ruby just doesn't make sense in this context.
    - mikemike 16y ago
      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-6/ http://antoniocangiano.com/2010/05/16/benchmarking-macruby-0... MacRuby plays in the same league as the other Ruby implementations. And http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all http://shootout.alioth.debian.org/u32/benchmark.php?test=all... tells you where that league can be found, relative to LuaJIT. Hint: scroll to the bottom. :-)