Anyone else becoming disillusioned with rubymotion?

[Kevin Fagan]

I've been a big advocate of rubymotion for the past two years, I've written gems for the ecosystem and I've given talks at my local ruby and iOS meetups, but lately I'm becoming increasingly frustrated with the state of the toolset.

I've run into more bug than ever over the past couple of months. Stuff that used to work is broken with new releases. Support for iOS features first unveiled back in the summer by Apple is still not there.

I used to feel super productive in the past but now find that time saved from the productivity bump is withered away waiting on RM to catch up with implementing platform features or fixing bugs that I need fixed before I can ship an app.

I understand the team are tackling some really big problems, adding Android support while implementing the new developer features available with iOS 8 is a huge feat but as a result I think the team is spreading itself way too thin.

I know you can halt the march of progress but I yearn for the good old days when the focus was one one platform and each release brought with it great new tools and more stability than the last.

[Caram Dache]

I haven’t run into the same kind of issues, but one key issue for me is the current state of debugging and it’s hitting me everyday and whenever I switch back to Xcode for a moment I can’t help but feel how happy Xcode developers are (on that aspect at least). Alas, I am using mostly printf. Setting breakpoints manually and typing pro is not really efficient for a substantial, multi-threaded app.

Have I been missing something? Is there anything in the works?

If there was a key feature to be implemented next in RM, I would nominate debugging by far above anything else.

Caram

 Stack traces are often missing line numbers

--
You received this message because you are subscribed to the Google Groups "RubyMotion - Ruby for iOS, OS X, and Android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubymotion+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubymotion/4e64fa50-5de5-4f3d-aae0-ba91dab059bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin T.A. Gray]

Sorry to hear you feel that way, Kevin.  I'm in the opposite camp right now, I've recently had a string of Objective-C projects that have demanded I dust off the ol' Xcode.

It's been a reminder to me of what I was happy to leave behind: a bloated and flaky GUI (combined with a terrible editor, though I stick to sublime, so 99% of the time I don't deal with that) and a clunky, awkward language.

What tools in particular are you missing out on?

Caram - to your point about the debugger, even that is not something I miss.  I am a printf–style debugger, and when I do need something fancier, I log json files that I then parse with a quick command line script.  Stop laughing!  It works! :-)

Also, if writing line numbers isn't your thing, use dbt to insert breakpoints.  They update `debugger_cmds` every time you compile, so line numbers get updated.  https://github.com/colinta/dbt

Colin T.A. Gray

Community Manager

HipByte

Sign up for RubyMotion training! http://training.rubymotion.com

[adam wilson]

Not sure if I'm qualified to chime in here, as I've only started using RubyMotion a couple of weeks ago. I was drawn in by the new Android port, as I've been developing an app initially for Android with a view to building an iOS version after. 

I've been waiting over a week for an answer to a support question around importing .jar filles, I know its in beta and all but it is advertised as one of the features for Android development... just would be good to have an idea so I can plan my project around it - e.g. 'were looking into it' or 'have you tried xyz' 

[Polar Humenn]

I'm not so disillusioned with Rubymotion, yet. But there are strange memory errors, and stuff that just doesn't work, or I haven't figured out "how it's supposed to work," yet.

I am more disillusioned with iPhone development in general. It's like a trip back to the 1980s, and the nineties are more than over, man! As some would have it, Ruby may be "friendly" to some. It's a nightmare to others like me, who are advocates for type safe languages and a guy who worked on functional languages, like Haskell, back in the day.

Originally, we embarked on type safety to get attain efficiency of execution from the languages in which we wrote code. In all, that was a good goal, but the ultimate benefit of that effort is now the ease with which the development process has improved. The development tools, e.g. Eclipse, are excellent at analyzing the code on the fly, good at making suggestions of method names you desire, and proper argument matching by type, and leads to much faster development process, eliminating stupid errors due to the dynamic compiling the IDE employs. And refactoring the code is just a few mouse clicks away, brilliant!

Ruby throws most of that progress into the trash can, and you end up with typeOs and argument mismatches so far down the line that you have write test for everything, just to make sure you typed it correctly. And you can still get burned way down in the process when you fire up the app, because your development tools don't have a friggin clue about what is to transpire. That process is ridiculously long.

I started on this project with Rubymotion because I have an Android App that I did in Java, as one does. It took me a week to learn enough intricacies about the process, and with the help of a good IDE and it's integration with excellent documentation, I had a functioning app with maps in about a week. It was a relative breeze. 

My app contains a lot of non-ui logic, so after a failure of trying to convert the Java to Objective-C (you can read about that here), I decided to go with RubyMotion, based on the fact that I could get a common base of code that will work for both the Android and iOS. 

I've been at this Ruby crap for months, converting my Java code to Ruby. The IDE I'm using is RubyMine, which is good, but it's Ruby, so it can only be so good, and that's just not Eclipse and Java. It's been a trying experience. As a result, I have Rspecs for everything, basically which is the result of just trying to clear the typeOs and the type mismatches that the IDE can't do anything about before I get into the arduous iPhone/Rubymotion process.

Objective-C is the most inelegant language I've ever come across. Anyway, I bought Rubymotion, and it's just been a frustrating experience. Rubymine just doesn't play well with it. The debugger sucks, and is basically useless. However, it's consolation is that it's better than Xcode and Obj-C. And the REPL is somewhat useful, except that I have so many "puts" statements in my code for debugging purposes, trying to read the result of an evaluated expression in REPL is like trying to catch chickens in the yard if you can't stop the scrolling fast enough. Also, REPL tries to print out the resulting object and if the object is large the whole thing crashes with a malloc_error, which is some throwback from the 1970s, but I digress.

The whole write code, compile, fire up the simulator, fire up the app, crash sometimes with or without an assembler dump reminds me of a time when I would accidentally drop a boxed program of punch cards on the floor, or when the card reader would chew your cards like a mad dog. Alas, you guys are probably too young to remember that, and some of you'll probably say I'm too old to be doing this stuff.

In any case, I'm hoping that some of the problems with Rubymotion can be gotten around and that the Android thing will work. I'm kind of betting on that. I've seen a lot of software come into being and improve, even Microsoft's horrible crap, given enough time. I still have faith. 

Cheers,

Dr. Polar Humenn

--

You received this message because you are subscribed to the Google Groups "RubyMotion - Ruby for iOS, OS X, and Android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubymotion+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubymotion/ef555541-ab59-4eee-91be-d10081ae2f10%40googlegroups.com.

[Kevin Fagan]

It's not tools I'm missing, it's stability. These are the issues I ran into in the last 6 weeks while trying to finish up a rubymotion app with with a today widget.

1. Testing main app on device only when I experience random crashes. Turns out that Dispatch.once is broken, spend hours debugging my code only to later learn it's a rubymotion regression. Later fixed in a RM update.

2. Cannot load today widget onto device since ARM64 support is not available. Support later arrives in an RM update.

3. To test my today widget I load app onto device and deployment fails every time with cryptic certificate errors. Spend hours invalidating and creating new provisioning profiles and certificates only to later learn it's a rubymotion bug. Later fixed in a RM update.

4. Experience random crashes on the device and more hours debugging only to figure out it's again an RM bug which affects C structs under ARM64. This issue is still to be fixed so there's nothing I can do but wait it out.

So here I am 3 weeks later and still unable to ship my app.

Last week I was fed up, I've been wanting to dip my toe into swift for a while now so with nothing else to do I started porting my RM app over. Ruby is a much more elegant language but other things have won me over:

* The Xvim plugin for Xcode gives me 90% of the editor features I miss from Vim.

* Swift to my eyes, though not quite as elegant as ruby is big step up on objective c.

* The strong type system has me catching more bugs much earlier. With RM it was always write some code, watch the app crash, check the stack trace, fix the bug, relaunch the app. With swift I find that most of the time when I launch the the app behaves exactly as I intended, the compiler checks are a huge help.

* Xcode and Instruments gives me much better metrics on how my app is performing. RM support for instruments is nowhere near good enough.

* The ecosystem is bigger and better supported. I can get tools like crashlytics and paintcode to work without resorting to hacks and porting code.

[Bryan Maynard]

I feel similarly to several people on this thread: while Ruby is an elegant language and working with a familiar process is nice, I've been bitten by too many RM bugs. More than once development of my app been blocked by bugs in RM.

Most recently, when I posted about a problem I just encountered, I got a reply from the Community Manager that I felt was dismissive. I pay for the privilege of using RubyMotion just like everyone else here. I understand that more details make diagnosing issues easier - the problem is that I didn't have the details to provide.

As someone else said; I've been eyeing Swift since it came out, and since my support contract expires in less than a month maybe it's a good time to take the plunge and switch to Swift. After all, let's be honest, finding solutions as a RM developer primarily involves finding a solution built using Apple's tools and attempting to reverse engineer it to work with RM.

[Roy B]

I'm really disappointed to hear that people are still struggling. 

RM is an amazing accomplishment by some very smart people, and no doubt a huge challenge. However IMHO it feels like it has been more like a fun (not-)open source project for its developers than something worthy of committing one's professional reputation on. Given the state of the runtime when android support was announced, and looking at the size of the staff, it's pretty clear that there simply has never been enough resource to get RM where it needs to be, and sadly where priorities lie. 

With so many cheerleading (out of politeness or self-promotion?), those who are having trouble get drowned out too often. 

That they are shipped apps doesn't mean there are not critical flaws that deserve top priority in the queue. And bugs should never sit unanswered for months.

[Caram Dache]

Colin,

Thanks, I’ll have a look at dbt. I’m glad you can work with json printfs but I need something a little more efficient/intuitive and I guess other people might benefit as well. This is the part of the workflow where I am currently really unhappy/uncomfortable with.

To be constructive: I understand the team is thin and there might not be enough resources around, but I am thinking something like the feu Smalltalk debugger might not be too difficult to put together:

- a text editor (whichever, it just needs to be able to display lines and set/clear breakpoints graphically)

- a stack trace (to easily switch from one frame to the next)

- a REPL (where you can access objects/fields from the current stack trace)

- (optionally) a little object window to keep objects around

Also, I’m still struggling with half crashes not showing line numbers in the stack trace. This makes debugging really like a clever detective art. Is there any chance this might be improved?

Caram

Le 6 nov. 2014 à 17:31, Colin T.A. Gray <co...@hipbyte.com> a écrit :

[…]

Caram - to your point about the debugger, even that is not something I miss.  I am a printf–style debugger, and when I do need something fancier, I log json files that I then parse with a quick command line script.  Stop laughing!  It works! :-)

Also, if writing line numbers isn't your thing, use dbt to insert breakpoints.  They update `debugger_cmds` every time you compile, so line numbers get updated.  https://github.com/colinta/dbt

Colin T.A. Gray

Community Manager

HipByte

Sign up for RubyMotion training! http://training.rubymotion.com

[Colin T.A. Gray]

It will be difficult for us to move away from the "editor agnostic" stance, but that doesn't mean we don't want to improve debugging, in fact that has been the subject of much internal discussion.

One issue, though, is that we are at the mercy of llvm and lldb.  Even though the RubyMotion compiler emits all the meta-information that lldb expects (like DWARF code, but I know little about this area), as you point out we still miss out on our useful stack traces.  It's a very different situation from running Ruby on MRI or Rubinius - or any other VM-based Ruby implementation.  RubyMotion, at the end of the day, is running as machine code.  While this gives us a pretty huge performance gain, it also means that we do not have the ability to use awesome tools like pry.

Colin T.A. Gray

Community Manager

HipByte

Sign up for RubyMotion training! http://training.rubymotion.com

--
You received this message because you are subscribed to the Google Groups "RubyMotion - Ruby for iOS, OS X, and Android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubymotion+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubymotion/61760AAC-BF1D-4ABE-8F05-4B2B93142B76%40gmail.com.

[Caram Dache]

Thanks Colin. This is an important area for me. I am highly productive using RM until I hit the difficult bug to track down using command lines tools. How to make further progress? If the DWARF code is emitted properly, would Xcode debugging be a simple, viable alternative? The simplest I need is a mixture between the current debug mode and the REPL.

Yeah, I know, fellow developers always want their cake and eat it and LLVM is quite a beast. (Emitting code on the fly now that WebKit has added support for JIT JavaScript?)

Caram

To view this discussion on the web visit https://groups.google.com/d/msgid/rubymotion/3BF52419-DC15-4FEB-875A-56F3AA84EF89%40hipbyte.com.