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

Re: Why RubyMotion Is Better Than Objective-C

#61

Post by chc » Fri, May 04, 2012, 5:09 PM UTC

bunderbunder wrote: post #51

cageface wrote: post #31

Earlier quoted context omitted.

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…

MacRuby/RubyMotion uses the same reference-counting mechanism as Objective-C, so I'm not sure how that relates.

Re: Why RubyMotion Is Better Than Objective-C

#62

Post by glenra » Fri, May 04, 2012, 5:10 PM UTC

nanijoe wrote: post #8

I would have killed for this about 2 years ago, but now that I learned Objective C, I'm comfortable enough with its quirks that I can just use it to get stuff done.. Having to learn the nuances of RubyMotion in order to do stuff I already know how to do, is probably very very low on my priority list.

Hmm, I gave up on Objective C about 2 years ago, so learning RubyMotion now is tempting. :-)

Re: Why RubyMotion Is Better Than Objective-C

#63

Post by jacaranda » Fri, May 04, 2012, 5:18 PM UTC

GuiA wrote: post #36

Seen in the article: "Why do I have to have huge statements like this? static UIColor firstColor = nil; static UIColor secondColor = nil; static UIColor thirdColor = nil; static UIColor fourthColor = nil; static UIColor fifthColor = nil; static UIColor sixthColor = nil; " Great, so someone who doesn't know how to use arrays is criticizing Objective-C as a language. To everyone claiming that Objective-C's syntax is un…

I am a fairly proficient ruby coder and I tried learning obj-c multiple times but just did not find my way around it. I wasn't thrown off by the syntax but more about the way the MVC model is built in obj-c. I was really confused by delegates and did not for some reason find obj-c intuitive. I was baffled in a few areas even with tutorials since I did not grasp some of the fundamentals. I think most people are not referring to the obj-c syntax as hard but to the overall framework. Again, I did not spend as much time/effort learning ruby/rails and felt comfortable the first week. My background is primarily Java/J2EE stuff before rails.

Re: Why RubyMotion Is Better Than Objective-C

#64

Post by ryanpetrich » Fri, May 04, 2012, 5:36 PM UTC

bunderbunder wrote: post #51

cageface wrote: post #31

Earlier quoted context omitted.

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…

It's not all rainbows and butterflies. From the RubyMotion documentation: "Object cycles, when two or more objects refer to each other, are currently not handled by the runtime, but will be in future releases."

Re: Why RubyMotion Is Better Than Objective-C

#65

Post by jad » Fri, May 04, 2012, 5:39 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…

  >> - Objective-C Is Tedious
  >
  > Matter of opinion. One person's tedium is another being explicit and reaping the
  > benefits during refactoring, code completion and compilation speed.

This is not a matter of opinion.

Objective-C:

NSDictionary *d = [NSDictionary dictionaryWithObjectsAndKeys:[NSNumber numberWithInteger:1], @"foo", [NSNumber numberWithBool:YES], @"bar", nil];

Ruby:

d = {foo: 1, bar: true}

Objective-C's "explicitness" provides no advantage to the programmer here whatsoever.

I write code all day every day in Objective-C. It is an extremely tedious language that requires large amounts of boilerplate to perform even simple tasks. (Yes, I know about the new literal syntax available in Mountain Lion, but that doesn't change the broader point.)

Your programming language is the most powerful tool in your toolbox. Ruby is clearly more powerful than Objective-C in terms of how much code one has to write to accomplish a given task.

Re: Why RubyMotion Is Better Than Objective-C

#66

Post by ryanpetrich » Fri, May 04, 2012, 5:47 PM UTC

spullara wrote: post #52

Davertron wrote: post #28

Earlier quoted context omitted.

> 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.

Text editors don't display method signatures (some IDEs do, but usually only in tooltips or autocomplete). When writing code in Java or C I often find myself looking up the method/function definition to be certain which argument is which.

Re: Why RubyMotion Is Better Than Objective-C

#67

Post by Posibyte » Fri, May 04, 2012, 5:50 PM UTC

tudorizer wrote: post #60

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…

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

A bad workman blames his tools. And, from what I read from the author, that's what he's doing. He doesn't understand trivial software patterns, such as pocketing like types into arrays (I hope everybody who took Programming 1 remembers this), and insists on doing things the Ruby way without a clear understanding of why Obj-C is actually a pretty good tool.

Re: Why RubyMotion Is Better Than Objective-C

#68

Post by mistercow » Fri, May 04, 2012, 9:08 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.

Do you mean that Ruby code tends to be simpler than Objective-C code, or that the language itself is actually simpler. Because, while I haven't done a formal comparison or anything, I would find the latter to be pretty unlikely. Most of Objective-C can really be boiled down to little more than few teaspoons of syntax sugar on top of C (although that is less true today than it once was), and C is definitely a simpler language than Ruby.

Re: Why RubyMotion Is Better Than Objective-C

#69

Post by mistercow » Fri, May 04, 2012, 9:22 PM UTC

GuiA wrote: post #36

Seen in the article: "Why do I have to have huge statements like this? static UIColor firstColor = nil; static UIColor secondColor = nil; static UIColor thirdColor = nil; static UIColor fourthColor = nil; static UIColor fifthColor = nil; static UIColor sixthColor = nil; " Great, so someone who doesn't know how to use arrays is criticizing Objective-C as a language. To everyone claiming that Objective-C's syntax is un…

>Great, so someone who doesn't know how to use arrays is criticizing Objective-C as a language.

I think the author has a valid point though, even though that example doesn't illustrate it well. He should have used variable names that didn't immediately cry out for arrayification, but there is a boilerplate problem in Objective C.

The thing is, a lot of the verbosity of Objective C is actually a win. Take the messaging syntax: beautiful and readable. And the lack of first-class syntax for almost anything? Usually pretty nice and elegant. Nothing feels magic.

But you don't get a choice about these ideals. Need optional arguments? Too bad. Use a config dictionary. And there's no literal syntax for dictionaries, so every time somebody calls your method, it's going to be a big pile of boilerplate.

I don't even think Objective-C should compromise on all of these ideals, but it should compromise on some, and I think that kind of basic functionality would have been a better point of focus than foreach loops and dot-notation.

Since they don't, people are tempted to use CPP macros to work around these shortcomings. You may remember CPP macros from every GDB nightmare you've ever had.

Re: Why RubyMotion Is Better Than Objective-C

#70

Post by trevorchill » Mon, May 07, 2012, 7:09 AM UTC

RandallBrown wrote: post #47

Yarnage wrote: post #23

>>>Don’t get me wrong, Objective-C is better than C or C++, but I don’t think that’s saying a whole lot. Objective-C better than C++? Wow, has this person ever used Objective-C and C++?

Do you really like C++ better than Objective-C? I've been writing both for the past few years and I have to say I greatly prefer Objective-C.

Yes, I much prefer C++.

There is a recurring problem in which languages outgrow their original syntax when applied to new programming paradigms.

For example, accessing an array in C uses simple syntax: arr[5] = 10;

But with NSArrays, etc., we have to add lots of explicit method calls with lots of named arguments, destroying the clear and simple syntax meant to express use of an array in C.

The nice thing about C++ is that you can fix that by overloading operators so that a vector can use the same simple syntax most of the time. You can do this for any objects for which it makes sense... And it vastly improves the ease of coding and reading code.

In objective c, you simply can't improve it. Tons of operations with containers and objects are unnecessarily syntactically unwieldy. Higher level languages like Ruby do this as well, but C++ is fast and explicit. If you want to know what the operator is doing, you can step into it. You can read the code...