RubyMotion Success Story: Cabify(blog.rubymotion.com)
blog.rubymotion.com
RubyMotion Success Story: Cabify
http://blog.rubymotion.com/post/30514580062/rubymotion-success-story-cabify
5 comments
Congrats to Mark on his success! For those who haven't had a chance to follow along, Mark has been a constant presence in the community and I'm glad to see his drive and willingness to take the initiative has paid off. His story is also a perfect example of why it is so important to get out, give talks, and participate in your local development communities, even if "local" doesn't overlap with "Silicon Valley" or "NYC".
That's a very good point to focus on. Thank you! ;)
Thank you Joshua! :)
Just curious - are developers putting themselves at risk by revealing they're using RubyMotion? ie risk of being penalised in app store or possibly even banned if Apple's policy swung back to how it used to be.
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?
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?
You would have to be rather talented and put in a non-trivial amount of effort to tell a RubyMotion app from any other iOS app. A while back there was a conversation in IRC where one person was trying to do just that and kept coming up short...
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".
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".
How does cabify differ from uber? I haven't used either...
I haven't used Über, but the idea is exactly the same and the apps are very much alike. I live in Madrid, which is one of the cities where Cabify operates. I've used their service a couple of times and I can only recommend it. Looks like a good place to work and Mark Villa Camp, the guy mentioned in the article is a well known name in the Spanish tech scene.
Is Cabify a copycat? Whatever, is a well executed idea and I wish they succeed.
Is Cabify a copycat? Whatever, is a well executed idea and I wish they succeed.
I, for one, am not looking forward to an influx of Rails engineers redefining the iOS development culture in their image.
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.
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.
I really don't understand how the world of iOS development has become one of the most cloistered developer communities in recent memory. Is it the gold rush mentality, maybe?
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.
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.
> I really don't understand how the world of iOS development has become one of the most cloistered developer communities in recent memory. Is it the gold rush mentality, maybe?
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.
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.
> We're simply not interested in the subpar engineering that comes from the inexperienced web developers joining the gold rush.
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..
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..
> 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.
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.
> You must understand that the iOS development community has its roots in decades of engineering community, coming from NeXT, Mac OS and UNIX traditions.
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.
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.
> 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.
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.
Bypassing visual builders in favor of code is not a new idea!
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.
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'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.
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.
What exactly have you done in iOS programming to feel so entitled? Seriously, it must be awesome, give us a link maybe?
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.
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.
> What exactly have you done in iOS programming to feel so entitled?
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.
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.
>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.
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...
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...
> Sounds impressive (but, no pointers/links? How to differentiate from some random guy on the interwebs?).
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?
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?
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).
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.
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.
> 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.
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'
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'
Quick question: Why do you think that RubyMotion doesn't support Interface Builder? It does, wonderfully, including storyboards. In my last project I used them, along a number of 3rd party libraries like the new Facebook iOS SDK and Urban Airship, all with no problem.
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.
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.
RubyMotion didn't support IB at all when it was released. Glad to see that's improved, but how does IB parse your code if its in Ruby?
Also, 'going back' to ObjC would mean a rewrite, not keeping around mountains of code you have to continue to maintain.
Also, 'going back' to ObjC would mean a rewrite, not keeping around mountains of code you have to continue to maintain.
> ObjC needs to be replaced,
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.
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.
Heh, yeah. Look at that company. A 20 years old dude comes with some hipster unproven technology and the boss jumps at it.
They are doomed to fail.
They are doomed to fail.
RubyMotion changed the way our entire agency operates: we haven't outsourced a single app in months. It's been the best thing to happen to us, hands down.
Uh, reading that just hurts.
You could have also just learned how to write Objective-C. It'd be more fair to your clients.
How so? These responses are quite simply FUD.
For the same reason we don't use MonoTouch on client projects; it would creat a maintenance and hiring nightmare for our clients. You jumped on RubyMotion out of laziness or inability to learn something new.
I absolutely believe that the process of developing an app with RubyMotion is revolutionary in terms of mobile development. The flexibility of Ruby paired with the interoperability with Obj-C is nothing but a win.
Says the individual that had to farm out mobile development until you could use a language with which you were already familiar.
There's little I've seen in RubyMotion that provides a substantive improvement on ObjC, and a lot that is worse than ObjC.
There's little I've seen in RubyMotion that provides a substantive improvement on ObjC, and a lot that is worse than ObjC.
It just depends on what you want to do. For example, if I wanted to develop a 3D shooter game do you think I would do it in Objective-C, C++, etc? No -- I'd use Unity or Stage3D and then compile to the target.
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.)
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.)
elegance, simplicity, beauty.. do those words emanate from Ruby in waves or from your inability to give a technical description? what overhead and code-bloat are you talking about? you can read the LLVM code and the objc runtime from Apple and go into specifics if you like.
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.
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.
Every technology gets proven with its use, investing time, great loads of effort, sometimes money, and courage. Last one it's the most important for me :) Btw, did you know any technology that was already proven when it wasn't known? IMHO that's a part of the mainstreaming process, and almost everything we have today has past through it.
Unproven in what sense? This is not some novel academic concept. It's a Ruby port on the Obj-C runtime. If it builds and runs the app, there is absolutely nothing to be proven.
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...
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...
Hmm, I have used Cabify and it's a horribly slow application. Now I know why.
- "We hope to launch a new completely redesigned app in the next few weeks, as opposed to months!"
It seems the app for common users is not the RubyMotion app.
It seems the app for common users is not the RubyMotion app.
They are not using Rubymotion for their customer app yet.
No, you don't. Of all the things I have against RubyMotion, performance is not one of them.
As far as I'm concerned, Rubymotion shoudn't decrease the performance of an app...
Yup Rubymotion isn't interpreted, it's compiled file by file to LLVM bytecode, this negatively effects development speed but it means it runs (roughly) as fast as pure obj-c (or so they claim on the rubymotion site).
We're using it at the moment to develop an app, it's great at keeping code DRY, debuggability on device kinda sucks atm though.
Given how RubyMotion works (not an interpreter unlike regular Ruby), if the app is slow (I didn't test!) then it's very likely not related to RubyMotion.
I call BS.
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.
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.