* for the record, my steampunk goggles were bought off of Etsy.

SproutCore runs in the browser, your production system can use whatever backend you want, as long as it sends JSON to the browser.

When I was using an early version of SproutCore to build .Mac Web Gallery last year, the backing system was a WebDAV server that produced JSON when asked. I’m pretty sure that WebObjects is the backend sending JSON to the calendar and address book applications demoed at last week’s WWDC.

The nice thing about the separation of browser logic from the backend is that you can build some static JSON fixtures you can serve from your local web server while you’re developing your application.

ETA: Charles Jolley reminds me that you can consume XML as well as JSON, but JSON remains faster.

You wouldn’t be surprised to meet Ruby enthusiasts at a Japanese science fiction convention.

Shimura’s got embedded Ruby running in Illustrator. Press a button, and that evals to ’7′.

The back story: Shimura’s part of Cafe Scifi+tique, a performance event put together by Japanese science fiction fans to invert and parody the creepy ‘maid cafe’ scene.

Cyn and I paid 500 JPY each to sit down with an actual scientist while we were served tea and juice for a half hour.

The annoying thing is that the mad scientist cafe’s set up in the far part of the convention hall, while another group’s running a maid cafe in the main exhibit hall.

Much of an object’s strength lies in its behavior, not its data. If you only try to provide the minimum, you end up with multiple clients duplicating code for common cases. In cases like flatten you end up with a bunch of people writing their own recursive functions. It’s not hard, but why should they bother when it’s not that rare a case?

Harold thinks the class is too large and needs refactoring.

There’s simply no reason for 78 methods in a basic List [Array] class. In fact, there’s no reason for 78 public methods in any class. 78 public methods in one class is a code smell. 78 public methods make a class hard to learn, hard to use, hard to test, and hard to maintain. When a class has 78 public methods, it’s time to refactor.

I think Harold’s right when it comes to designing one’s own classes: make them small, focused and testable.

However, if a language has core classes like Array, I think there’s a reason to build in convenience methods so that users don’t have write them from scratch. Projects like Ruby have resources for writing optimized implementations of those methods, and testing them.

This summer I ended up writing about a dozen additional methods for the PHP libxml2 object. I can see other projects needing the same methods, and it would had been nice to have them baked into PHP.

But anyone can walk up, hand $10 to a hosting company, and start serving PHP + MySQL applications. If you want to run Perl, Python, Ruby or anything else, you need to use CGI or a dedicated and more expensive server.

Not to knock those other languages (and I’d like to do some projects in Ruby or Python,) but until Mod_(Perl|Python|Ruby) becomes as common as PHP in hosting packages, people are going to build their applications using PHP.