

Build iOS Apps In Ruby - Available Summer '12 - teeray
http://mobiruby.org/

======
thomasjoulin
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];

~~~
ashleyw
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
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.

------
koenbok
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...](http://www.madebysofa.com/archive/blog/pyobjc-and-
cocoa/index.html)

~~~
koenbok
And here too: [http://dirkstoop.posterous.com/why-im-slowly-moving-
checkout...](http://dirkstoop.posterous.com/why-im-slowly-moving-checkout-
from-pyobjc-to)

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

~~~
cageface
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
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.

~~~
cageface
Sure, but in a lot of today's apps there are no performance critical parts.
They're already well under the ceiling of what the hardware can do all the
time or they spent 95% of their CPU in optimized routines in the OS/kernel. Of
course, a more expressive but faster language like Mirah or Kotlin or Go
something would be ideal here.

The problem with writing glue code in a scripting language is that it doesn't
really buy you much unless you can impose a new, higher-level abstraction on
the existing UI. As these examples show, you haven't really improved on Cocoa
if all you've done is changed the function calling syntax.

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

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

Doesnt seem to save any time at all.

~~~
kennywinker
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
current method role is tentative. I'll do more improvement.

~~~
grey-area
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)?

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

~~~
pjmlp
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
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.

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

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

------
floydprice
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
I love obj-c, especially after the blocks. Sorry, you guys are too late.

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

~~~
masuidrive
Yes, MobiRuby aim implement all ObjC capability.

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

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

------
iamtoby2003
would it save us from the hell of objective c?

~~~
kenver
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
what's an advantage of being too verbose? extra exercise for your fingers? ;-)

~~~
rimantas
With autocomplete you don't get much extra exercise anyway. It helps to strain
your brain less however when reading the code.

~~~
chc
I don't think "arrayByAddingObjectsFromArray:" is particularly clearer than
"concat" or "+" unless you're just totally unfamiliar with the language. In
fact, for many selectors I find the shorter names easier to read because my
brain sees them as a single token while I have to mentally parse Cocoa's
behemoths every time I run across them. There is some benefit to clarity, but
very often Objective-C's glut of information makes it harder to pick out the
details you were looking for. Smalltalk was considered quite readable and in
fact was the inspiration for Objective-C and Cocoa, but its selectors were
more minimal (for example, the equivalent to the above methods is #addAll:).

(Just to establish that I'm not _completely_ talking out my rear end: I've
been programming Objective-C for ten years, Ruby for five.)

~~~
kennywinker
oh crap, does concat create a new object, or mutate the current one? is it the
same as using + or do they handle objects differently....? should I be using
<< here maybe?

I agree with you that the verbosity of ObjC makes it harder to mentally parse
fast, but I also think there is a lot of clarity to it when you read it slow.

Where I see ObjC fall down is more in terms of command verbosity. For example
in Ruby,

    
    
        File.open("readfile.rb", "r") do |infile|
          while (line = infile.gets)
            puts "#{line}"
          end
        end
    

...would be ~150 lines of code in ObjC (Dave DeLong:
<http://stackoverflow.com/a/3711079/196358>). Which is not really a failing of
the language, actually. It's a failing of the libraries that come with the
language.

Apple chose to give you a couple ways to read a file. The easy way is
`stringWithContentsOfFile:encoding:error:error`, but the next level of control
is way to low level. Dave DeLong's solution to reading a file line by line
exposes an api that looks like this:

    
    
        DDFileReader * reader = [[DDFileReader alloc] initWithFilePath:pathToMyFile];
        [reader enumerateLinesUsingBlock:^(NSString * line, BOOL * stop) {
          NSLog(@"%@", line);
        }];
    

Not actually much more complex or verbose than the ruby.

------
Radzell
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
Totally. That is why I code my web apps in assembly. Frameworks and higher
level languages have nothing to offer.

~~~
Radzell
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.

