I've been testing Microsoft's new Office 2010, along with its equally important companion SharePoint 2010, and trying to decide where it lies between brilliance and disaster. It's certainly an improvement on Office 2007. I was relieved to find that Outlook 2010 performs much better than Outlook 2007 did on its first release. Still, the perenniel question with Office is whether you will actually notice the difference, other than a slightly changed colour scheme, as you get on with typing documents in Word and calculating spreadsheets in Excel. While there is the usual laundry list of new features, there's nothing here as dramatic as the switch from menus to the Ribbon in Office 2007.
The real difference lies elsewhere, in how Office is entering the realm of cloud computing. The likes of Google and Salesforce.com have a straightforward proposition: ditch your desktop applications, store everything on our servers, and run your applications in the browser. Microsoft cannot afford to take that line, since Office is its biggest source of income after Windows itself. It has come up with something more nuanced, offering what it hopes are the most beneficial aspects of the cloud without displacing desktop Office.
Therefore we have Office Web Apps, with in-browser creation and editing of Office documents, but still tied to the desktop applications if you need to go beyond basic features. Office Web Apps can live on Microsoft's servers, such as SkyDrive and the recently announced Facebook tie-in docs.com, or on your own servers as a feature of SharePoint 2010. You can use them from various browsers on Windows, Mac and Linux. Suddenly, opening and editing that .docx or .xlsx - these being the controversial Open XML formats - on Linux is not such a problem. I was pleased and surprised by how much the Web Apps improve SharePoint and change the way I use it.
At the same time, as I dug into the Office Web Apps, I found more and more frustrations. The Office Web Apps use the very same formats as desktop Office, but not all their features are available. For example, you cannot insert a new sheet into Excel via the Web App. In fact, there are so many things you cannot do that listing them would take many pages. That doesn't mean the web apps are useless, they are fine for the basics. Microsoft's solution if you need an unavailable feature: just open them in desktop Office. But what if I'm on Linux? Tough.
This same issue leads to problems which are close to being bugs. Let's say I'm in an Internet cafe using a machine that does not have Office installed, you are in the Office, and we are happily collaborating on an Excel spreadsheet - Office Web Apps even lets us edit it simultaneously. The spreadsheet is nearly done, you feel it needs a little jazzing up, and you open it in Excel to add some Word Art. Oops. Not only is the Word Art invisible to me, but I can no longer edit the spreadsheet. Sorry, says Excel Web App. Incompatible features.
It's something that cannot happen in Google Docs, or Adobe's Acrobat.com, where the web application is the only one that you use. I can see this kind of thing causing endless frustration. Note too that you get no warning when editing a document in a way that introduces web app incompatibility.
Office Web Apps is something we did not have before, and you can see it as glass half full, or glass half empty. Personally I expect to use the web apps, and if they help bring an end to the terrible practice of collaborating by emailing documents to all and sundry, I will be grateful.
Nevertheless, as a cloud offering the Office Web Apps are somewhat broken. It will be fascinating to see how this evolves. My guess is that the Web Apps will improve over time, to the point where installing desktop Office becomes unnecessary for many of us. Microsoft may not like the sound of that, but it is better for the company than the alternative, which is not using Office at all. Never bet against the cloud.
Image via Wikipedia
Yesterday Microsoft launched a new version of Visual Studio. It's stuffed with new features, has a new shell, and introduces a major new release of the .NET Framework, so there is plenty to take in if you work on Microsoft's platform. In fact, with so many things clamouring for attention it would be easy to give little attention to the brand new language that comes in the package - Microsoft F#. Admittedly the language is not entirely new; it's been around for anyone to try for some time. Nevertheless, it is new to Visual Studio, and giving it the status of a fully-supported language alongside C# and Visual Basic is bound to have an impact.
So why bother with F#? As it happens, I'm writing this from Intel's software conference in Barcelona, where the topic under discussion is parallel programming. We've heard nothing about F# (even in Microsoft's presentation); yet F# is a functional programming language and inherently well-suited to concurrency. One of the key features is that variables are immutable by default, whereas in imperative languages like C# and VB the opposite is true. Immutability makes multi-threaded code much safer.
Here's what F#'s inventor Don Syme told me when I asked him what F# brings to concurrent and asynchronous programming:
There's three things. The first is a real focus on reducing the amount of mutable state in your programming. This means in essence that your mutable state is to be boiled down to the absolute essentials of what has to be mutable. If you do have some mutable state it's local to the user interface thread or local to an agent. But in general you can often completely eliminate the mutable state through this consistent set of functional programming techniques, often by passing some data around explicitly, rather than propagating the data everywhere implicitly by these sort-of global mutable tables. So a focus on immutability first is a major factor.
The second is this Async programming feature which essentially allows you to add lightweight reactions to the system, so you can have many objects waiting to be activated by a callback of some kind, and you can program these objects without doing what's called inversion of control. You can program a series of sequential execution, a series of web requests for example, go to one web site, go to the next web site, go to the next web site and so on, and you can write what we call asynchronous workflows to express this logic which would otherwise be encoded as a set of callbacks all the way through your code. This is extremely important when you're talking about handling errors in a series of asynchronous calls or perhaps accumulating a set of resources across the calls and making sure we clean up file connections and other things that happen during a computational process.
The last thing we bring is an Agent-based programming model built on top of the asynchronous model. This lets you define many hundreds of thousands of agents in memory, in a single process. And this is critical if you're reacting to many different external events such a web crawler having many different i/o requests outstanding at the same time, or processing many different images in parallel.
It's a compelling story; and there are other nice things about F# as well, like the succinct, easy to follow programming style it encourages.
Let me now put this together with a conversation I had yesterday with Intel's Chief Software Evangelist, James Reinders. I asked him about functional programming and he sighed, telling me that yes, languages like F# make parallel programming much easier, but that there was no sign of developers switching to them. In addition, he said, there is so much existing code out there that no functional language can succeed unless it can extend applications written in other languages.
It then struck me how well Microsoft has ticked that box with F#. It is a .NET language, so integrates easily with C# or Visual Basic, and it is presented as a language with which to create libraries for specific tasks, rather than as something you are likely to use for an entire application. It seems to me that it can deliver real value and is well worth exploring.
There's more on F# here; and look out for more from my interview with Don Syme soon.