Why RubyMotion Is Better Than Objective-C • Hacker News Board

Re: Why RubyMotion Is Better Than Objective-C

#51

Post by bunderbunder » Fri, May 04, 2012, 4:39 PM UTC

cageface wrote: post #31

poutine wrote: post #19

- Objective-C is Hard to Use It has a much steeper learning curve than Ruby for sure, but once you're proficient it's no harder to use. Indeed there's benefits to both languages. - Xcode is Unstable It's gone through periods of instability. But in the current version you may encounter the odd crash (perhaps once a week in full time use for me). Really not an issue given it's a cutting edge tool that's rapidly evolvin…

I have yet to write an iOS app where I didn't at least once dip down into raw C for speed and/or control. On resource constrained platforms Obj-C's ability to go from high to low in a line of code is a big competitive advantage. I don't give that up lightly. If RubyMotion offered a truly higher level abstraction over Cocoa Touch or offered cross-platform portability I might be interested but an arguably better syntax…

Score one for ObjC's use of reference counting instead of a garbage collector on iOS, too.

Now don't get me wrong, I'm normally of the opinion that anything that whiffs of manual memory management is for chumps. But by day I write apps that target workstations that have enough RAM that I can get away with pretending that memory is an unlimited resource.

On a memory-constrained platform like iOS, though, being able to tightly control how much memory you're using becomes much more valuable. If not critical. And the one place where garbage collection simply can't beat manual memory management is total memory consumed. All those dead objects that are waiting around to be scooped up by the collector do take up space. Sometimes a whole lot of it.

Re: Why RubyMotion Is Better Than Objective-C

#52

Post by spullara » Fri, May 04, 2012, 4:40 PM UTC

Davertron wrote: post #28

natesm wrote: post #20

> Why do I have to have huge statements like this? Uh, because you're declaring six static color variables. Also, they could be collapsed into one line. > Introspection is unavailable at runtime Not sure what this means. Everything is introspectable in Objective-C. #import The cell dequeueing comparison uses a one liner for Ruby and an if statement for Obj-C. That's not a fair comparison. "dequeue ?: allocate" would…

> dequeueReusableCellWithIdentifier, ugh. What is wrong with this? • I am dequeueing something from the receiver. • It is a reusable cell. • The first (and only) argument is the identifier for the cell. What would be a better name, without losing the descriptiveness? I don't think he's complaining about the name of the method, he's complaining about the fact that he has to type it all out now instead of Xcode complet…

Xcode does complete it for you. So does JetBrains AppCode. I bet RubyMine would too with RubyMotion.

IMHO, the name sucks because it includes information in the name that is also in the signature. At least it would be in languages that support overloading.

Re: Why RubyMotion Is Better Than Objective-C

#53

Post by tommy_m » Fri, May 04, 2012, 4:41 PM UTC

cageface wrote: post #44

tommy_m wrote: post #37

In my opinion lot of these threads completely miss the point of a tool like RubyMotion. It isn't about which solution is "better"...it is about ease of use for the large number of people that already know Ruby, and want to leverage that knowledge into exploring IOS development. Not everyone has the time or inclination to learn Objective-C right now, even though we can all agree that learning other languages is a good…

As many other posters have noted, learning Obj-C is about 5% of the battle. Getting to grips with the APIs is the hard part and you have to learn them whether you decide to use Obj-C, RubyMotion or MonoTouch. So if you think that Ruby is providing you with a significant shortcut here you're in for some disappointment.

I completely understand and agree with your comment re: the importance of the APIs, but I think the big win is going to be the Ruby DSLs built on top of the tool kit to make the APIs easier to use - for RubyMotion's intended audience (existing Ruby/Rails Devs). This is just the first step.....look six to twelve months out with an active developer community and think where this project could be.

Re: Why RubyMotion Is Better Than Objective-C

#54

Post by Andrew_V » Fri, May 04, 2012, 4:43 PM UTC

cageface wrote: post #44

tommy_m wrote: post #37

In my opinion lot of these threads completely miss the point of a tool like RubyMotion. It isn't about which solution is "better"...it is about ease of use for the large number of people that already know Ruby, and want to leverage that knowledge into exploring IOS development. Not everyone has the time or inclination to learn Objective-C right now, even though we can all agree that learning other languages is a good…

As many other posters have noted, learning Obj-C is about 5% of the battle. Getting to grips with the APIs is the hard part and you have to learn them whether you decide to use Obj-C, RubyMotion or MonoTouch. So if you think that Ruby is providing you with a significant shortcut here you're in for some disappointment.

actually, i have found that without the code completion rubymotion is forcing me to learn the obj-c framework and method names a bit more. i guess I could have just turned off code completion for that.

Re: Why RubyMotion Is Better Than Objective-C

#55

Post by trebor » Fri, May 04, 2012, 4:43 PM UTC

poutine wrote: post #19

- Objective-C is Hard to Use It has a much steeper learning curve than Ruby for sure, but once you're proficient it's no harder to use. Indeed there's benefits to both languages. - Xcode is Unstable It's gone through periods of instability. But in the current version you may encounter the odd crash (perhaps once a week in full time use for me). Really not an issue given it's a cutting edge tool that's rapidly evolvin…

Could you explain:

    - RubyMotion is Ruby
    That's great. Ruby is a great, easy to use and powerful language. I love Ruby. However given all the other things you sacrifice to get Ruby it's really not worth it.

What do you sacrifice to get to use Ruby? I've avoided learning to program iOS because I really dislike Obj-C. If Ruby were good enough for 60% of the apps on the App Store I'd join in a heartbeat.

Re: Why RubyMotion Is Better Than Objective-C

#56

Post by [deleted] » Fri, May 04, 2012, 4:50 PM UTC

tommy_m wrote: post #37

In my opinion lot of these threads completely miss the point of a tool like RubyMotion. It isn't about which solution is "better"...it is about ease of use for the large number of people that already know Ruby, and want to leverage that knowledge into exploring IOS development. Not everyone has the time or inclination to learn Objective-C right now, even though we can all agree that learning other languages is a good…

[deleted]

Re: Why RubyMotion Is Better Than Objective-C

#57

Post by fusiongyro » Fri, May 04, 2012, 4:54 PM UTC

cageface wrote: post #44

tommy_m wrote: post #37

In my opinion lot of these threads completely miss the point of a tool like RubyMotion. It isn't about which solution is "better"...it is about ease of use for the large number of people that already know Ruby, and want to leverage that knowledge into exploring IOS development. Not everyone has the time or inclination to learn Objective-C right now, even though we can all agree that learning other languages is a good…

As many other posters have noted, learning Obj-C is about 5% of the battle. Getting to grips with the APIs is the hard part and you have to learn them whether you decide to use Obj-C, RubyMotion or MonoTouch. So if you think that Ruby is providing you with a significant shortcut here you're in for some disappointment.

On top of this, when Apple releases new frameworks, the Obj-C users get to use them immediately. People using weird bridges are giving their competition a huge time boost by voluntarily delaying their own access to the new stuff.

I worked for a company doing Mac apps in REALbasic for several years, and this was a constant hassle. Additionally, RB chose the wrong backend for their compiler (Carbon instead of Cocoa) and there were multiple years of setbacks due to Apple hemming and hawing about whether they were going to deprecate Carbon altogether and RB porting their entire framework to Cocoa. During that process, everybody who emigrated to Objective-C got their stuff to market sooner, and with access to newer libraries to boot.

Re: Why RubyMotion Is Better Than Objective-C

#58

Post by poutine » Fri, May 04, 2012, 4:57 PM UTC

trebor wrote: post #55

poutine wrote: post #19

- Objective-C is Hard to Use It has a much steeper learning curve than Ruby for sure, but once you're proficient it's no harder to use. Indeed there's benefits to both languages. - Xcode is Unstable It's gone through periods of instability. But in the current version you may encounter the odd crash (perhaps once a week in full time use for me). Really not an issue given it's a cutting edge tool that's rapidly evolvin…

Could you explain: - RubyMotion is Ruby That's great. Ruby is a great, easy to use and powerful language. I love Ruby. However given all the other things you sacrifice to get Ruby it's really not worth it. What do you sacrifice to get to use Ruby? I've avoided learning to program iOS because I really dislike Obj-C. If Ruby were good enough for 60% of the apps on the App Store I'd join in a heartbeat.

- No Interface builder. Really a big loss given the power of Storyboards/segues, layout of objects, complex flows.

- No syntax/error checking as you type

- No static analyzer

- No code completion (perhaps you could find a 3rd party module to do this eventually)

- No refactoring support (very important in larger projects)

- Probably longer compilations (in Xcode/ObjC the compiler will know which files are modified by looking at the included headers and only recompile what is needed, in Ruby I would expect it's gotta do them all but could be wrong).

Re: Why RubyMotion Is Better Than Objective-C

#59

Post by Derbasti » Fri, May 04, 2012, 4:58 PM UTC

stcredzero wrote: post #49

Derbasti wrote: post #17

Earlier quoted context omitted.

Exactly. C++ is simply way more complicated than Obj-C. Also, the Obj-C object system is pretty high level and dynamic (message passing, late binding, dynamic dispatch). This makes it somewhat slower at method calling, but at the same time a lot easier to work with. The downside of being slow is usually mitigated by simply being able to drop back to plain old C if need be. Of course, C++ can emulate all that, and wit…

C++ is simply way more complicated than Obj-C. Also, Obj-C is somewhat more complicated than Ruby, though there is a lot of Ruby if you go looking. Obj-C is also more syntactically noisy than Ruby.

having dabbled in a bit of Ruby metaprogramming, I can't say that it is particularly simple. Still, simple Ruby is simpler than simple Obj-C and certainly simpler than simple C++ (if indeed there is such a thing as simple C++).

Re: Why RubyMotion Is Better Than Objective-C

#60

Post by tudorizer » Fri, May 04, 2012, 4:59 PM UTC

Here we go again. Another "Obj-C killer". "Ooh, that ugly obj-c is so unproductive!".

Currently I'm mainting a couple of medium to big obj-c projects and one big ROR custom CMS. My background was mostly in Python. A few years ago this sharade of writing faster obj-c app started. You guys might have heard of Wax (in Lua) which seemed to have a similar concept to RubyMobtion (of course, w/o the shiny presentation style that comes with the ROR community). After rolling my sleeves and digging into Obj-C (and CocoaTouch), all other alternatives look like made for people who are comfy/lazy and stick to writing in high-level scripting languages. If they admit their status, no problem, just that personally I would not bet medium-to-big project on anything else except plain obj-c.

The "RubyMotion Makes Debugging Easy" is the silliest part. Good luck on using GDB/LLDB!

Note: sharade and other casual language was in no intent meant to discredit the hard work put in by the developers of such tools. Full respect for the gents behind RubyMotion. They are building a fair business.

All and all, stop whining and get to know both sides.