[Haskell] Re: [Haskell-cafe] Work on Video Games in Haskell

[Dave Bayer]

On May 26, 2010, at 2:51 AM, Ryan Trinkle wrote:

> I don't think this licensing issue will be a problem for us.  It's not clear to me that our game violates this new term, and we certainly don't violate any of the principles Steve Jobs used to justify it.  If Apple wants to reject our app, they already have a variety of excuses at their disposal, as they've demonstrated on many occasions.  Frankly, it'd be their loss; Android is now the fastest-growing smartphone market, and we'll be more than happy to focus on it (and other friendlier markets) if Apple's not interested in having our product on their platform.

The best accounts that I read at the time on this were

	Why Apple Changed Section 3.3.1
	http://daringfireball.net/2010/04/why_apple_changed_section_331

	Strategy Letter V
	Smart companies try to commoditize their products' complements.
	http://www.joelonsoftware.com/articles/StrategyLetterV.html

In the narrow sense, Apple didn't want Adobe Flash to become the default development environment, at the expense of any distinctive look and feel or performance advantage to the iPhone/iPad. Adobe code is the worst and most expensive code I use regularly (it stinks, in short), so I'm sympathetic here. In a broader sense, Apple does want to make it hard to develop for all platforms at once, but that's a losing battle for them as you note.

The iPad / Android application that would most excite me to write, and the "game" that would most excite me to play would be a "gesture" programming language. I owned a FingerWorks TouchStream keyboard before Apple bought them out; this really is a radical paradigm shift, even if Apple is teaching the masses by cautiously dribbling out one gesture as a time.

Read "Coders at Work": The most reasoned, pragmatic objection to Lisp family language syntax over e.g. Haskell syntax is simply code density. This consideration gets up-ended if one's primary constraint is entering code through a novel, limited bandwidth interface. Lisp's parentheses are an historical artifact tied to an input method that iPad-like devices will help supplant; even on keyboards one can get rid of most parentheses by the Haskell $ op and resolving the "missing outline levels" issue. One actually thinks in syntax trees, and could enter them directly as trees through a gesture-based editor that understood the grammar, your choices and their probabilities.

The iPad does allow calculators, and such a program would be a smart calculator. It would be a shame if Section 3.3.1 ruled out the most radical experiments with the iPad technology. On the other hand, why haven't I bought an iPad yet?

	*** It's NOT a computer! (Slap forehead) ***

One gets bit by this at every turn, one doesn't have to turn to to Section 3.3.1 to see this. Try saving or printing a PDF from the browser.

I bought my first Apple in 1980 because they were the most open; none of the other choices even survived. For generic desktop boxes, Ubuntu looks better and better to me on each release as I sour on Apple over this business bull as they morph into M$; for GHC Haskell I only want OS X to make effective use of every core in parallel, in situations where I'm willing to suffer the restrictions of 32 bits.

On May 25, 2010, at 11:52 PM, Ryan Trinkle wrote:

> We believe in giving back to the Haskell community, so we've open-sourced our ghc-iphone project, which allows GHC to produce binaries for the iPhone.  Check it out at http://projects.haskell.org/ghc-iphone/.

This would be a perfect platform for playing with this idea!