Live data from Hacker News

Could Ruby be Apple's language and API future?

parveenkaler.com

71–80 of 80 posts

Re: Could Ruby be Apple's language and API future?

#71

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

I am quite interested in the topic of java vs C++ and java vs C performance. Do you have specific examples that I can run down?

Re: Could Ruby be Apple's language and API future?

#72
You really can't avoid native execution if you want to really push the frontiers on these devices. And because these are such small devices even lone developers can really push boundaries and make money and a name for themselves. But the second you start blindly "optimizing" their products, bad things happen in spades.

In 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?

#73
post #34

Earlier 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…

Thanks for commenting on this, you clearly know a lot more about this topic than I do.

Re: Could Ruby be Apple's language and API future?

#74
post #14

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

http://en.wikipedia.org/wiki/Apple_A4#History

Re: Could Ruby be Apple's language and API future?

#75
post #42
post #4

Earlier 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…

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.

Re: Could Ruby be Apple's language and API future?

#77
post #35

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

Not so. The MacRuby team had already thought up a number of ideas for working around the lack of a garbage collected runtime (the most promising was similar to the direction Apple's going with Objective-C, where retain and release happen automatically based on policies). They never got implemented because Apple instituted the ban on programming languages right around the same time.

Re: Could Ruby be Apple's language and API future?

#78
post #34

Earlier 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…

I would argue the Smalltalk-esque message-passing system is an advantage, not a weakness. A large amount of the dynamic nature of languages like MacRuby can be captured with such a system whereas on .NET you need another abstraction layer (like the Dynamic Language Runtime), leaks and all.

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?

#79
post #42

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

Could not agree more. MacRuby exists, it's great. Use it. Who cares whether or not it will replace or complement Obj-C, sliced bread or even the internal combustion engine. GC is the key to the iOS port. Not there yet, so no option at the moment. Of course the future (maybe distant, maybe near) will bring GC to iOS and MacRuby with it. No need for reinventing the wheel.

Re: Could Ruby be Apple's language and API future?

#80
post #68

Nah, I think Apple has already chosen JavaScript. Don't forget, Apple actually spearheaded the HTML5 movement...

> Apple actually spearheaded the HTML5 movement... Hahaha, that was good. =)

good and true, html5/css3 innovation started with Apple's work on webkit.
Post reply on HN