3 ms·
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 g
by cageface 15y ago
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 over the same API just isn't enough of a win.
- bunderbunder 15y agoScore 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.
- chc 15y agoMacRuby/RubyMotion uses the same reference-counting mechanism as Objective-C, so I'm not sure how that relates.
- ryanpetrich 15y agoIt'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."