Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm Not Using RubyMotion in Production

joshsymonds.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: Why I'm Not Using RubyMotion in Production

#61

Post by mharju »

sjtgraham wrote: post #41
adriand wrote: post #39

Earlier quoted context omitted.

> using Xcode is a far superior experience to RubyMotion and any editor. 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.

Did you know you can have Vim keybindings in Xcode?

As it happens, ViEmu has just launched their product on XCode as well. From the couple of days in use, I'm quite pleased with it in comparison with Vicious that I used before that.

http://www.viemu.com/download-xcode.html

Re: Why I'm Not Using RubyMotion in Production

#62

Post by aufreak3 »

sjtgraham wrote: post #26

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…

This. After the addition of blocks, Grand Central Dispatch, and the booting of garbage collection in favour of ARC, ObjC is a pleasure to code in and to see it perform. As mentioned, KVC/KVO have made the UI code for my app much simpler than without them.

I'd add that one not be fooled by the apparent verbosity of the "selectors", which is the ObjC equivalent of lisp parens that hits folks new to the language. Their cognitive overhead (for me) is rather low, and they make the code readable without profuse commenting. XCode has been a pleasure as well (despite the occasional crashes), due to the live code correctness feedback (thanks to llvm/clang), auto-complete and auto-correct.

Overall, practically everything's been improving in iOS land as far as I can tell.

Re: Why I'm Not Using RubyMotion in Production

#63

Post by daemon13 »

x0x0 wrote: post #40
scribu wrote: post #25

Earlier quoted context omitted.

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

I worked for one and it works very well. They build one of the most common electronic medical record systems plus a bunch of associated software. Any large client, in this case a hospital, hospital chain, or large ambulatory clinic, pays a $mm annual fee for the right to call and notify of a breaking bug and get engineers to issue a fix asap.

>> one of the most common electronic medical record systems

Can you point to the company name? I am checking what is out there (EMRS).

Re: Why I'm Not Using RubyMotion in Production

#65

Post by cpr »

flyingbeaver wrote: post #64

RubyMotion's creator answer : https://groups.google.com/forum/#!topic/rubymotion/x6-9c__IH...

tl;dr: They had a well-known workaround for the known bug involving block variables [apparently not well-enough], so they were focusing on other things. As of right now, they're going drop everything and fix it in RM 2.4.

Re: Why I'm Not Using RubyMotion in Production

#66

Post by supervillain »

ef4 wrote: post #19

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…

That is $200, then after a year you will have to pay $100 to get updates. That was not cheap, I was hoping that I can continue recieving updates for my initial purchase, since many apps which is payed only once does that.

Re: Why I'm Not Using RubyMotion in Production

#67

Post by manojlds »

gfodor wrote: post #52
krichman wrote: post #48

Earlier quoted context omitted.

Using Xcode is a shit experience, it crashes numerous times each day, creates zombie processes when testing in the simulator, and has something like 1000 tiny problems that are irritating. LLDB is powerful, but not a proper REPL. > using Xcode is a far superior experience to RubyMotion and any editor Yesterday I had to convert a list of constants into mathematical operations. Took ten seconds to make the macro in vim…

Yeah I have to admit if they added first class vim keybindings to XCode it would have probably swayed me away from RubyMotion.

What about AppCode and the vim plugin that goes with all Jetbrains IDEs

Re: Why I'm Not Using RubyMotion in Production

#68

Post by jasonlotito »

cpr wrote: post #65
flyingbeaver wrote: post #64

RubyMotion's creator answer : https://groups.google.com/forum/#!topic/rubymotion/x6-9c__IH...

tl;dr: They had a well-known workaround for the known bug involving block variables [apparently not well-enough], so they were focusing on other things. As of right now, they're going drop everything and fix it in RM 2.4.

Every time I heard the phrase "well-known workaround" I interpret it as "tribal knowledge."

Re: Why I'm Not Using RubyMotion in Production

#69

Post by mikeash »

hboon wrote: post #46
mikeash wrote: post #37

Earlier quoted context omitted.

That's a good question. I'm not really sure, but I'm almost positive it's related to Ruby or RubyMotion internals, not ARC in general. 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); }; Because the bloc…

I just want to add that RubyMotion is also not correctly capturing the "value" of the variable in a block. i.e. even if you manually retain a local variable's object and don't release it, it wouldn't work correctly if the block runs after the local variable goes out of scope. IMO, this makes it much harder to workaround this retain bug. The workaround now is just to create a class around each block operation. I've be…

That's quite weird. I can only assume that normal Ruby has no problem with this. Wonder what changed in RubyMotion to break it. Certainly would need to be fixed before I'd call RM anything other than a toy or experiment.

Re: Why I'm Not Using RubyMotion in Production

#70

Post by GantMan »

gfodor wrote: post #53
stashpro wrote: post #24

That's a lot of fuzz for an active bug with a very easy workaround.

The fact that there is a workaround is irrelevant for two reasons. First, said workaround would completely change the entire structure of your ruby code. Basically, kill blocks. This is inferior to Objective-C itself structure-wise. Second, and most importantly, this bug is not something that jumps out at you. It only causes crashes in some small % of runs. So, the result is your apps look fine, you are writing idiom…

I think "irrelevant" is a poor choice of words here.

It is VERY relevant that there is a workaround. Additionally, it's kind of unfair to point at 1 bug (that has a workaround) and judge an entire system on it.

https://yourlogicalfallacyis.com/composition-division https://yourlogicalfallacyis.com/no-true-scotsman https://yourlogicalfallacyis.com/the-texas-sharpshooter

Post reply on HN