Live data from Hacker News

RubyMotion - Ruby for iOS

rubymotion.com

191–200 of 250 posts

Re: RubyMotion - Ruby for iOS

#191
post #171

Earlier quoted context omitted.

Apparently the disconnect here comes because you think of a language as trivial (as compared to an API), however it's often hard to separate the language (syntax, and its built in methods), and the libraries which make up an API/standard library. In addition to the cost of learning a library/language, there is also a day to day cost in using it - a certain friction which encourages you to take some paths and not othe…

I don't understand how this relates to anything I've said. How is this meant to show that the time it would take to learn Objective-C while you're learning Cocoa is prohibitive? Actually, I think your code examples support my point. You're not contrasting Ruby and Objective-C, you're contrasting Ruby's standard library with the Objective-C library Foundation, which is what you need to learn to get any real use out of…

Are normal ruby regex expressions not available in macruby/Rubymotion? If so, why would you bother to use the above code using cocoa regex when the idiomatic ruby version is so much shorter and simpler?

The example was supposed to illustrate that some things are easier and more concise in ruby, and thus also presumably in something like Rubymotion. The relevance to your posts is that you are ignoring some very good reasons to use ruby in your focus on the cocoa api - not all programming in ios consists of calls to the api so learning it is not the only thing required to make an iPhone app. In some apps api calls might make up half of the code, with the rest being back-end stuff. Evidently Rubymotion does not mean you can avoid learning the api, it just helps you write the rest of your code in a preferred language while painlessly calling the apis to show stuff on the screen. Not having to deal with Xcode would be a bonus too.

Re: RubyMotion - Ruby for iOS

#192
post #57

A suggestion for Laurent Sansonetti will be to release this similarly with the way Xamarin has released Mono for iOS. Basically you should be able to download and use the library for free in the iPhone/iPad simulator and you will need to buy a license if you want to be able to export the app to the actual device. This licensing model has the advantage that is similar with what Apple does for developing apps for iOS.…

2nd this, that would be awesome. I am very tempted to give Rubymotion a try, but not sure I am ready at the moment to shell out the cash for it.

Re: RubyMotion - Ruby for iOS

#193
post #104
post #95

No interface builder? Depending on what type of apps you make it can be a big issue I think

The problem with interface builder is that it only exposes some properties and others you have to set in your class anyway. Why can't I set the background image of a view in interface builder, for instance? With RubyMotion you get to roughly lay out your controls, and then you get to use the interactive interpreter for fine-grained adjustments. See around the 5:30 mark in the getting started video for an example.

[deleted]

Re: RubyMotion - Ruby for iOS

#194

I love writing Ruby code, but today I'm finally at a point where I also feel happy and productive with Objective-C. What made my eyes bulge is this: http://www.rubymotion.com/developer-center/guides/project-ma... No XCode. Instead of obscure and impenetrable project files, a convention over configuration Rakefile. Clean and Ruby-like workflows and repositories. While you can certainly configure an Xcode workspace to…

Which makes me wonder.. is it possible to rig up such an environment for standard Objective C iOS app development? It could be huge.

Do Makefiles count? Xcode project are largely (not so) shiny wrappers around Makefiles and keeping track of files.

Re: RubyMotion - Ruby for iOS

#195
post #169

Earlier quoted context omitted.

I can only assume you didn't read up on the technology at all. RubyMotion does not use a Ruby VM, instead it's a static compilation to machine code. So any previous Ruby performance benchmarks are invalid in this instance. Also, Objective-C is not the slow bit in the example you described. There is a lot of logic overhead in laying out views in Cocoa. While it's true Objective-C (the language) may have some overhead,…

It's true, I didn't read up on the tech at all. That was just my initial reaction. If it's fast, great! I'd love to see some performance benchmarks. As for Objective-C, whether the language in and of itself is the source of the slowness I was talking about is somewhat beside the point, IMHO. I'm aware that laying out views in Cocoa involves a lot of overhead, and that it's as much to do with the complexity of what's…

The fact of the matter remains though that you take a performance hit when laying out non-trivial views that need to be updated as fast as possible (e.g. when a table view scrolls by even one pixel and all the views have to be redrawn).

Not true, on a bunch of different levels.

A. Go do a benchmark with a nib loaded with UINib, and then with your "non-trivial view". The difference is negligible. You won't get more than 1-2 fps more by keeping it in code. And honestly? If you're that desperate for 1-2 fps, you're not likely bottlenecked at drawing code.

B. If you scroll by one pixel, at most, you'll have one new cell to redraw: the one that appeared on screen at the end. You don't redraw everything all the time.

C. I find that custom code is usually slower than loading some images and placing them on screen. CoreGraphics functions, for example, don't use the GPU. Set the wrong property on your layer (try touching CALayer's shadow properties on a large scrollview)? You lose ~20FPS. GPU is too busy calculating stuff to actually put stuff on screen, so CA drops frame.

Re: RubyMotion - Ruby for iOS

#196

I love this. It looks like exactly what I've been looking for since the iPhone SDK was first announced. I've been a web/RoR developer since high school but could never find the motivation to get used to all of Objective C/XCode's quirks. I've tried everything from PhoneGap to Appcelerator to mimicking native feel in a browser, but it was never enough. This is perfect. But quite frankly, I can't afford it. I'm a colle…

But you could justify spending 4 weeks food on an experiment? Because you'll need that $100 to put an app on your device, as well.

Re: RubyMotion - Ruby for iOS

#197
post #77

Earlier quoted context omitted.

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.

Many Mac devs who attended WWDC before the iPhone shipped say the same thing now about iOS developers…

Re: RubyMotion - Ruby for iOS

#198
post #190
post #53

Earlier quoted context omitted.

> Rubyists in general want to use Ruby for everything. Well… why not? This is a relatively objective statement; the problem with ruby tends to be the crappy interpreter we're forced to suffer through - not the language itself. The Ruby language, in my biased opinion, as far as OO-functional languages go is pure awesome. My initial reaction was: "A Ruby to Obj-C ABI compiler? Fuck no, what is wrong with you." Upon lea…

I like ruby but please, do not call it a functional language. Its not even remotely close.

Why not? Sure, neither ruby nor python emphasise immutability, and recursion isn't optimised, but both lend themselves to a functional style if you're so inclined. See http://stackoverflow.com/questions/159797/is-ruby-a-function...

Re: RubyMotion - Ruby for iOS

#199

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…

It might not be the best but it's good enough. Most of the heavy lifting GUI code is still in Obj-C, it's just going to be hitting ruby for microseconds.

Sure if you're writing the unreal engine it's not going to be the best idea, but it should do fine for a Facebook/Three20 type app.

Re: RubyMotion - Ruby for iOS

#200

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…

The point is that compared to Ruby, Objective-C is just aging, bloated, and incomprehensibly loaded with special traps designed to keep you wedded to the platform.

Ruby skills: applicable across a very broad range of computing devices. Objective-C: not so much.

Post reply on HN