Build iOS Apps In Ruby - Available Summer '12 | Hacker News Reader

Build iOS Apps In Ruby - Available Summer '12

mobiruby.org

89 pointsteeray52 comments

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

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

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.

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.

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?

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.

Thank you very much for this clarification.

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.

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.

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

So, 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];
    [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)

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

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"

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

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

ignore the internet, masui, and do whatever you think is best >:3

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.

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.

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.

PyPy?

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

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

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 ;-)

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

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

Yes, MobiRuby aim implement all ObjC capability.

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

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

would it save us from the hell of objective c?

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.

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

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

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

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.

it has big advantages in terms of readability and is necessary for self-documenting code

You can always make use of APL if you don't like typing.

You could always make use of enterprise Java if you like verbosity.

The extremes are probably not the place to be.

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.

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.

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

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.

Reply on news.ycombinator.com