If you’re doing .NET development and have a background in Unix, it’s well worth checking out the second half of the new .NET Show episode on Longhorn Fundamentals. The first half of the show “Technobabble” was a bit disappointing as it didn’t seem to cover what was going to be in the Longhorn Fundamentals layer. Most of the discussion was on security.
The second half “Enter the Programmer” was fascinating. This section of the show covered Monad (also known as MSH) which is a Microsoft command line shell environment. As Robert Hess mentioned, Jeffrey Snover seems pretty chuffed with his software “progeny”. Who can blame him? A scripting/shell environment that is object aware and tightly integrated in with the .NET platform has huge potential. There is an element of technical beauty in the ability to pass lists of objects between loosely coupled processing modules using pipes with run time type flexibility. The proof is in the pudding though, and the reality comes with actual usage. I’ll be happy to give up the need to go through parsing hassles for every small admin task that needs to be written. Unfortunately, I can’t justify the time to play around with it at the current point in time. Bummer.
As usual with .NET related technology, crunch time usually comes with the deployment scenario. Where can I use this stuff on my customer’s systems? It seems Monad/MSH is slated as the Longhorn Command Shell. Due to it’s nature, my guess is that it’s one of the technologies that won’t necessarily be bound to Longhorn and be formally made available for other current Windows versions. Hope so.
Even if it were made available on Windows XP, 2003 and 2000 there’s stuff all chance it will be available on anything other than Microsoft platforms. There’s also the perennial question of whether something similar is developed for Linux (e.g. Mono based) and what Microsoft would do about it.
The strength of the Monad functionality is that it’s aware of objects and plays in that space. This is where I think more software environments/tools need to head towards. It’s a long held belief of mine that the Software Industry hasn’t really put enough effort into Object technology. That may seem like a crazy statement, but take a look at relational databases, SQL and XML technology. The primary programming paradigm for the last 15 years is arguably object oriented but we’re still banging our heads against the relational database plumbing needs (check out the Anders Hejlsberg video on Channel 9).
An OO system can represent relationships between abstractions far more comprehensively than a “relational” database (may be they should be called table databases or grid databases). With regards to XML, I’d much prefer a text format that is similar conceptually to XML but maps more closely to OO data related concepts (types, fields, properties, relationships, lists, maps). It seems a lot of the XML syntax is fluff when representing the information we need to store/transport. This is of course of an over-simplification of the subject-matter, but I can’t help thinking putting more effort in making object oriented functionality available throughout the software environments we work in (not just the pure coding areas) would be a win in the long run.