> The Dalvik virtual machine that ships with Android interprets byte code. A byte code interpreter has a few advantages over a stack that runs native code. Performance is not one of those advantages. This is a cheap shot. First of all, when building a JIT or a tracing compiler, it's always better to start with an efficient interpreter ... and for all intents and purposes, Android has a kickass interpreter. Then you c…
Could Ruby be Apple's language and API future?
71–80 of 80 posts
Re: Could Ruby be Apple's language and API future?
#72In my opinion implementing a VM purpose built for a specific language spec is, was, and ever shall be a mistake. Sun was wrong to do it with the original JVMs. In this regard at the very least Dalvik is ahead of the game. The problem of course is, however, that implementing any VM at all on an embedded device results in crap performance from all apps executing through it. The reason Apple chose to remove multitasking and force C# down people's throats was simply because it's the only way to develop an application that is sturdy and fast on an embedded device today. Claiming it frees the developer from having to optimize their code betrays your ignorance of developing on embedded devices.
Re: Could Ruby be Apple's language and API future?
#73Earlier quoted context omitted.
Not at all. Given that they're both dynamic programming languages with runtime dispatch, there's really little impedance mismatch between Ruby and Objective-C. Thus MacRuby, a Ruby implementation that encapsulates Objective-C objects and messages in Ruby objects and methods. Cocoa in Ruby without a bridge -- it's already there, it's a done deal. Now as for whether they'd replace Objective-C with MacRuby, no, that wou…
Having used both Objective-C and .NET, I would much rather be faced with implementing a dynamic language atop .NET than have to do so atop Objective-C. While ObjC's dispatch system is quite dynamic, the relative weakness of the type system (if you can even call what ObjC has a 'type' system) and the amount of C baggage it drags along with it makes it a rather unfriendly environment for running dynamic code. Here's on…
Re: Could Ruby be Apple's language and API future?
#74Earlier quoted context omitted.
Just remember that we're talking about a company that managed to migrate its entire product line to an entirely new processor with few people (inside and outside the company) really knowing until they unveiled the first demo machines. Compared to that, adding a new programming language (that doesn't even affect their existing 3rd party applications) to a platform they own completely is child's play.
To be fair, NeXTStep very publicly run on x86 before NeXT was bought by Apple -- it didn't just appear out of nowhere. And the actual processor is mostly abstracted away -- it's not difficult to simply recompile your apps for another CPU.
Re: Could Ruby be Apple's language and API future?
#75Earlier quoted context omitted.
Apple is sponsoring the development of MacRuby. It's not sponsoring pypy or Haskell LLVM backends.
Just because they "sponsor" MacRuby doesn't mean they favor ruby as a replacement for Objective-C. Until ruby is as fast as Objective-C, I see no reason they would make such a change. Low performance languages have never gained serious adoption on embedded platforms, which includes everything that has made Apple, Inc (not Computer) successful . Maybe I'm a non-believer, but I also don't see any benefit to Apple suppo…
Re: Could Ruby be Apple's language and API future?
#76Re: Could Ruby be Apple's language and API future?
#77Earlier quoted context omitted.
I don't know about "not considered stable." The official MacRuby site claims the current version is "Stable for Cocoa Development." It's not on the iPhone, granted, but that's because it's banned, so nobody wants to waste time on it.
MacRuby is not on the iPhone because there is no garbage collected Objective-C runtime on the iPhone, NOT because it is banned.
Re: Could Ruby be Apple's language and API future?
#78Earlier quoted context omitted.
Not at all. Given that they're both dynamic programming languages with runtime dispatch, there's really little impedance mismatch between Ruby and Objective-C. Thus MacRuby, a Ruby implementation that encapsulates Objective-C objects and messages in Ruby objects and methods. Cocoa in Ruby without a bridge -- it's already there, it's a done deal. Now as for whether they'd replace Objective-C with MacRuby, no, that wou…
Having used both Objective-C and .NET, I would much rather be faced with implementing a dynamic language atop .NET than have to do so atop Objective-C. While ObjC's dispatch system is quite dynamic, the relative weakness of the type system (if you can even call what ObjC has a 'type' system) and the amount of C baggage it drags along with it makes it a rather unfriendly environment for running dynamic code. Here's on…
And I would nitpick the argument that Objective-C requires types for arguments. You can declare arguments as "id" in Objective-C, exercising message passing, and objects will respond to the messages regardless of type. This is why MacRuby and Objective-C are a good fit: both languages are based messages, a concept alien to .NET.
Re: Could Ruby be Apple's language and API future?
#79Earlier quoted context omitted.
Just because they "sponsor" MacRuby doesn't mean they favor ruby as a replacement for Objective-C. Until ruby is as fast as Objective-C, I see no reason they would make such a change. Low performance languages have never gained serious adoption on embedded platforms, which includes everything that has made Apple, Inc (not Computer) successful . Maybe I'm a non-believer, but I also don't see any benefit to Apple suppo…
Btw, Apple is not "sponsoring" MacRuby. Apple is developing MacRuby, it's an Apple project. Will it replace Obj-C? Probably not. Will it become a blessed alternative? Everything seems to point in that direction.