Build iOS Apps In Ruby - Available Summer '12

by teeray • 14 years ago

89 52 14 years ago

cageface4• 14 years 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.

pjmlp3• 14 years 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.

cageface4• 14 years 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• 14 years ago

PyPy?

rollypolly• 14 years ago

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

masuidrive2• 14 years ago

Yes, MobiRuby aim implement all ObjC capability.

ricksta• 14 years ago

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

holyjaw• 14 years ago

So, you type out the same obj-c code, but with different syntax.

Doesnt seem to save any time at all.

kennywinker2• 14 years 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)

masuidrive2• 14 years ago

current method role is tentative. I'll do more improvement.

grey-area2• 14 years 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

mxey• 14 years ago

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

iamtoby2003• 14 years ago

would it save us from the hell of objective c?

kenver• 14 years 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.

damian20002• 14 years ago

what's an advantage of being too verbose? extra exercise for your fingers? ;-)

koenbok2• 14 years 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/inde...

koenbok2• 14 years ago

And here too: http://dirkstoop.posterous.com/why-im-slowly-moving-checkout...

thomasjoulin• 14 years 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• 14 years 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• 14 years 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• 14 years 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• 14 years 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.

buff-a• 14 years ago

Because its actually:

file.rb:

  require 'stuff'

  class foo
    def something
      alert = UIAlertView._alloc \
        ._initWithTitle _S("Hello"),
        :message, _S("I'm MobiRuby"),
        :delegate, nil,
        :cancelButtonTitle, _S("I know!"),
        :otherButtonTitles, nil
      alert._show
    end
  end

Instead of

file.h

  #import <stuff>
  @interface foo
    -(void)something:(BOOL)what andthen:(CGRect)thisthing
  @end

and then file.m

  #import <otherstuff>
  #import <yetmorestuff>
  #import "file.h"
  #import <oh shit is this in the right place?.h>
  #import <i think this is ok>
  #define SOME_HACK
  #import <this better come after that define up there.h>

  @implementation foo

  -(void)something:(BOOL)what butthen:(CGRect)thisthing
  {
   alert = [[UIAlertView alloc] 
                initWithTitle:@"Hello"
                message:@"I'm ObjC"
                delegate:nil
                cancelButtonTitle:@"I know!"
                otherButtonTitles:nil];
     [alert show];
  }

Fuck that.

1. Don't Repeat Yourself. Computer have more memory than 1986.

2. Don't forget to turn on warnings-as-errors, otherwise that code above will compile and then break because (of course you noticed) the method declaration doesn't actually match the declaration but the compiler doesn't care because its a brutal hack.

EzGraphs• 14 years ago

Definitely agree. The place where ruby syntax might shine a bit is in code that does not interact with the Cocoa/IOs specific libraries (e.g. doing calculation, parsing/manipulating strings).

LinaLauneBaer3• 14 years 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• 14 years 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.

LinaLauneBaer3• 14 years 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?

cageface4• 14 years ago

For code that's just gluing bits of the API together I agree you're not going to do much better than Objective-C and really that kind of code makes up the bulk of most apps.

Obj-C really falls down for more complex algorithms, data structures, and text handling. You can do this kind of thing in Obj-C, of course, but the verbosity really gets in the way. A higher-level language like Ruby would be great for this but maybe the new object literals coming in Obj-C will help close the gap.

philwelch• 14 years ago

Still don't see it. Algorithms and data structures are going to be the most performance critical parts. It's the glue code if anything that should be written in a scripting language.

floydprice• 14 years 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• 14 years ago

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

damian20002• 14 years ago

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

brackishlake• 14 years 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• 14 years 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• 14 years 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

Radzell2• 14 years 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• 14 years ago

Totally. That is why I code my web apps in assembly. Frameworks and higher level languages have nothing to offer.

Radzell2• 14 years 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• 14 years ago

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

Build iOS Apps In Ruby - Available Summer '12

Related Stories