One of the great bonuses of writing for a magazine like PC Pro is that you get invitations to major product launches (or is that lunches?) and the occasional conference, to see what software vendors have planned for the future and chat with like-minded people. So it was when I was invited to Mix:UK, the Brit version of a larger event held in Las Vegas early in 2007, where such luminaries as Scott Guthrie and Angus Logan from Microsoft spoke about Silverlight and the Microsoft “Live” platform. I came away with several pages of notes, many unanswered questions in my head and the feeling that it could all have been presented much better.
By that I mean that most attendees were programmers hoping to see the tools they’d be using over the next year: their companies were paying to get a real-world “edge”. It’s hard enough nowadays to keep up with developments and know what to invest time into learning (that’s why you read this magazine, isn’t it?). But instead of being shown something we could go away and start working with, we were shown early alphas of Silverlight 1.1, so early and so alpha that they had no controls and all you could do was draw simple shapes. As such, it had very little relevance to the real world.
We all know people who can talk for hours about the relative merits of a particular way of coding, but most of us need to churn out working code that stays working, and in a realistic timeframe. Some of you may remember playing with Ajax extensions for ASP.NET and getting them to work only after much gnashing of teeth, research and forum chat – then the next version of the extensions were released and this hard-grafted code would no longer run, requiring so many changes that rewriting from scratch was the easier option, for me at least. Sure, there were lots of good reasons for the changes, and the resulting extensions were much better, but experiences such as that leave us with little enthusiasm for anything more than a quick glance at Silverlight 1.1 – who knows what will have changed when it finally escapes?
There were some points mentioned that caught my interest, however. For example, Microsoft claims that no feature will be added to Silverlight that won’t work on all browsers, and on all platforms. This is a claim worth monitoring and holding the company to, and one that could come back to bite it very hard indeed. Interestingly, for the two days of the conference, I found no mention of the accessibility features to be incorporated into Silverlight. Admittedly, I couldn’t attend all the talks as many ran simultaneously, but accessibility issues certainly didn’t seem to top the agenda with Silverlight code. Let’s just hope Microsoft isn’t making the same mistake Macromedia did with Flash, forcing it to “bolt on” accessibility features later.
At any programming technology previews, I always make myself a small bet that Microsoft will announce yet another new way of connecting to data sources, and I wasn’t to be disappointed this time. Finding new ways of dealing with data sets seems to be a long-standing Microsoft tradition. No longer content with SQL – a long-established data query language that most developers are now pretty proficient in – we’re being offered LINQ, which looks a little like the old FoxBase.
LINQ can be imagined as a universal language that translates queries into a native query language, dependent on the particular data source – so if, for instance, you were accessing a SQL database it would translate into MSSQL, while if you were accessing a XML data source it would translate the query into XQUERY. So we have LINQ to SQL, which was previously known as DLinq, and LINQ to XML, which was called XLinq, and the idea is that there will be connectors for Access, LDAP, web services and SharePoint, in fact to any data source. There’s also work being done on a version of LINQ to be known as PLINQ that tries to spread a query across multiple processors and so speed up its execution, but the fact remains that querying via LINQ is still going to be slower than using the database’s native query language, so why use it at all? The official rationale is that LINQ isolates the concepts programmers need to deal with from the back-end implementation.