Hacker News Reader

Comment by holyjaw | Hacker News Reader

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)

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

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

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

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"

Reply on news.ycombinator.com