Twitter Weekly Updates for 2010-04-11

  • Remember the Milk is hiring a Scala programmer: #
  • Worrisome new rule for iPhone / iPad causing discussion on #monotouch — consensus seems to be that MonoTouch is fine. #
  • More scary stuff from new iPhone SDK license: “”Applications must be originally written in Objective-C, C, C++, or JavaScript…” #monotouch #
  • Restrictive clauses in new iPhone SDK agreement seem to only apply to AppStore Deployment: not enterprise deployment. #
  • Just got my first pair of rigid gas-permeable contacts. Blinking back tears like I’m watching “Brian’s Song” on TV. #
  • RIP Malcolm Mclaren #
  • I’m quoted (more politely) in this SD Times article on the iPhone restrictions: #
  • Power just went out in Kalaoa #
  • Power back in Kalaoa #
  • Heading over to Hilo and BI Pizza for tweetup. Is it rainy today? #

Powered by Twitter Tools

“Originally Written in…” vs. Code Generation

My assertion that the iPhone license phrase “Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine” can only mean zero code generation has been questioned. Here’s why I stand by that assessment (and consider the clause beyond the pale).

Let me point out that the common-sense reading of that clause is straightforward. The word “originally” clearly implies that writing this:

UIView.SetAnimationTransition(UIViewAnimationTransition.FlipFromLeft, this.Superview, true);

and transforming it into:

[UIView beginAnimations: nil context:context];
[UIView setAnimationTransition: UIViewAnimationTransitionFlipFromLeft forView: [self superView] cache: YES];
[UIView setAnimationCurve: UIViewAnimationCurveEaseInOut];
[UIView setAnimationDuration: 1.0]

is forbidden. To take it to the extreme, can you imagine betting your company on convincing a jury that writing the first (which is C# and MonoTouch) and generating the second means it was “originally written in Objective C”? If so, you have some hard lessons about the legal system to learn.

I should point out that even though this code is clearly very similar, there are some slight differences, such as C#’s enumerated values UIViewAnimationTransition.FlipFromLeft as opposed to Objective C’s constant value UIViewAnimationTransitionFlipFromLeft. The . makes a difference in the parse tree and in the programmer’s mind — a small one, but a helpful one.

I should also point out that today MonoTouch does not generate the Objective C 2nd listing. It probably generates something like:

.maxstack 8
L_0000: nop
L_0001: ldstr ""
L_0006: call void Foo.UIView::BeginAnimations(string)
L_000b: nop
L_000c: ldc.i4.0
L_000d: ldsfld class Foo.UIView Foo.UIView::Superview
L_0012: ldc.i4.1
L_0013: call void Foo.UIView::SetAnimationTransition(valuetype Foo.UIViewAnimationTransition, class Foo.UIView, bool)
L_0018: nop
L_0019: ldc.i4.0
L_001a: call void Foo.UIView::SetAnimationCurve(valuetype Foo.UIViewAnimationCurve)
L_001f: nop
L_0020: ldc.r8 1
L_0029: call void Foo.UIView::SetAnimationDuration(float64)
L_002e: nop
L_002f: ret

which is “Common Intermediate Language.” The .NET Virtual Machine loads CIL files directly, while MonoTouch generates at compile time native code, which¬† which is an exercise left for the interested student (and, while hardly trivial, is a mechanical process that can be reviewed for efficiency, improved, etc.). (The “nop”s, by the way, are for breakpoints and wouldn’t be generated in a release build).

Generating two levels of low-level code (C# -> CIL -> Native Code) may seem to be the source of inefficiencies, but generating for an intermediate assembly language is very common with modern compilers. Code generation may be a source of inefficiencies or it may be a place of optimization — that’s dependent on the skill of the compiler writers.

The reason why it’s absurd to forbid native code compilers but allow Objective C code generation is that there is no difference between generating assembly language and generating C. If you can write an IL->Native Code compiler, of course you can write a IL->C compiler. So were code generation legal, a potential strategy for other alternative language vendors would be to do FooLanguage -> Foo IL -> C (“OK, lawyers, as you can see, we are simply generating C code”) -> Apple Approved C Compiler -> Native. Kafka-esque absurdity, but perfectly cromulent. Indeed, I strongly suspect that all of the alternative language vendors are preparing just such a tactic as “Plan B” or “Plan C” in case Apple relents on the word “originally.”

The Double-Edged Sword

Why should Apple allow alternative code generation? They fear inefficiencies, they cannot control the efficiency of code generation, therefore it is logical to forbid code generation. Why is that unreasonable?

The reason is that if you forbid code generation, you forbid huge swaths of good programming techniques. Rather than go on about lex and yacc and report generators and screen managers, though, we have the delightful “The Elements” iPad app to make the point. Don’t take it from me that code generation is good, read the article:

Even the amazing animation synchronized to Tom Lehrer’s iconic song “The Elements”, which plays the first time you open the e-book, was generated entirely by a Mathematica program.