Live data from Hacker News

RubyMotion - Ruby for iOS

rubymotion.com

61–70 of 250 posts

Re: RubyMotion - Ruby for iOS

#61

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…

totally agree with you. just for your statement "I really want to try it out. Especially since I know Ruby (and C) but I don't know any Obj-C.": Would be interesting to really know what is the steeper/longer part of the learning curve: learning ObjC or learning the frameworks. To me, ObjC is a lean language (with an awful bracket syntax just like lisp) but learning the ins and outs of the frameworks is what took me t…

Yep - In times when ARC was not invented, memory management took some time to get used to (what with object ownership and such), but you can strike this from the list now. Another thing is that one has to get used to the ObjC way of doing stuff. E.g., Devs who are used to Java will make subclasses instead of categories, add comments instead of expressive method names, and make nil checks where they are not necessary. Or ask where all those open-source projects' unit tests have gone :)

Re: RubyMotion - Ruby for iOS

#62
post #12

I could see this really taking off. My worry is that it would take off so well that the ruby gem community could get fragmented into libraries for RubyMotion and libraries for regular ruby projects.

There are already exclusive libraries for MRI/JRuby, so adding a third platform doesn't seem like it would break the world. Tools like Bundler do a great job of keeping things moving smoothly.

Didn't realize bundler kept track of what ruby you were using.

Re: RubyMotion - Ruby for iOS

#63

How does memory management work with ruby and iOS? I did not find the information on the website.

From the Features: "It's Ruby, you don't need to think about managing memory. Ever. RubyMotion will by itself release the objects you create when they are no longer needed. Our memory model, similar to Objective-C ARC in design, does not require any extra memory or processor footprint to allocate and reclaim unused objects."

I still wonder how they did that. The classic problem with reference counting is correctly releasing cycles, which ARC handles by allowing "weak" references. How does MacRuby know when to insert a weak reference as opposed to the usual "strong" reference? If that could be automatically detected, why does Obj-C ARC not automatically do it for you?

Re: RubyMotion - Ruby for iOS

#64

Part of me is happy. Apple pushed MacRuby before Lion and effectively killed it internally going forward after the ARC announcement. MacRuby relies on the GC capability of Objective-C which is incompatible with their new ARC baby. Just a few days ago I wanted to take a backend framework we wrote and build a command line tool to call some of it's methods in MacRuby (lots of command line parsing and Ruby has good facil…

It doesn't sound like they're using ObjC garbage collection, which I do not think would be available in iOS anyway:

"Our memory model, similar to Objective-C ARC in design, does not require any extra memory or processor footprint to allocate and reclaim unused objects"

Re: RubyMotion - Ruby for iOS

#65

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…

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 that any easier. It's simply a massive amount of information to take in all at once.

Re: RubyMotion - Ruby for iOS

#66
post #25
post #11

Earlier quoted context omitted.

I agree, but many young developers have C phobia and somehow seem not to be able to grasp C based languages.

Or they've been spoiled by certain language features and it seems unbearable to go backwards.

What language features does Ruby have that Objective-C lacks? It's a bit more succinct, perhaps, but when you're calling out to Cocoa all the time, that succinctness is going to get thrown out the window.

Re: RubyMotion - Ruby for iOS

#67
Problem in search for a solution? Apple is walled garden - provides the best integrated IDE for iphone development that is a pleasure to use. Language is just a small part of the puzzle. For each task, the best suited environment and language. There is no panacea.

Re: RubyMotion - Ruby for iOS

#70

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 of UIKit through Ruby will provide interesting insights that will later be used to make Objective-C better: all the Objective-C 2.0 additions (including the ones you mention) were certainly a response to modern languages that made a lot of things easier for programmers.

As an Objective-C programmer myself, I was initially really turned off by this attitude from the JavaScript community: (Why do we need we need a LISP implementation in JS? It's already a functional language! Why do we need Objective-J? JS already kind of has classes!). Hilariously enough, the only language that was "accepted" by the JS community was the one that specifically promised that it wouldn't add any new features: CoffeeScript. I missed the Objective-C community precisely because I had always found it quite unreligious and practical: to each his own when it comes to development -- I hope that with its latest success it hasn't become more dogmatic and insular.

Post reply on HN