Live data from Hacker News

RubyMotion - Ruby for iOS

rubymotion.com

71–80 of 250 posts

Re: RubyMotion - Ruby for iOS

#71
post #16

missing trial period so i'd rather wait for mobiruby

The difference is that, as far as I can see, mobiruby is a Ruby interpreter/VM embedded in an Obj-C application. This is in contrast to MacRuby which is implemented directly on top of the Obj-C runtime. So, MobiRuby still has to go through the work of converting Ruby objects into Obj-C objects, whereas in MacRuby a Ruby object is an Obj-C object.

For a practical example of what this means, see the most recent sample code that was released for mobiruby: https://gist.github.com/2577620

Re: RubyMotion - Ruby for iOS

#72
post #69

"At the end, a RubyMotion app looks pretty much the same as an Objective-C app." ( from bottom of: http://www.rubymotion.com/features/ ). pretty much the same as an Objective-C app? Anyone have any clue as to why they didn't state apps in the two languages would look identical?

Different compilers will generate different compiled code, even on identical input (ie, clang vs. GCC). So the binary will be different.

Re: RubyMotion - Ruby for iOS

#73

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actually become pleasant to write IMO. The example RubyMotion code also doesn't look very nice either. The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the be…

Objective-C's heritage as a strict superset of C means that it's great for doing high-level stuff while still keeping your hands in the low-level (necessary when performance becomes a main concern).

Objective-C's heritage as a strict superset of C means that, ultimately, it's syntax is limited (why do you think all the new literal forms are prefixed with "@"). Ruby, on the other hand, excelles at constructing DSLs.

I think you'll find that this strength of Ruby will make RubyMotion a compelling solution for a wide range of tasks in iOS development. That said, CocoaPod support is built in, so you really can have the best of both worlds.

Re: RubyMotion - Ruby for iOS

#74
post #69

"At the end, a RubyMotion app looks pretty much the same as an Objective-C app." ( from bottom of: http://www.rubymotion.com/features/ ). pretty much the same as an Objective-C app? Anyone have any clue as to why they didn't state apps in the two languages would look identical?

Different compilers will generate different compiled code, even on identical input (ie, clang vs. GCC). So the binary will be different.

I think he's commenting on why they wouldn't LOOK identical, as in UI.

UI is a finicky thing, but assuming this allows you to use all Apple APIs, there is no reason you couldn't get an identical-looking UI using this.

Re: RubyMotion - Ruby for iOS

#75

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actually become pleasant to write IMO. The example RubyMotion code also doesn't look very nice either. The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the be…

I already know both languages — in fact, I've known Objective-C for 10 years and Ruby for only six — and I still see some reasons why this is interesting.

Anecdote: When ARC was first released, I decided to turn it on for a small project. The very first method I wrote blew up with a memory error. The reason? I used the NSFontMatrixAttribute of NSFontDescriptor. For some reason, ARC doesn't handle it correctly. I've never had such a thing happen in Ruby.

There is still a long way to go from where Objective-C is. It's moving in the right direction, but there's still a long road ahead of it. Ruby is closer to being there, though the lack of tool support (particularly autocomplete) makes it a much less compelling proposition than it would otherwise be.

Also, Ruby can be considerably easier than Objective-C to read because there is a lot less line noise. Objective-C's method names read very smoothly out loud, but they can also be visually overwhelming at times and make code sort of melt together into a wall of text. It's maybe a little bit easier to read Objective-C quickly when you're being very deliberate about it, but it's much easier to skim Ruby in my experience.

I probably won't be using this, and I think your criticism of Rubyists is kind of valid, but I think — for this particular project — you're dismissing it too readily.

Re: RubyMotion - Ruby for iOS

#76

Earlier quoted context omitted.

In reference to your first paragraph, that's all your opinion. You are completely entitled to it and I respect it. My opinion is that this looks awesome and I really want to try it out. Especially since I know Ruby (and C) but I don't know any Obj-C. As for your second paragraph, you can say that about any '-ists'. I've met java, python and .Net people who all love their respective languages and just want to code in…

Especially since I know Ruby (and C) but I don't know any Obj-C. Interestingly, from my point of view, Obj-C made perfect sense to me when I realized that it was basically Ruby with C syntax. Given the heritage of Ruby and Obj-C, they come out as very similar languages, so I found it a breeze to pick up the other. The hard part was learning the Cocoa (Touch) frameworks, but I'm not sure a Ruby API would have made tha…

I think you'll find the difference between working with Cocoa APIs in Obj-C vs Ruby is that it's much easier in Ruby to turn what you've learned into a simple, boiled-down, easier to digest set of helper methods/objects/modules.

For example, in using the RubyMotion beta, after I understood the UIView animation flow, I created a helper method using "yield" to do the actual animation. If I were working in Obj-C, it would've been a lot more work to do the equivalent (and I probably would've just copy-pasted existing code around instead).

Re: RubyMotion - Ruby for iOS

#77

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actually become pleasant to write IMO. The example RubyMotion code also doesn't look very nice either. The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the be…

I've never understood this logic: The existence of this project is not an attack on Objective-C. Objective-C is not hard to learn and awesome, I agree. But what does that have to do with providing an alternative? There can exist multiple good solutions to one problem. You said it yourself: Ruby is not always the best tool for the job, perhaps Objective-C is also not always the best tool for the job. Perhaps the use o…

I am personally concerned that the Rubyists will flood the iOS development space, bringing their culture and introducing a dogmatic and insular environment.

We already have -- and without great fanfare -- Lua, JavaScript, C# (MonoTouch), et al. This seems somehow different.

Re: RubyMotion - Ruby for iOS

#78

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actually become pleasant to write IMO. The example RubyMotion code also doesn't look very nice either. The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the be…

I agree, language itself is not a problem. It is iOS API that matters (or needs to be fixed, in context of this thread).

Actually, I can say the same regarding Java/Android API correlation.

Re: RubyMotion - Ruby for iOS

#79
post #7

Earlier quoted context omitted.

Having been part of the private beta I can tell you that it's a huge time saver. Objective-C is nice be ruby is much more expressive, you can use the same API with much less code, you can skip XCode altogether and use your favorite editor, ... I can't express properly how awesome it is, really.

In the Ars article, I noticed the author mentions you can't use XCode's layout tools. In practice, how big a problem is that?

I quite like Interface Builder, and this sounds like a bit of a deal-breaker for me. I'd rather not have my controllers cluttered with UI-positioning code, etc. It's a much more elegant way to create you UI (most of the time).

I bet they are working on it, though...

Re: RubyMotion - Ruby for iOS

#80

Earlier quoted context omitted.

In the Ars article, I noticed the author mentions you can't use XCode's layout tools. In practice, how big a problem is that?

Some people hate interface builder and don't use it at all. I really like it and would have a really hard time getting rid of it. The amount of code you would need to write to make all of your views would be terrible. I would liken it to not using HTML when you're making a web app and you can only use javascript to generate (by hand) all of the UI.

Except that I feel the control you lost by using IB is smaller compared to the control you lose by using an HTML builder. But then again, it's been forever since I last used an HTML builder.

In both cases, there are border cases that need to be handled in code (or markup).

Post reply on HN