Live data from Hacker News

Build iOS Apps In Ruby - Available Summer '12

mobiruby.org

31–40 of 54 posts

Re: Build iOS Apps In Ruby - Available Summer '12

#31

Earlier quoted context omitted.

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.

Re: Build iOS Apps In Ruby - Available Summer '12

#33
post #31

Earlier quoted context omitted.

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.

Re: Build iOS Apps In Ruby - Available Summer '12

#34

Earlier quoted context omitted.

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 ma…

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.

Re: Build iOS Apps In Ruby - Available Summer '12

#35

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

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.

Re: Build iOS Apps In Ruby - Available Summer '12

#36

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

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.

Re: Build iOS Apps In Ruby - Available Summer '12

#37
post #18

Earlier quoted context omitted.

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

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

Re: Build iOS Apps In Ruby - Available Summer '12

#38
post #36

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

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.

Re: Build iOS Apps In Ruby - Available Summer '12

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

Re: Build iOS Apps In Ruby - Available Summer '12

#40

Earlier quoted context omitted.

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]; [pe…

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

ignore the internet, masui, and do whatever you think is best >:3
Post reply on HN