31–40 of 75 posts
I've been using Ruby for some years now, and let me tell you something: just learn Obj-C. It's not hard to learn, is actually a pleasure to write, and will surprise you with it's elegance sometimes, e.g. KVC collection operators ( http://nshipster.com/kvc-collection-operators/ ). RubyMotion would have been awesome a few years ago, but now that Obj-C has ARC, literals for dictionaries and arrays, and blocks (yes!), I…
I've been using Ruby for some years now, and let me tell you something: just learn Obj-C. It's not hard to learn, is actually a pleasure to write, and will surprise you with it's elegance sometimes, e.g. KVC collection operators ( http://nshipster.com/kvc-collection-operators/ ). RubyMotion would have been awesome a few years ago, but now that Obj-C has ARC, literals for dictionaries and arrays, and blocks (yes!), I…
- you can use the editor of your choice and the terminal instead of Xcode
- you can use the interactive console to debug your app or to live test new code
- you get all the great wrapper gems like BubbleWrap which are heavily influenced by the "rails way" of doing things
Am I the only one who thinks that ARC in a language like Ruby is probably impossible? Even with Objective C they had to add 4 new variable qualifiers, and put that burden on the programmer to use them properly.
ARC in a language like ruby is trivial. ARC is probably the first kind of garbage collection ever implemented. It's only complicated in Objective-C because of all the C.
(Looking at your web site, seems like you would have a good understanding of the underlying issues.)
Ruby Motion is supposed to make iOS and Mac OS X app development simpler than Objective C. If there are lots of complex rules and corner cases to learn about and work around, it becomes easier to just write Objective C, where at least the rules about memory are well understood by the community.
Will be interesting to see how HipByte addresses this. They at least need to get in front of the issue with a blog entry or article about how they plan to address it.
I've been using Ruby for some years now, and let me tell you something: just learn Obj-C. It's not hard to learn, is actually a pleasure to write, and will surprise you with it's elegance sometimes, e.g. KVC collection operators ( http://nshipster.com/kvc-collection-operators/ ). RubyMotion would have been awesome a few years ago, but now that Obj-C has ARC, literals for dictionaries and arrays, and blocks (yes!), I…
I agree, Obj-C has improved a lot. But it's not just Obj-C vs. Ruby: - you can use the editor of your choice and the terminal instead of Xcode - you can use the interactive console to debug your app or to live test new code - you get all the great wrapper gems like BubbleWrap which are heavily influenced by the "rails way" of doing things
Because:
> you can use the editor of your choice and the terminal instead of Xcode.
This is possible with Obj-C, but using Xcode is a far superior experience to RubyMotion and any editor.
> you can use the interactive console to debug your app or to live test new code
Ditto for lldb in Xcode
> you get all the great wrapper gems like BubbleWrap which are heavily influenced by the "rails way" of doing things
There are plenty of powerful 3rd party Obj-C abstractions too.
Earlier quoted context omitted.
I didn't see a workaround, can you elaborate?
Read the paragraph that starts with the sentence, "Of course, there's a workaround."
Earlier quoted context omitted.
ARC in a language like ruby is trivial. ARC is probably the first kind of garbage collection ever implemented. It's only complicated in Objective-C because of all the C.
Do you have any thoughts, then, on why Laurent is having such a hard time fixing this in Ruby Motion? (Looking at your web site, seems like you would have a good understanding of the underlying issues.)
As best I can tell from the article and the filed bug, it comes down to not retaining captured variables in blocks. In Objective-C, there's some automatic memory management that happens for you when you capture a variable in a block:
id x = ...;
^{ NSLog(@"%@", x); };
Note that, while definitely "automatic reference counting", this isn't, strictly speaking, ARC. Because this is so critical to being able to use blocks without going completely insane, this bit of cleverness was introduced with blocks on 10.6, even though ARC didn't exist yet.
The note in the bug says that it's complicated because they don't want to introduce a performance regression. This suggests that they're not having trouble with retaining objects referenced by the block per se, but rather with being smart about it, so that it's only retained when necessary. The Objective-C compiler does this by constructing blocks on the stack, and requiring an explicit copy to move them to the heap. Only when explicitly copied do they retain the variables they capture, so simple inline cases remain fast. Perhaps Ruby or RubyMotion have something that makes this harder to do.
If that's correct, then I can't say I find the excuse a very good one. Performance regressions are bad, but generating incorrect code is much worse. They need to fix it immediately, take the speed hit, then see about ways to improve performance while maintaining correctness. However, I certainly could be wrong.
Earlier quoted context omitted.
I agree, Obj-C has improved a lot. But it's not just Obj-C vs. Ruby: - you can use the editor of your choice and the terminal instead of Xcode - you can use the interactive console to debug your app or to live test new code - you get all the great wrapper gems like BubbleWrap which are heavily influenced by the "rails way" of doing things
Do you know these to be facts or are you just regurgitating something you've read or heard elsewhere? Because: > you can use the editor of your choice and the terminal instead of Xcode. This is possible with Obj-C, but using Xcode is a far superior experience to RubyMotion and any editor. > you can use the interactive console to debug your app or to live test new code Ditto for lldb in Xcode > you get all the great w…
XCode is not ideal for people accustomed to, say, vim. I love the static code analysis and the autocomplete and storyboards are pretty cool too. But having to edit text like a normal human instead of using vim sucks and the split pane handling is garbage. I would rather do all my dev in vim.
I'm happy that the RubyMotion guys can charge money for what they're doing. But if you're going to stay closed source, you're asking me to just trust you that important (to me) bugs are going to get fixed fast enough. That is very hard to do. That is the real value of open source. It's not about the money -- an extra $200 is nothing in a development budget. It's about being able to fix the bugs myself when they matte…
... or at least hire someone to fix the bugs for you. I wonder if there are any closed-source software shops that have a "pays us a premium to fix bug X first" option. Doesn't seem like it would work too well.