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.