RubyMotion - Ruby for iOS

This is the classic response. It's also ridiculous. It's not just a matter of "passing the wrong type", it's a matter of using the type system to express higher-level constraints that make it impossible to introduce bugs in a complex system -- bugs more fancy than "I passed a string when I should have passed an int".

Of course, passing a string when you should have passed an int happens with regularity, too, and claims otherwise are a lie, especially if you don't spend a ridiculous amount of time pretending to be a compiler by writing extensive unit tests that would be totally unnecessary if you had one.

> And I never claimed that LINQ or C# lambdas were derived from Ruby, just that they were Ruby-ish. Clearly someone in Redmond is watching Ruby and Rails.

What? I ... no. I point out a 1965 paper on lambdas and you claim MS R&D is watching Ruby? You're comparing LINQ -- which implements a coherent model of relational algebra and set theory -- to Rails?

Ruby didn't pioneer these things, didn't add anything novel to them, implemented inconsistent models of them, and can't take any credit for them.

A. I wasn't talking about loading a nib vs programmatically wiring up a view. Many people never touch interface builder and write all their views from scratch, but in that case you still have the choice between compositing your view using subviews and overriding drawRect with drawing calls. Have you ever has the pleasure setting up a tableview controller on an older (first or second generation) iOS device? The difference in responsiveness there can be quite striking. This may be a topic rendered somewhat moot with newer hardware.

B. That's not my understanding, but if you have a source on that I'd appreciate a link. I was under the impression that while the cell will only be requested once it comes into view, scrolling the table still requires the visible to cells to be re-layed out, which is where the relative inefficiency of subview rendering starts to hurt you. I certainly could be wrong about that though.

C. If I recall, CoreGraphics is implemented on top of OpenGL. You still don't want to do complex graphics in your cell's drawRect in this sort of situation (I'm just imagining an image and a few labels, nothing fancy). Drawing a static image, pre-generated or cached, is a nice solution in some cases.

It's classic because it's true.

"bugs more fancy..."

Fancy? Fancy?? (thumbs through Knuth and SICP looking for "fancy" bugs...looks for "fancy" anti-pattern...)

Nope, not there. Consistent with my own experience, rather than anecdotal FUD (Fanciness Uncertainty and Doubt), after years and years and thousands and thousands of lines of code in type-safe and dynamic environments, I've yet to encounter a significant issue that would have been caught by a type-safe system.

"...especially if you don't spend a ridiculous amount of time pretending to be a compiler by writing extensive unit tests that would be totally unnecessary if you had one."

Complete. Nonsense. I write the same unit tests in RSpec and TestUnit that I write in NUnit and JUnit, and far, far, FAR, fewer lines of code for the same coverage in Ruby. I do NOT write extra unit tests because -- holy crap! I don't have type-safety!

No, type coverage is a side-effect of a well-written unit test. No extra effort whatsoever is needed.

"I point out a 1965 paper on lambdas and you claim MS R&D is watching Ruby?"

This is starting to sound like a debate between a CS student who just got out of a Set Theory final and just figured out who CAR Hoare is, and someone who is just trying to ship features and make sure his company makes money. Yes, I have a decent handle on lambda calculus (thanks for the Wikipedia link) and I know the differences between Ruby's collections DSL and LINQ, having used both pretty extensively.

It doesn't matter. The notion that MS is not paying attention to the most influential application framework of the last 10 years is a ridiculous idea. The fact that Ruby didn't pioneer lambda calculus is...just as obvious as the fact that C# didn't pioneer VMs, GC, generics, etc., and can't take credit for those either, and just as much of a non-sequitur.

Many people overestimate how expensive a view is to lay out, and jump straight into code (I'm as guilty of this as anyone else), without actually stopping to see how nibs perform, due to misunderstanding some part of the pipeline.

Have you ever has the pleasure setting up a tableview controller on an older (first or second generation) iOS device? The difference in responsiveness there can be quite striking. This may be a topic rendered somewhat moot with newer hardware.

Yup. Fun times. Glad we're not there anymore. And given AT&T gives away 3GS's for free, I'd have to agree that the topic's moot and go on to say that it isn't worth the time or effort to support a device that no one has anymore ;)

..but if you have a source on that I'd appreciate a link

Add a log to -layoutSubviews of your cell subclass, and look at how often it gets printed out when you scroll.

If I recall, CoreGraphics is implemented on top of OpenGL. You still don't want to do complex graphics in your cell's drawRect in this sort of situation (I'm just imagining an image and a few labels, nothing fancy). Drawing a static image, pre-generated or cached, is a nice solution in some cases.

Go far enough back, and everything UI-related is OpenGL. CoreGraphics, however, is not built directly on top of OpenGL. It's part of Quartz, (specifically, QuartzGL). QGL on Mac can use either CPU-backed or GPU-backed drawing. On Mac, QGL defaults to CPU-backed drawing, but an app can use the GPU backing instead, by setting QuartzGLEnable to true in Info.plist. This option isn't available on iOS. You're stuck with CPU, only, for CG.

I find them really easy to follow.