My cofounder did a nice talk on our experiences: http://www.madebysofa.com/archive/blog/pyobjc-and-cocoa/inde...
Build iOS Apps In Ruby - Available Summer '12
11–20 of 54 posts
Re: Build iOS Apps In Ruby - Available Summer '12
#12 alert = UIAlertView._alloc \
._initWithTitle _S("Hello"),
:message, _S("I'm MobiRuby"),
:delegate, nil,
:cancelButtonTitle, _S("I know!"),
:otherButtonTitles, nil
alert._show
supposed to be better than this ? alert = [[UIAlertView alloc]
initWithTitle:@"Hello"
message:@"I'm ObjC"
delegate:nil
cancelButtonTitle:@"I know!"
otherButtonTitles:nil];
[alert show];Re: Build iOS Apps In Ruby - Available Summer '12
#13My previous company shipped mac desktop apps written in Python. It made sense at the time (no sqlalchemy for cocoa) but turned out not to be great for many reasons. The two main ones imho were that the language doesn't fit the framework (argument passing style) and that you have to understand both languages and the bridge to be able to debug well. My cofounder did a nice talk on our experiences: http://www.madebysofa…
Re: Build iOS Apps In Ruby - Available Summer '12
#14Does this project intend to make /all/ of Objective-C available thru Ruby?
Re: Build iOS Apps In Ruby - Available Summer '12
#15So, you type out the same obj-c code, but with different syntax. Doesnt seem to save any time at all.
Well any way you slice it you're still going to have to interface with the Cocoa frameworks that make up the OS. Anything that masks the interface too much just causes friction. e.g. you can't look stuff up in the docs anymore. MacRuby does a bit better job at first glance than this does, but you can't get past the way the framework you're using works. In Objective-C: Person *person = [Person new]; [person name]; [pe…
Re: Build iOS Apps In Ruby - Available Summer '12
#16So, you type out the same obj-c code, but with different syntax. Doesnt seem to save any time at all.
Well any way you slice it you're still going to have to interface with the Cocoa frameworks that make up the OS. Anything that masks the interface too much just causes friction. e.g. you can't look stuff up in the docs anymore. MacRuby does a bit better job at first glance than this does, but you can't get past the way the framework you're using works. In Objective-C: Person *person = [Person new]; [person name]; [pe…
person = Person.new
person.update_attributes(:name => 'Joe', :surname => 'Blogs')
OR
person = Person.new
person.name = "Joe"
person.last_name = "Blogs"
So why not just use ObjC and call a bundled script which deals well with a specific problem in a rubyish way, and takes input from files, rather than mixing up the two paradigms and ending up with a Frankenstein language which is harder to parse from both sides? I think Apple bans calling bundled scripts on iOS (or did, not sure if the rules have changed), but that's not a technical problem but a political one.I understand people might want to try to use the strengths of Ruby (munging text, some nice libraries), but to get there, you're throwing out some of the nicest things about Ruby - a lovely syntax that doesn't get in your way, and method names you can easily guess. Usually writing Ruby I find I don't have to look up methods and can stay in the flow, but I can't say the same about the cocoa API, with NSString in particular full of huge method names and bizarre syntax for simple operations. So this is throwing out that advantage for the dubious advantage of being able to call cocoa methods from Ruby (using a weird syntax).
YMMV
Re: Build iOS Apps In Ruby - Available Summer '12
#17How is this : alert = UIAlertView._alloc \ ._initWithTitle _S("Hello"), :message, _S("I'm MobiRuby"), :delegate, nil, :cancelButtonTitle, _S("I know!"), :otherButtonTitles, nil alert._show supposed to be better than this ? alert = [[UIAlertView alloc] initWithTitle:@"Hello" message:@"I'm ObjC" delegate:nil cancelButtonTitle:@"I know!" otherButtonTitles:nil]; [alert show];
Re: Build iOS Apps In Ruby - Available Summer '12
#18would it save us from the hell of objective c?
Re: Build iOS Apps In Ruby - Available Summer '12
#19It's things like this and Corona (Lua) that make me thing that the people that are proclaiming that the emergence of mobile is going to lead to a native code "renaissance" are indulging in some wishful thinking. Sure, there will always be some apps that will need to be coded close to the metal in C/C++ for maximum performance. But now we're seeing more and more that even on mobile devices we have enough power that we…
In which languages are you then coding the VM/JIT? At some level you need native code. For me, I want something like Ruby that generates native code.
I'm not optimistic about trying to generate good native code from a language like Ruby. You need much more control over memory layout, just for starters, to get real native speeds.
Re: Build iOS Apps In Ruby - Available Summer '12
#20It's things like this and Corona (Lua) that make me thing that the people that are proclaiming that the emergence of mobile is going to lead to a native code "renaissance" are indulging in some wishful thinking. Sure, there will always be some apps that will need to be coded close to the metal in C/C++ for maximum performance. But now we're seeing more and more that even on mobile devices we have enough power that we…
In which languages are you then coding the VM/JIT? At some level you need native code. For me, I want something like Ruby that generates native code.