8 ms·

Build iOS Apps In Ruby - Available Summer '12

89 points by teeray 15y ago

holyjaw 15y ago
So, you type out the same obj-c code, but with different syntax. Doesnt seem to save any time at all.
- kennywinker 15y ago
  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]; [person setName:name]; [person setFirstName:first lastName:last]; and in MacRuby person = Person.new person.name person.setName(name) person.setFirstName(first, lastName:last) As far as I can tell in MobiRuby that'd look something like this: person = Person._alloc._init person._name person._setName _S(name) person._setFirstName _S(first), :lastName, _S(last)
  - masuidrive 15y ago
    current method role is tentative. I'll do more improvement.
    - asparagui 15y ago
      ignore the internet, masui, and do whatever you think is best >:3
    - grey-area 15y ago
      In your example you have: alert = UIAlertView._alloc \ ._initWithTitle _S("Hello"), :message, _S("I'm MobiRuby"), :delegate, nil, :cancelButtonTitle, _S("I know!"), :otherButtonTitles, nil alert._show Presumably you don't want to stray from UIKit method names in order to make translation automatic, which is understandable, however translation could be automatic couldn't it - is all that _S necessary? Did you consider a chained, hash syntax something like this: alert = UIAlertView.alloc().initWithTitle(:title => 'Hello', :message => "I'm MobiRuby", :delegate => nil, :cancelButtonTitle => "I know!", :otherButtonTitles => nil).show() With the syntax above someone could omit nil arguments and still get the right result, if you fill in missing arguments for them. Or would that not work for some reason? I understand why you need to keep the method names (for automatic translation), but perhaps the syntax could be a little friendlier and more in line with expectation for Ruby code? I would love to write code for iOS in Ruby (have already written some, but it wouldn't get on the app store due to restrictions), but interfacing with views etc is not too painful in ObjC currently, so if it was more painful in something like this it would put me off. Having looked at your pages further, I see the possibilities of a cross-platform Ruby framework for iOS and Android or WinMo, but if you tie it so tightly to UIKit, how did you plan handling cross-platform issues elegantly? Would that be down to the developers (it is a huge task of course)?
  - grey-area 15y ago
    The trouble is, this causes almost as much friction as just using Objective C in the first place. I use Ruby and ObjC extensively (have even mixed them in a desktop app), so I'm familiar with both. While I find ObjC immensely frustrating for dealing with strings and text, and love to use Ruby for that, the syntax above just makes me cringe - it's not idiomatic Ruby, which would be something more like: 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
    - jballanc 15y ago
      Assuming that "name", "firstName", and "lastName" are KVC compliant properties, you could do this in MacRuby: person = Person.new person.name = "Joe" person.lastName = "Blogs"
cageface 15y ago
It'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 can afford to write most apps primarily or even entirely in "managed" languages like Lua, Java, and (apparently) Ruby.
- deleted 15y ago
  [deleted]
- pjmlp 15y ago
  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.
  - cageface 15y ago
    Of course you need native code on the foundation. But it doesn't look to me like mobile is really going to change the equation that you only need one native programmer for every 100 higher level programmers. 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.
  - HorizonXP 15y ago
    PyPy?
rollypolly 15y ago
Does this project intend to make /all/ of Objective-C available thru Ruby?
- masuidrive 15y ago
  Yes, MobiRuby aim implement all ObjC capability.
ricksta 15y ago
So what does this do? compile ruby code into objective c? or directly into machine code that can be run on iOS?
mxey 15y ago
From a first look, MacRuby does a better job of integrating with Objective C/Cocoa.
iamtoby2003 15y ago
would it save us from the hell of objective c?
- kenver 15y ago
  Why do you think it's hell? I've been using it for about 2-3 years now and it's really grown on me over that time. I think the most common complaint is that it is too verbose, but that has its advantages too.
  - damian2000 15y ago
    what's an advantage of being too verbose? extra exercise for your fingers? ;-)
    - agos 15y ago
      it has big advantages in terms of readability and is necessary for self-documenting code
    - pjmlp 15y ago
      You can always make use of APL if you don't like typing.
      - chc 15y ago
        You could always make use of enterprise Java if you like verbosity. The extremes are probably not the place to be.
        pjmlp 15y ago
        Verbosity is good when you need to maintain projects developed with 300+ developers, scattered across the globe with multiple companies working on the project. Why do you think verbose languages are so loved by big enterprise companies? It is a total different scale of development.
    - 15y ago
koenbok 15y ago
My 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.com/archive/blog/pyobjc-and-cocoa/index.html http://www.madebysofa.com/archive/blog/pyobjc-and-cocoa/inde...
- koenbok 15y ago
  And here too: http://dirkstoop.posterous.com/why-im-slowly-moving-checkout-from-pyobjc-to http://dirkstoop.posterous.com/why-im-slowly-moving-checkout...
thomasjoulin 15y ago
How 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];
- orta 15y ago
  A lot of these things can be abstracted out, but I agree. I think the MacRuby syntax is significantly better for cocoa/uikit ruby. And considering the man who made macruby hasn't been active on it for a long time, I wouldnt be surprised to see him just pop out with something like this one of these days.
- Tloewald 15y ago
  My thoughts exactly. I've gotten used to obj-c over the years but it's still ugly to my eye. This is way uglier and I doubt I'll have a nice editor for it any time soon.
- ashleyw 15y ago
  Exactly. The problem with this and MacRuby is you're only really using the Ruby syntax. The idioms are still mostly the same, which IMO is what makes Ruby shine, not necessarily just the syntax.
  - jeremymcanally 15y ago
    But you're not STUCK with that. You can write wrappers. Look at HotCocoa: that's Cocoa code that looks like Ruby. Even outside of that, though, there are a LOT of things that you can do with MacRuby a lot cleaner thanks to it being Ruby over its Objective-C counterpart. Try launching an external process, for example. It's 5-8 lines of code at the very least in Objective-C (and it's not as flexible), whereas it's 1-3 easy to read lines in Ruby, depending on how much control and feedback you want. I think as it matures, we'll see some wrappers that will make MobiRuby closer to what people are wanting to see from a Ruby-on-iOS solution; it's weird that you guys seem to have no vision for this sort of thing.
LinaLauneBaer 15y ago
Experience taught me this: In the world of OS X/iOS the frameworks are really important. You have to understand them. You have to work with them. It is not uncommon that you need much more time to get familiar with a framework than to get familiar with Objective-C. Take Core Data for example: Core Data is an extremely cool framework but you need a couple of days to understand the basics, a couple of weeks to understand the advanced concepts and years to really master it. Objective-C is a pretty easy programming language. So a a conclusion: Does it really make sense to replace Objective-C with - lets say Ruby? What do you gain? Lets assume you already know Ruby - then it saves you to learn Objective-C. But 90% of the time you will deal with the frameworks - not with the language. In my opinion it does not really make sense to use Ruby instead of Objective-C because you save so little.
- mcobrien 15y ago
  I already know and use both, but find I'm much more productive with ruby because it's so expressive. While this project isn't going to do much to simplify my Cocoa code, the rest of my app could be much simpler as a result.
  - LinaLauneBaer 15y ago
    Wait... cageface wrote: "but the verbosity really gets in the way" and you write "I'm much more productive with ruby because it's so expressive.". I am not a native speaker but isn't that contradictory?
    - com 15y ago
      Verbosity is a subjective assessment that concepts require too many or complex, specialised words to express compared with some other approach. Expressiveness is subjective too, but in this context talks about ability to express concepts in elegant or clear ways.
      - LinaLauneBaer 15y ago
        Thank you very much for this clarification.
floydprice 15y ago
I'm assuming that you will wrap this all up in ruby objects and expose a cleaner syntax? As orta said the Objective-C syntax is currently cleaner. From an engineering point of view i have to say that this is impressive, very keen to see what tools you come up with to aid the development process, a TextMate bundle to compile and deploy to the sim would be super sweet ;-)
jarsj 15y ago
I love obj-c, especially after the blocks. Sorry, you guys are too late.
damian2000 15y ago
If they can pull this off, I'll definitely be on board ... good luck.
brackishlake 15y ago
People of Earth: This is nonsense. Objective C is a fantastic language. Appcelerator Titanium, PhoneGap - it's all crap. Customers can feel the difference. To make a native app, learn a native language.
- 89a 15y ago
  Really wish the Flash devs I worked with thought this way. "Oh I've been looking into PhoneGap, it's pretty cool" "Oh I've been learning Android development" WHY???? When has a client even asked us to make an Android app.
  - gte910h 15y ago
    While iOS devices are pretty up to date, phonegap/flash/titanium/corona are actually pretty nice on android when you have 15 different operating system versions all seemeingly evenly deployed on the market
Radzell 15y ago
How about you learn the native language. You will never get the most out of a platform without going native. Apps like instagram, any games, and the most exciting apps in mobile will always be native. Great programmers have the tools to build what needs to build.
- ericb 15y ago
  Totally. That is why I code my web apps in assembly. Frameworks and higher level languages have nothing to offer.
  - Radzell 15y ago
    Thats not the same because iOS and android are both frameworks. Adding framework onto framework especially on mobile which moves so fast cause more problem than it solves because people start complain that google or apple broke there framework which shouldn't have been there in the first place.
dkrich 15y ago
Will I be able to make a photo-sharing app with this?

89 points by teeray 15y ago

holyjaw 15y ago

So, you type out the same obj-c code, but with different syntax. Doesnt seem to save any time at all.

kennywinker 15y ago
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]; [person setName:name]; [person setFirstName:first lastName:last]; and in MacRuby person = Person.new person.name person.setName(name) person.setFirstName(first, lastName:last) As far as I can tell in MobiRuby that'd look something like this: person = Person._alloc._init person._name person._setName _S(name) person._setFirstName _S(first), :lastName, _S(last)
- masuidrive 15y ago
  current method role is tentative. I'll do more improvement.
  - asparagui 15y ago
    ignore the internet, masui, and do whatever you think is best >:3
  - grey-area 15y ago
    In your example you have: alert = UIAlertView._alloc \ ._initWithTitle _S("Hello"), :message, _S("I'm MobiRuby"), :delegate, nil, :cancelButtonTitle, _S("I know!"), :otherButtonTitles, nil alert._show Presumably you don't want to stray from UIKit method names in order to make translation automatic, which is understandable, however translation could be automatic couldn't it - is all that _S necessary? Did you consider a chained, hash syntax something like this: alert = UIAlertView.alloc().initWithTitle(:title => 'Hello', :message => "I'm MobiRuby", :delegate => nil, :cancelButtonTitle => "I know!", :otherButtonTitles => nil).show() With the syntax above someone could omit nil arguments and still get the right result, if you fill in missing arguments for them. Or would that not work for some reason? I understand why you need to keep the method names (for automatic translation), but perhaps the syntax could be a little friendlier and more in line with expectation for Ruby code? I would love to write code for iOS in Ruby (have already written some, but it wouldn't get on the app store due to restrictions), but interfacing with views etc is not too painful in ObjC currently, so if it was more painful in something like this it would put me off. Having looked at your pages further, I see the possibilities of a cross-platform Ruby framework for iOS and Android or WinMo, but if you tie it so tightly to UIKit, how did you plan handling cross-platform issues elegantly? Would that be down to the developers (it is a huge task of course)?
- grey-area 15y ago
  The trouble is, this causes almost as much friction as just using Objective C in the first place. I use Ruby and ObjC extensively (have even mixed them in a desktop app), so I'm familiar with both. While I find ObjC immensely frustrating for dealing with strings and text, and love to use Ruby for that, the syntax above just makes me cringe - it's not idiomatic Ruby, which would be something more like: 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
  - jballanc 15y ago
    Assuming that "name", "firstName", and "lastName" are KVC compliant properties, you could do this in MacRuby: person = Person.new person.name = "Joe" person.lastName = "Blogs"

cageface 15y ago

It'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 can afford to write most apps primarily or even entirely in "managed" languages like Lua, Java, and (apparently) Ruby.

deleted 15y ago
[deleted]
pjmlp 15y ago
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.
- cageface 15y ago
  Of course you need native code on the foundation. But it doesn't look to me like mobile is really going to change the equation that you only need one native programmer for every 100 higher level programmers. 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.
- HorizonXP 15y ago
  PyPy?

rollypolly 15y ago

Does this project intend to make /all/ of Objective-C available thru Ruby?

masuidrive 15y ago
Yes, MobiRuby aim implement all ObjC capability.

ricksta 15y ago

So what does this do? compile ruby code into objective c? or directly into machine code that can be run on iOS?

mxey 15y ago

From a first look, MacRuby does a better job of integrating with Objective C/Cocoa.

iamtoby2003 15y ago

would it save us from the hell of objective c?

kenver 15y ago
Why do you think it's hell? I've been using it for about 2-3 years now and it's really grown on me over that time. I think the most common complaint is that it is too verbose, but that has its advantages too.
- damian2000 15y ago
  what's an advantage of being too verbose? extra exercise for your fingers? ;-)
  - agos 15y ago
    it has big advantages in terms of readability and is necessary for self-documenting code
  - pjmlp 15y ago
    You can always make use of APL if you don't like typing.
    - chc 15y ago
      You could always make use of enterprise Java if you like verbosity. The extremes are probably not the place to be.
      - pjmlp 15y ago
        Verbosity is good when you need to maintain projects developed with 300+ developers, scattered across the globe with multiple companies working on the project. Why do you think verbose languages are so loved by big enterprise companies? It is a total different scale of development.
  - 15y ago

koenbok 15y ago

My 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.com/archive/blog/pyobjc-and-cocoa/index.html http://www.madebysofa.com/archive/blog/pyobjc-and-cocoa/inde...

koenbok 15y ago
And here too: http://dirkstoop.posterous.com/why-im-slowly-moving-checkout-from-pyobjc-to http://dirkstoop.posterous.com/why-im-slowly-moving-checkout...

thomasjoulin 15y ago

How 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];

orta 15y ago
A lot of these things can be abstracted out, but I agree. I think the MacRuby syntax is significantly better for cocoa/uikit ruby. And considering the man who made macruby hasn't been active on it for a long time, I wouldnt be surprised to see him just pop out with something like this one of these days.
Tloewald 15y ago
My thoughts exactly. I've gotten used to obj-c over the years but it's still ugly to my eye. This is way uglier and I doubt I'll have a nice editor for it any time soon.
ashleyw 15y ago
Exactly. The problem with this and MacRuby is you're only really using the Ruby syntax. The idioms are still mostly the same, which IMO is what makes Ruby shine, not necessarily just the syntax.
- jeremymcanally 15y ago
  But you're not STUCK with that. You can write wrappers. Look at HotCocoa: that's Cocoa code that looks like Ruby. Even outside of that, though, there are a LOT of things that you can do with MacRuby a lot cleaner thanks to it being Ruby over its Objective-C counterpart. Try launching an external process, for example. It's 5-8 lines of code at the very least in Objective-C (and it's not as flexible), whereas it's 1-3 easy to read lines in Ruby, depending on how much control and feedback you want. I think as it matures, we'll see some wrappers that will make MobiRuby closer to what people are wanting to see from a Ruby-on-iOS solution; it's weird that you guys seem to have no vision for this sort of thing.

LinaLauneBaer 15y ago

Experience taught me this: In the world of OS X/iOS the frameworks are really important. You have to understand them. You have to work with them. It is not uncommon that you need much more time to get familiar with a framework than to get familiar with Objective-C. Take Core Data for example: Core Data is an extremely cool framework but you need a couple of days to understand the basics, a couple of weeks to understand the advanced concepts and years to really master it. Objective-C is a pretty easy programming language. So a a conclusion: Does it really make sense to replace Objective-C with - lets say Ruby? What do you gain? Lets assume you already know Ruby - then it saves you to learn Objective-C. But 90% of the time you will deal with the frameworks - not with the language. In my opinion it does not really make sense to use Ruby instead of Objective-C because you save so little.

mcobrien 15y ago
I already know and use both, but find I'm much more productive with ruby because it's so expressive. While this project isn't going to do much to simplify my Cocoa code, the rest of my app could be much simpler as a result.
- LinaLauneBaer 15y ago
  Wait... cageface wrote: "but the verbosity really gets in the way" and you write "I'm much more productive with ruby because it's so expressive.". I am not a native speaker but isn't that contradictory?
  - com 15y ago
    Verbosity is a subjective assessment that concepts require too many or complex, specialised words to express compared with some other approach. Expressiveness is subjective too, but in this context talks about ability to express concepts in elegant or clear ways.
    - LinaLauneBaer 15y ago
      Thank you very much for this clarification.

floydprice 15y ago

I'm assuming that you will wrap this all up in ruby objects and expose a cleaner syntax? As orta said the Objective-C syntax is currently cleaner. From an engineering point of view i have to say that this is impressive, very keen to see what tools you come up with to aid the development process, a TextMate bundle to compile and deploy to the sim would be super sweet ;-)

jarsj 15y ago

I love obj-c, especially after the blocks. Sorry, you guys are too late.

damian2000 15y ago

If they can pull this off, I'll definitely be on board ... good luck.

brackishlake 15y ago

People of Earth: This is nonsense. Objective C is a fantastic language. Appcelerator Titanium, PhoneGap - it's all crap. Customers can feel the difference. To make a native app, learn a native language.

89a 15y ago
Really wish the Flash devs I worked with thought this way. "Oh I've been looking into PhoneGap, it's pretty cool" "Oh I've been learning Android development" WHY???? When has a client even asked us to make an Android app.
- gte910h 15y ago
  While iOS devices are pretty up to date, phonegap/flash/titanium/corona are actually pretty nice on android when you have 15 different operating system versions all seemeingly evenly deployed on the market

Radzell 15y ago

How about you learn the native language. You will never get the most out of a platform without going native. Apps like instagram, any games, and the most exciting apps in mobile will always be native. Great programmers have the tools to build what needs to build.

ericb 15y ago
Totally. That is why I code my web apps in assembly. Frameworks and higher level languages have nothing to offer.
- Radzell 15y ago
  Thats not the same because iOS and android are both frameworks. Adding framework onto framework especially on mobile which moves so fast cause more problem than it solves because people start complain that google or apple broke there framework which shouldn't have been there in the first place.

dkrich 15y ago

Will I be able to make a photo-sharing app with this?