It's been a rough week ... I still had my sore throat (noticeable during the webinar) when I arrived to do four days of accelerated Tapestry training in Michigan. Returning after midnight on Friday, I had morning and afternoon slots at Portland Code Camp on Saturday to talk about Clojure and Tapestry. I think it was a good little conference, and 75 minute time slots are just barely enough time to say something meaningful.
I attended a nice introduction to jQuery (once again confirming that I backed the wrong horse when selecting Prototype over jQuery for Tapestry), and another session on coding for iPhone.
The only other session I attended was iPhone Development from an ex Softie by Rory Blyth. It was entertaining in an unusual way, since Rory is very glib in a stream of consciousness kind of way, but he spent all but five minutes of his time ranting against Objective-C and iPhone toolkits. Literally he had five minutes for the core of his talk!
I was one of a few people in the audience who knew Objective-C (though it's more than ten years since I coded in it) and found many of his objections quite unreasonable. Basically, he wants Objective-C to look like every other language derived from C, which is missing the point of what Objective-C actually is: a melding of concepts from C and Smalltalk designed to operate on the very constrained hardware available, even for desktops, in the late 80's. It obligates developers to do something unreasonable by today's standards (a cumbersome retain count mechanism, rather than garbage collection), and the (optional) type syntax (such as (NSString *)) reveals its C heritage (as Smalltalk doesn't deal with declared types).
I even made this point to him; that Objective-C may be a natural fit for the constrained devices such as mobile platforms. His response to any challenge from any audience member was that we were afflicted with "Stockholm syndrome".
Strangely, a few minutes after I pointed out the "constrained device" theory (which he dismissed, disjointedly citing Windows smart phones as a "success") he then talked about ... the constraints of the iPhone in terms of memory, battery and CPU utilization.
Basically, Rory is unable to wrap his head around anything unfamiliar or to understand how a difference in philosophy can inform how a language syntax evolves, as well as the terminology (i.e., Objective-C's "receivers", "messages" and "selectors") used to describe that language.
There's a quote from the book Freakonomics, roughly (from memory):
Morality is how we think we should live our lives. Economics reveals how we actually do.
Rory has a kind of "language morality" that states the objects should be listed first, with periods separating member access, such as method invocation, and that languages that deviate from this are failed and broken. Unfortunately for that argument, the explosive success of the iPhone and the iPhone app market indicates that Objective-C is a tremendous development platform for the kind of intuitive, focused, responsive applications that dominate the market.
It was a shame, because his style was entertaining, if very "slacker" styled, and if he organized his thoughts a bit and kept track of the clock, his valid criticisms of the iPhone development environment would hold a bit more weight and reach a wider, more receptive audience.
6 comments:
Interesting comment on jQuery vs Prototype, would you mind expanding on that? Also, does this mean that in the future Tapestry will be including jQuery as opposed to Prototype? If so, any thoughts of which version?
I would be also interested to know about next version tapestry features. Also in the future IDE developments in support of tapestry. Currently having bad time with MyEclipse and its tapestry plugin.
I'm, also very interested in any plans Howard may have on the jQuery/Prototype issue.
I've been using jQuery on my Tapestry projects for a while now.
I started out learning Prototype, but in the end I switched back to jQuery because I like it better, it's faster and and there are more plugins available.
To me it feels like I am forcing our users to load a lot of useless Javascript into their browser, since only a very small subset of Prototype is being used.
I'm guessing it should be possible to rewrite the main Tapestry js file to plain Javascript. Feel free to correct me if I'm wrong though.
It'll be a whole lot of work, so maybe we can split up the work. I'd be happy to rewrite a couple of functions if needed.
If this is done, developers can more easily pick the framework they are already familiar with and reuse the code they have already developed, which makes Tapestry even more productive.
I don't think it'll break existing projects since developers can still manually include prototype if they've come to depend on it.
The next logical question is "will Tapestry support jQuery as well and deprecate Prototype"? Note that this doesn't mean that Prototype should be totally ripped out...just that Tapestry can support both with a preference towards jQuery. It'd have to do this to be backward compatible...
This discussion has already taken place on mailing lists; the intent is that at some future date it will be possible to choose protoype or jquery (or something else) as the underlying JS layer. It's tricky, I like P's "class-like" (or "class-lite") support for example, but jQuery looks largely easier to use and faster.
However, this does add another dimension to resuable components, as most internal and third-party components are making explicit use of Prototype (such as the $ function at the very least). This means its quite a bit of work to move to another underlying framework, especially one that interprets $ as a similar but distinct function!
That was a very fair, if not generous, account of Rory's presentation. It felt more like a stand up comedy routine ("What's the deal with square brackets ...") than a tutorial.
His criticisms of Objective C just seemed incredibly naive. It also bugged me that he kept going on about there only being one major update of the language in 20 years. Sure there was only one major update to the the language -- because it didn't need it. The core syntax and structure of the language was simple, flexible and very, very useful. What he ignores is that there has been consistent and awesome updates to the NextStep/Cocoa frameworks and libraries.
Post a Comment