So I was supposed to have a new mobile phone by now. I spoke to the sales rep for my wireless provider Monday who had to convince the customer care department that they needed to give me a shiny nice new phone to make up for all the crap I’ve put up with for the past six months. Maybe it should be called customer we-don’t-care. Anyway, they finally agreed and I was supposed to have a new phone yesterday. Except that it didn’t arrive. My bill arrived no problem, so they obviously have the right address. I call the rep, and he’s not available.

The only thing keeping me with this provider (for now) is that it will suck just as bad with every other provider anyway. What a crappy business model: “We suck slightly less than everyone else”. Maybe it should be their advertising slogan. Let’s put it on a billboard.

My dad (who needs his own blog) pointed me to a presentation from the 2nd Microsoft Research Rotor Workshop that was held in April in Pisa, Italy. The presentation in question is by Luca Cardelli on the subject of programming language innovation, a topic I’ve blogged on before. I want to take a look at the other speaker’s content, but a couple of things stand out from Luca’s talk.

• Programming Language data has traditionally been triangular, i.e. object graphs, while persistent data has traditionally been rectangular, i.e. database tables. This leads to an integration issue between the programming language and the database. However, data is evolving. XML makes persistent data triangular as well.
• In addition to data evolution, we’re also seeing an evolution of program flow. It’s moving away from threads and RPC and towards schedules and messages. IMO, that’s what Service Oriented Architecture is all about, but Luca’s point is there’s no support in the programming language for this model.
• There’s great coverage of the concept of “semi-structured” data. It’s not an array. It’s not records. It’s “unusual data” in Luca’s terms, which needs unusual programming languages.
• I get the feeling Luca is recommending new languages, not retrofitting existing languages with support for XML data and schedule based program flow.
• Luca points out that type systems for programming languages and for XML are still “deeply incompatible”. This jibes with my last XML entities post. I don’t want different programming styles for internal and external entities. If I can get a programming language that makes it easier to code against XML, that makes exposing internal entities as XML that much more reasonable.