Live data from Hacker News

Rubymotion – Myth, Magic, or The Future?

bostonrb.org

11–20 of 24 posts

Re: Rubymotion – Myth, Magic, or The Future?

#11

I think one of the most interesting points about the presentation is the BubbleWrap libraries. The greatest pain I've felt with iOS development are some of the terrible APIs. The amount of ceremony needed to Parse JSON from a web based API request or to access the camera is almost absurd.

Well, here are two short snippets on how to do that. It is incredibly easy. (Sorry, I couldn't find a better paste it host.)

http://paste.org/53022

Re: Rubymotion – Myth, Magic, or The Future?

#12
post #8

I refuse to hammer this nail with a hammer. I will use a screwdriver. I will go through great difficulties if need be, so that I can keep on using a screwdriver.

Are you saying use the right tool for the problem, or that there is only one tool per problem?

If you are saying the former, I agree entirely. If you are claiming the secondary, than I have to ask what do you think the purpose of a language like Lua is? Why do programmers like using Lua in combination with their c/c++ projects?

Re: Rubymotion – Myth, Magic, or The Future?

#13
post #6
post #3

Oddly, I didn't run away from Objective-C and Xcode screaming. But I have run screaming away from Ruby on Rails a number of times. I do acknowledge that this is likely a personal shortcoming though.

Ruby is cool. REPLs are cool. Objective-C is slightly weird. Interface builder is kind of nice. XCode is weird, but has some fairly great features for Objective-C/Cocoa. But Cocoa is the thing you have to learn no matter what. To be honest, all things considered I would rather put up with Objective-C than lose Interface Builder and the niceties of XCode. And I say that even though I have used and love PyQt. Cocoa is…

You don't strictly have to lose interface builder to use RubyMotion, you can use XIBs with Motion, but [for now] addressing elements in the XIB requires a little bit of ugly manual mapping of the numerical XIB element ids to names you want to give them in Motion.

Disclaimer: I've not built anything extensive with Rubymotion/IB, but I have built a proof of concept. I don't know if it's really feasible on a large project.

Also, Obj-C and Ruby share many common concepts, using Cocoa from RubyMotion usually requires just a bit of syntax swapping, "vanilla" RubyMotion is not much of an abstraction.

Re: Rubymotion – Myth, Magic, or The Future?

#14
post #11

I think one of the most interesting points about the presentation is the BubbleWrap libraries. The greatest pain I've felt with iOS development are some of the terrible APIs. The amount of ceremony needed to Parse JSON from a web based API request or to access the camera is almost absurd.

Well, here are two short snippets on how to do that. It is incredibly easy. (Sorry, I couldn't find a better paste it host.) http://paste.org/53022

Alternately, here's BubbleWrap on camera: https://github.com/rubymotion/BubbleWrap#camera

on JSON: https://github.com/rubymotion/BubbleWrap#json

Re: Rubymotion – Myth, Magic, or The Future?

#15
post #11

I think one of the most interesting points about the presentation is the BubbleWrap libraries. The greatest pain I've felt with iOS development are some of the terrible APIs. The amount of ceremony needed to Parse JSON from a web based API request or to access the camera is almost absurd.

Well, here are two short snippets on how to do that. It is incredibly easy. (Sorry, I couldn't find a better paste it host.) http://paste.org/53022

[deleted]

Re: Rubymotion – Myth, Magic, or The Future?

#16
post #2

I don't hate objective c / XCode nearly enough to pursue a solution like this even though I like and appreciate ruby. In my opinion the only way this would be the future is if apple started providing support for it.

Totally agree. That said, Rubymotion is pretty sweet as when I play around with it, I'm just reminded of why I love Ruby in general. I like Obj-c too, but I love Ruby.

Re: Rubymotion – Myth, Magic, or The Future?

#17
This actually tracks w/ my experiences using MacRuby.

The REPL is kind of cool, but then he doesn't remember how to set the label text. There's no statement completion or help for him in the console, so he gives up. He's stuck. He'll spend way more time reading docs and figuring out Cocoa method sigs than just learning the XCode toolset and discovering methods in the editor.

That said, overall it's a good talk and I applaud his efforts at explaining the tool - I just think it's not clear RubyMotion is a net positive in terms of productivity.

Re: Rubymotion – Myth, Magic, or The Future?

#18
post #2

I don't hate objective c / XCode nearly enough to pursue a solution like this even though I like and appreciate ruby. In my opinion the only way this would be the future is if apple started providing support for it.

I agree also. I primarily work in Ruby but was pleasantly surprised with the updates for iOS 5. ARC support and the addition of storyboards really helped with the parts I disliked working with.

The only issue is that I would prefer to work with another editor. XCode just doesn't have some of the editor features I am used to with other IDEs.

Re: Rubymotion – Myth, Magic, or The Future?

#19
post #5

This fear of learning a new tool, language or API boggles my mind. The insight alone from seeing a new corner of the programming world is worth biting the bullet and learning something new.

I think your comment is great, and equally applies to experienced Objective-C developers who could miss something interesting here :)
Post reply on HN