RubyMotion Success Story: Cabify
blog.rubymotion.com
blog.rubymotion.com
I assume there's no way to tell an app is RubyMotion by inspecting the UI, though maybe it's possible to tell from the binary?
Edit: Also, "how it used to be" was a stupid, knee-jerk reaction to Adobe and caused significant consternation even within Apple (disclaimer: I was working at Apple at the time). Furthermore, considering that the single most recognizable "App Store" brand utilizes a non-trivial amount of Lua, there is essentially zero risk that things will go back to "how it used to be".
Is Cabify a copycat? Whatever, is a well executed idea and I wish they succeed.
The lack of respect for knowledge gained over 20+ years of platform development is staggering, but not unexpected. They're rejecting everything from Interface Builder to the standard build tools, and adopting inferior web ideas wholesale -- such as attempting to style native UI with CSS.
While it may be par for the course, I'd had hoped that our section of the engineering field would be immune to influence from the Rails community.
Seriously, some of the outright hostility I've seen in the iOS development community is breathtaking. Yes, there is a lot of money to be made in iOS development so, no, you probably don't need to practice community building in order to be successful...today.
Regardless, your snide comment about "Rails engineers" reveals your own ignorance on the subject. There are plenty of software engineers that use Ruby but not Rails, and any developer who cannot use Ruby without Rails is unlikely to be of any threat to "redefine iOS development culture", since RubyMotion is not Rails.
Edit: Also...since when have "hacker" and "respect for knowledge gained over 20+ years" ever had anything to do with each other? Take the "knowledge gained", evaluate it on its merits, and if you find it lacking, who cares over how many years it was gained?!? If you think you can do better, do so.
You must understand that the iOS development community has its roots in decades of engineering community, coming from NeXT, Mac OS and UNIX traditions.
We're simply not interested in the subpar engineering that comes from the inexperienced web developers joining the gold rush.
> Edit: Also...since when have "hacker" and "respect for knowledge gained over 20+ years" ever had anything to do with each other? Take the "knowledge gained", evaluate it on its merits, and if you find it lacking, who cares over how many years it was gained?!? If you think you can do better, do so.
Which is why we've watched the Rails community re-invent the wheel repeatedly over the past 6 years, consistently rediscovering abandoned methodologies, and then rediscovering why those methodologies were abandoned.
One of my favorite examples was the the breathless enthusiasm at the rediscovery of the (inefficient, abandoned) pure pre-fork model: http://tomayko.com/writings/unicorn-is-unix
Or, watching the extremely poor architecture of Rails waste vast troves of server CPU and RAM.
Or any other of the hundreds (thousands?) examples of junior engineers ignoring history and re-inventing failed architectures that would not have been so broken if they looked at what came before with anything other than disdain.
I'm sorry but that's a super douchey thing to say. It's not like there's a limited number of "seats" in the iOS community room, and oh no you wouldn't want to waste some seats on web developers.
And who are you to speak for the iOS community?
There is room for everyone and anyone to join development communities and contribute as much or as little as they want. No one is forcing you to help anyone out if you think they're not smart or cool enough for your tastes.
That's the beauty of all this, everyone is welcome. If you can't see that, you've missed out on some important lessons in your decades of engineering work..
Not all ideas are equally valid. Socially-driven technology shifts are often not an improvement, yet they can change the industry we all work in. If mobile development is overrun by Rails developers -- and the engineering approaches they promote (often while ignoring history) -- the mobile development community (and the industry) will suffer.
I'm sorry, but Fart Apps need not be the exclusive province of "very serious" developers.
> Or any other of the hundreds (thousands?) examples of junior engineers ignoring history and re-inventing failed architectures that would not have been so broken if they looked at what came before with anything other than disdain.
Maybe. Or perhaps the communication and people skills of the generation that came before them were somewhat lacking.
Or perhaps we valued substance and were not so easily misled by style.
Meanwhile, the bubbles have given inordinate voice to the inexperienced and those lacking substance.
They are doomed to fail.
Also, "a 20 years old dude comes with some hipster unproven technology"? Isn't this how Apple for one was founded? Not to mention Yahoo, Google and Facebook...
There's little I've seen in RubyMotion that provides a substantive improvement on ObjC, and a lot that is worse than ObjC.
For 90% of the fairly-standard apps that we'll ever develop, the overhead and headaches and needless code-bloat that Objective-C brings to the project is only a reminder of the elegance of Ruby and the beauty of simplicity. (It's also a reminder that you'll no longer need to budget for XCode crashes every hour.)
To write a 3D shooter you can use Objective-C specific features as much or as little as you want. For intensive performance code you can bypass the messaging system and write pure C, for the rest you can use Cocoa APIs. This is what you do in any language. Unless you want to argue that dynamic languages as a whole are not worth it.
If you are happy with RubyMotion go ahead, but don't preach bad mouthing a language you haven't even developed on.
It happened as well with .Net and VisualStudio; I used to be a heavy WinForm developer (including visual tools). At some point being able to do everything programmatically proved to be really interesting in my use cases (and on other people projects, too).
Not everyone is going to adopt CSS and Pixate, and people are using RubyMotion without Pixate, too.
As for the Rails community, pure iOS people are also interested in RubyMotion (based on my exchanges with developers, that is).
In the end, there is no such thing as lack of respect or bad influence. New tools get created, people pick what works for them. People using Rails used other platforms before and will use other platforms later.
I'll end with an advice to (new?) programmers: don't let fear (of being replaced) choose your skills and tools for you.
I'm more concerned about propagation of bad ideas. The current job market and VC climate has given extremely junior engineers a voice grossly disproportionate to their skill, wisdom, or experience.
In a more healthy job market, those engineers would be hired into junior positions apprenticed to senior engineers. In the current job market, inexperienced engineers are given carte blanche, and this shifts the industry. Not all shifts are a net positive.
It was with great dismay that I observed the rise of the Rails community, and I find it exceedingly disturbing to see their anti-intellectual, anti-experience, anti-computer-science approaches extending outside their initial realm of influence.
That said, they may lack respect for "knowledge gained over 20+ years of platform development", but you also lack knowledge of the "worse is better" reality and the underlying Unix/Lisp history behind it.
One of the top-grossing apps with ~$60M/year in revenue. Considerable open-source libraries. A huge number of applications are running my code, even if you discount the code I have in the OS.
> That said, they may lack respect for "knowledge gained over 20+ years of platform development", but you also lack knowledge of the "worse is better" reality and the underlying Unix/Lisp history behind it.
"Worse is better" doesn't really mean anything. Most of the usage is predicated on false dichotomies and gross over-simplifications, usually revolving around the notion that the opposite of "worse" is nothing at all.
Moreover, if any languages/platforms were a poster-boy for the "worse is better" mantra, it would be Apple's platforms. ObjC is high-functioning dinosaur.
Sounds impressive (but, no pointers/links? How to differentiate from some random guy on the interwebs?).
But surely with those credentials you don't have any reason to belittle some guy for using RubyMotion for development. Heck, even MacRuby itself was initiated and sponsored by Apple for a couple of years.
The most important thing is the end result, not how it was made and if it was messy inside. Heck, OS X _is_ messy inside, and historically it had been much more messy, with a plethora of frameworks for legacy compatibility, a hodgepodge of system apps done with one or the other technology, etc, as you yourself acknowledge.
If the app is well thought out, runs fast and does what it says without crashing, the customer could care less with what technology it was made with. You haven't given any proof that an app designed with RubyMotion would be worse off than one designed with Obj-C/Cocoa.
It's not like IB is the be all end all of development. People have managed without it. And it's not like Obj-C magically gives more quality to your code compared to Ruby. Most of the "20 years of practices" sound like cargo-cult.
A Ruby guy, even a RoR guy, coming to iOS development might have fresh ideas of the kind that an old Obj-C/NeXT veteran might not even be able to comprehend. I haven't seen any innovate iOS apps from NeXT-era Obj-C guys...
Well, that's the trick, innit?
> But surely with those credentials you don't have any reason to belittle some guy for using RubyMotion for development. Heck, even MacRuby itself was initiated and sponsored by Apple for a couple of years.
It was skunkworks, and it was never mainlined as a strategy, because it's not the right strategy. ObjC needs to be replaced, but Ruby is two steps backwards for one step forward.
> It's not like IB is the be all end all of development. People have managed without it.
It's an incredibly valuable tool, and not using it significantly increases the maintenance burden, especially when it comes to letting the design department directly tweak user interface.
> And it's not like Obj-C magically gives more quality to your code compared to Ruby. Most of the "20 years of practices" sound like cargo-cult.
The slavish devotion to Ruby sounds like cargo-cult. I use Objective-C when targeting iOS, I use Java when targeting Android. I use C when targeting the the kernel, and I use C++ when using OpenCV. I use assembly when writing code that can't be expressed in C. I use C when targeting microcontrollers, switch OSs and IDEs to match the target environment. Windows 7 for Atmel Studio, Mac OS X for IntelliJ (Android).
In other words, I use the tools that were specifically made to produce the best possible results for users, while using standard and ideally optimal methods that produce the minimum amount of pain for both myself and for future maintainers.
What I don't do is cargo-cult development practices from one field (Rails/Web), while operating in a completely different field (ObjC).
> I haven't seen any innovate iOS apps from NeXT-era Obj-C guys...
Would you know?
Considering your idea of using the best tool for the job requires switching to the OS some IDE runs on, I wonder why you should be taken seriously. It seems you have a "slavish devotion" to IDEs like Atmel Studio and IntelliJ. I've managed to write production firmware for Atmel chips without having to use Atmel Studio; I have instead found gcc and gdb to suit my workflow better.
In other words, I use the tools that were specifically made to produce the best possible results for users, while using standard and ideally optimal methods that produce the minimum amount of pain for both myself and for future maintainers.
Can you point us to any studies that indicate which tools and methods have been proven optimal or shown to produce the best results for iOS applications?
You're not making any sense. Use what works for you, but don't assume everyone else is wrong because they don't see things the same way you do.
How long did it take you to set up avarice and GDB to work with jtagice? What did you use to configure your stk600? What documentation browser did you use to quickly look up the the HVPP or ISP pinouts of your Atmel programmer? Do you sit and manually calculate fuse bits?
Or did you cobble it all together because 'blah, windows', despite the fact that just about everything else in the field (Altera!) runs on Windows.
You can make the OSS AVR tools work, but it's a headache. If it's your real job, it's faster/cheaper/easier to use the official tools, especially as of AVR Studio 5 / Atmel Studio 6.
> Can you point us to any studies that indicate which tools and methods have been proven optimal or shown to produce the best results for iOS applications?
Can you point to studies that show that using a non-type-checked minority language and dropping half of the vendor tools is an advantage, and doesn't incur future maintenance costs?
If you're just writing for yourself, use whatever makes you happy. Otherwise, the equation isn't as simple as 'I like Ruby/makefiles/avrdude therefor it's the best choice'
Hell, and even if you decided to go back to pure Obj-C, you could just run a `motion static` command on your project and then import it back into XCode as a library and go from there.
Seriously trolling, dude.
Also, 'going back' to ObjC would mean a rewrite, not keeping around mountains of code you have to continue to maintain.
I'd like to know why. I've been hearing this for a while based on the generic design LLVM/Clang and the slower dynamic nature of Objective-C. Both BS reasons.
It seems the app for common users is not the RubyMotion app.
Your other comment in the same thread does not mention you using Cabify at all -- it's a general slant against the company for using "unproven technology".
And your account was created one hour ago, just to deliver these two negative comments here.