Remembering the Future

Longhorn SDK Annotations Microsoft has added a new experimental facility to the MSDN library. The Longhorn SDK can display extra content from external sources alongside Microsoft's own documentation. At the PDC, Microsoft only showed one part of this feature: the discussion forums associated with each MSDN page. However, you can also choose to view annotations from selected external sources. Working closely with Microsoft, O'Reilly has seized upon this new feature to deliver its own, independently written commentaries on selected Longhorn SDK documentation entries via an RSS feed hosted at oreilly.com. . . . Note that annotations currently work only on the web-based version of the SDK. You will not see them on a locally installed copy of the SDK documentation. They also require version 1.1 of the .NET Framework to be installed on your machine, and they are only supported when using Internet Explorer.

A Group Is Its Own Worst Enemy If these assumptions are right, one that a group is its own worst enemy, and two, we're seeing this explosion of social software, what should we do? Is there anything we can say with any certainty about building social software, at least for large and long-lived groups? . . . So there's this question "What is required to make a large, long-lived online group successful?" and I think I can now answer with some confidence: "It depends." . . . Social software is like that. You can find the same piece of code running in many, many environments. And sometimes it works and sometimes it doesn't. So there is something supernatural about groups being a run-time experience. . . . There are, however, I think, about half a dozen things that are broadly true of all the groups I've looked at and all the online constitutions I've read for software that supports large and long-lived groups. And I'd break that list in half. I'd say, if you are going to create a piece of social software designed to support large groups, you have to accept three things, and design for four things. . . . 1. the first is that you cannot completely separate technical and social issues. . . no one could fork the conversation between social and technical issues, because the conversation can't be forked . . . 2. Members are different than users . . . 3. The core group has rights that trump individual rights in some situations . . . the core group needs ways to defend itself . . . 1. If you want a good reputation system, just let me remember who you are. And if you do me a favor, I'll remember it. . . Users have to be able to identify themselves and there has to be a penalty for switching handles . . . 2. Have to design some way in which good works get recognized . . . 3. Three, you need barriers to participation . . 4. And, finally, you have to find a way to spare the group from scale. Scale alone kills conversations, because conversations require dense two-way conversations

Yes: From monolithic to grid No: Grid Supercomputing: The Next Push Maybe: Distributed Computing Economics

So let me declare right now Eric Lippert's Rich Client Manifesto: The thin-client multi-tiered approach to software development squanders the richness available on the vast majority of client platforms that I'm interested in. We must implement tools that allow rich client application developers to attain the benefits of the thin-client multi-tiered model. That's the whole point of the .NET runtime and the coming Longhorn API. . . . Suppose you were going to design a language for thin client development and a language for rich client development. What kinds of features would you want to have in each? For the thin client, you'd want a language that had a very simple, straightforward, learn-as-you-go syntax. . . . In short, the language should enable rapid development of simple software by relatively unsophisticated programmers through a flexible and dynamic programming model. OK, what about the rich-client language? . . . In short, a rich-client language should support large-scale development of complex software by large teams of sophisticated professional programmers through a rigid and statically analyzable programming model. Complete opposites!

Workflow is just a Pi process A breakthrough in the representation and execution of business processes inspired by the Pi Calculus

Severe and well acknowledged problems of Workflow Management Systems stem from their rigorous and formal nature. Implementations of workflow tend to be coercive, isolationistic, and inflexible; whereas the natural interaction of people frequently incorporates flexibility, opportunistic behavior, social awareness, and compromise . . . . The application of contemporary workflow management systems is not always able to cope with ill-defined and unstructured environments. In practice, workflow technology often lacks flexibility, because it is trapped in a control flow paradigm. Workflows should not be driven by pre-specified control-flows but should be data- or information driven. -- Ijme Schilstra, BPM’03, Eindhoven

See also: this Previous Entry

When shouldn't you use XML? XML Sucks

The Big Here and Long Now

‘Now’ is never just a moment. The Long Now is the recognition that the precise moment you’re in grows out of the past and is a seed for the future. The longer your sense of Now, the more past and future it includes. It’s ironic that, at a time when humankind is at a peak of its technical powers, able to create huge global changes that will echo down the centuries, most of our social systems seem geared to increasingly short nows. ... Since this act of imagination concerns our relationship to time, a Millennium is a good moment to articulate it. Can we grasp this sense of ourselves as existing in time, part of the beautiful continuum of life? Can we become inspired by the prospect of contributing to the future? Can we shame ourselves into thinking that we really do owe those who follow us some sort of consideration – just as the people of the nineteenth century shamed themselves out of slavery? Can we extend our empathy to the lives beyond ours? ... And what is possible in art becomes thinkable in life. We become our new selves first in simulacrum, through style and fashion and art, our deliberate immersions in virtual worlds. Through them we sense what it would be like to be another kind of person with other kinds of values. We rehearse new feelings and sensitivities. We imagine other ways of thinking about our world and its future.

So what about Longhorn?

Yesterday's post on Longhorn got a fair number of reactions. Most of the folks who left comments were indignant Macintosh users. I agree that today Mac OS X is probably a superior operating system to Windows XP. That's one of the reasons that I asked for a Mac OS X machine as my official OSAF box. I wasn't talking about today. I was talking about tomorrow.

It's not about Mac vs Longhorn or Linux vs Longhorn

I have to say that I am impressed by the vision for Longhorn. It's not going to get us the Knowledge Navigator (sorry Scoble). I'm impressed with Microsoft's willingness to make such a risky play. Rewriting a huge amount of system functionality with new APIs in managed code is fairly risky. But if they succeed, they are going to end up with an environment that will be pretty nice to program in, and there'll be some cool features in there. Once they get everything into managed code, people working in predominantly unmanaged environments are going to be hard pressed to keep up. To me the real question isn't about Microsoft and Longhorn, it's about the alternative platforms, Linux and the Macintosh. The Macintosh is tough because Apple is basically saying "hey, just trust us to keep doing cool stuff". And they are doing cool stuff, there's a lot of nice stuff in Mac OS X. But let's be honest, most of this stuff is just NextStep dressed up a little bit nicer. We still have C/Objective-C/C++ at the core. We need more than that. Linux is even worse off. Now I love Linux, but when I compare the Longhorn story with the Linux story, I get scared. Look at things like this. Operating system kernels are commodity software. The interesting stuff is moving up the food chain.

Microsoft's Peculiar Profit Obsession, .NET, and What It All Really Means

But DRM also gives Microsoft added power in the computer and electronics industries, especially with the code portability Andy mentioned.  Remember, IL ultimately makes .NET and Windows hardware independent, decreasing Microsoft's dependence on Intel and increasing its power over Intel -- the power to give and to take away.  There are instances where Microsoft might want to move away from Intel.  Redmond has not done a very good job of putting its software on large-scale servers, for example, largely because its hardware partner doesn't scale well.  We're seeing Intel-based servers now with up to eight CPUs, but that's about it: Above eight the increased overhead means it isn't worthwhile, so we do clustering, instead.  But now Microsoft is flirting with IBM precisely because IBM's Power architecture scales beautifully.  If Microsoft wants to grab one of the last pools of profit it doesn't currently own -- high end corporate computing -- putting .NET on IBM's Power and PowerPC are a key.

It works at the bottom of the market, too, where IL's portability means Microsoft can drop old platforms and move to new ones primarily on the basis of compliant partner behavior.  Imagine a game machine or a set-top box that didn't embrace Microsoft's DRM scheme.  Well, it would be perfectly in keeping with Microsoft behavior to just drop those hardware platforms in favor of others that were more cooperative.  Either buy Redmond's DRM technology (ultimately giving Microsoft the transaction business, remember) or Microsoft might ignore your platform into oblivion.

But what happens when Microsoft has all the computers, all the video games, all the set-top boxes, all the PDAs, all the mobile phones, when it has conquered the transaction business and holds all the money?  That leaves only one more industry I can think of for Microsoft to enter that is profitable enough -- pharmaceuticals. Would you buy drugs from Bill Gates?

No dynamic XAML? Here are some excerpts:

XUL is based on a set of Mozilla specific foundation objects. Java applets are based on a set of Java specific foundation objects. Flash programs are based on a set of Flash specific foundation objects. SVG programs are based on a set of SVG specific foundation objects. I just don't see how XAML threatens the "standards" of the web just because it is based on its own specific set of foundation objects. Posted by Invalid Assertion

My not-to-hidden agenda here is simple - dynamic applications should be dynamic on the client. The server should send data - either through web services, database access, or any other wire protocol - and the client should consume that data and generate UI. The model of a server trying to generate the correct display for a client is just broken. -- Chris Anderson (Avalon Core Developer)

XAML is a markup language that can be used on Longhorn for many things including creating desktop apps, web pages, and printable documents. -- Rob Relyea (Avalon Program Manager, XAML "Spec Owner")

What does this mean? It means that you could use XAML as the backing format for an interactive design tool that lets you design programming logic graphically. Or maybe it lets you design complex business orchestration scenarios. Or whatever. The designs could then be serialized to XAML and then compiled into CLR assemblies. X# anyone? Posted by Invalid Assertion

Yes, you can always ship your application/framework with a runtime compiler instead of a runtime interpreter and make it all the same. The question is does it make sense to do it. Downloading JScript as a source file and then interpreting it in the browser at runtime is a monstrosity. On the other hand, compiling markup that does nothing else than specify the layout and the appearance of your UI is a monstrosity too. You should use the right tool for the job. Procedural code should always be statically compiled, and it should be possible to interpret declarative markup at runtime.

I did not get myself very familiar with the new XPathDocument class, but I think this class will allow writing XML directly into a document instead of using the DOM methods. It should be the same with XAML. Also, it should be possible to navigate the Element tree using XPath. For example: Button b = dockPanel.Item(“xpath_expression”) This, together with the DHTML style editing, would be the killer features of XAML. Posted by George Mladenov

From Sam Ruby (IBM)

It is nice to see Rob Relyea responding to my Avalon question.  And to see Mike Deemback in the blogosphere and responding respectfully to Joe Gregorio's rant.  And John Lam categorizing the Ant communityreaction to MSBuild.
What I believe we are seeing is domain experts seeking each other out.  Crossing organizational and philosophical boundaries.

One idea that has accured to me as a result of the post PDC newblitz is the difference between qualitative and quantitative change. Qualitative change tends to add features without changing values or basic structure, qualitative change, changes our values as well as the models we use to intepret what we do. When qualitative change is successful, it should actually simplify how we understand and do our work. To me this implies that if MS is able to capture the attention of the programmer community, an important part of this process of change will happen long before Longhorn goes into production. If they are successful, it will almost immediately change the value and relationships between our current concepts and work, and change the way existing tools are used to develop programs. Concepts like attribute based programming, Xpath based data manipulation, and declarative programming approaches, which are supported to some extent in existing tools, will be given a boost. Approaches that are based on DOM, SAX, and remote procedure calling will likewise be deprecated. This also relates, to some extent to the concept of FUD (Fear Uncertainty and Doubt). For example, Reporting Services, which will be available by the end of this year, will probably destroy one of MS's longest and closest remaining business partners. There were almost no vendors at the PDC, with the ironic exception of IBM, who had recently acquired Rational (the second largest MS development tool which may now be under attack by MS Whitehorse technology). I did talk with a few vendor attendees, and they were all visibly shaken. Java, which has been struggling to get its Java Server Faces technology out of committee, to compete with ASP.NET (introduced by MS in 2000), will probably quietly shift their focus to Java Desktop Network Components (JDNC). This is an obscure research concept that SUN has been working on, but that may now have to evolve to compete with MS XAML technology. IBM will also have to accelerate its own XQuery support in DB2. There is also a cultural effect. After having gone to several Java Conferences, there where two glaring differences that are taboo to notice or talk about. A large part of the dialog at Sun One, was dedicated to a ritualized demonization of MS. At PDC (my first MS conference), I never heard a negative comment about Java. In fact, there were several acknowledgments of innovations from Java that have been or will be incorporated into the MS platform. In some ways, the industry domination by MS has resulted in a kind of fundamentalism, that is not unlike the current developments in the Moslem World, where its leadership in science and the arts has stagnated under the domination of Western monoculture. In fact I actually share many of these concerns about both the MS black hole of product integration, and the Western monoculture of materialism. But it worries me when Java is defended in increasingly emotional and ethical/cultural terms. I also think that this will continue to be a problem for managers in IT organizations, with both Java and MS development shops, where defection between camps is enforced through many subtle forms of intimidation. This leads to fewer-and-fewer people having knowledge of both technologies. InfoWorld columnist Jon Udell has very interesting comment on a related topic: Skepticism, cynicism, optimism As for the other Taboo subject, while my organization has done better than most, I will just leave this link. Microsoft monks Everything seems pretty normal and nice, save for one thing: Where's all the women?

Organizational Blogging I got an email from Thomas Burg in Austria asking for any hints on introducing blogging to an IT organization. Here's what I told him:

1. Don't do it if you're not prepared, as an organization, to speak the truth. Blogging promotes, but also requires to some extent, a culture of candor.
2. Start small.
3. You need an organizational leader to set an example.
4. Set up the infrastructure, buy licenses, etc. early and make it easy for people to get started. I bought Radio licenses for everyone. You could choose Moveable Type as well, but I think Radio has some definite advantages: (a) it includes the hosting that's outside the organization and (b) it brings a sense of user ownership since it lives on the desktop.
5. Set a few guidelines (to show you've thought about them) but don't set too many since they will stifle people's creativity.
6. Create an aggregator that reads the RSS feeds from the various blogs and presents them for people who don't use blogs and aggregators. Point at it and reference it whenever you can to drive traffic to the information in the blogs.
7. Enable comments to encourage participation through feedback and interaction from those who don't write blogs.
8. Be prepared for some people to be very threatened and offended when you speak the truth. Be proactive in preparing the people who they'll complain to so that they understand what you're doing and what the goals are.
9. Pick out two or three people who like to write and give them special encouragement to get their blogs going. Meet with them often and form a "support group" of sorts to get things going.

Not all of these will work for everyone, but the advice is hard won. These are things I did that worked or things I wish I'd done. If you'd like to talk with me about doing this in your particular situation, send me an email, or comment below.

A Guide to Developing and Running Connected Systems with Indigo Indigo is a set of .NET Framework-based technologies for building and running connected systems. Indigo is the next step in the evolutionary path that started with COM, COM+, and MSMQ, and continues through .NET Remoting, ASMX, System.Messaging, and .NET Enterprise Services. Indigo subsumes these technologies and offers a single unified programming experience for developing services using any CLR-compliant language.

About Indigo

At the PDC, I was in charge of learning what was Indigo about, so I went to all Indigo sessions. Most of Don Box's sessions where more about philosopy (justifying MS's shift to the SOA model) than about technology (just have a look at his slides to see what I mean), but quite interesting anyway. Other sessions by Doug Purdy and Steve Swartz where more technical and more useful for understanding Indigo's architecture.

The first thing to say about Indigo is that it does not contain revolutionary technology. It just takes the best of ASMX, WSE, Remoting, Messaging and Enterprise Services to create a new framework for building enterprise applications based on a Service Oriented Architecture model.

However, the great value of Indigo is that it integrates in a coherent way all those diverse technologies, by providing a common communication stack, common security features, transaction management and extension mechanisms.

Posted by Gerald Bauer

What if the JRE shipped with XUL support built in, eh? Or if there was an XML syntax to create SWT components. The whole Java UI design methodology harkens back to X toolkit coding, programatically creating widgets and layout controllers. The closest we have is Jelly.

You might wonna check out the Luxor XUL Toolkit @ http://luxor-xul.sourceforge.net for creating Swing or SWT widgets using XML. For more alternative XUL motors/browsers/runtimes in Java check out the XUL Alliance @ http://xul.sourceforge.net

I am also going to observe that it is a shame that Sun haven't got a good Java alternative.

Well, Sun hates XUL because evidently it competes head-on with the upcoming Java Server Follies (JSF) package. See the Viva site for more insight @ http://viva.sourceforge.net/action.html Also note that Sun has a XUL alternative in vapourware state called Java Desktop Network Components (JDNC). See the XUL News Wire story for more insight @ http://article.gmane.org/gmane.comp.lang.xul.announce/29

From Don Box See Also In the case of XAML, "wire up" means one or more of the following: 1. Define a new CLR type. 2. Instantiate existing CLR types. 3. Set the values of properties. 4. Register event handlers. In the case of #1, you're really defining PART OF a CLR type - the XAML compiler allows you to combine a VB or C# (or ...) source file using the partial class support in the new whidbey compilers. Is this clear?

From IdentityCrisis

WhiteHorse: The most fascinating new feature I have seen from a deployment issue is WhiteHorse. It is not a builds program like Msbuild, but more importantly it is a modeling/framework using policies and gui representations of the logical and physical layers of your enterprise. Whitehorse can enforce these policies on a developer box. Most enterprise deployments encounter severe bugs at deployment because of the developers ignorance of their final environment. I have overcome these issues by completely understanding the deployment environment and then reproducing that environment on in my developer environment. That can manifest itself as many machines to gain physical separation (firewall issues and remoting realities), developing with developer tool on the actual platform server OS(such as Windows 2003), and enforcing authentication and authorization representing the deployed environment. Well I would like to have all of that on my portable laptop. Yes my lap top would weigh 85lbs and cost 10% of my yearly income, maybe 20% some years. I usually try to mitigate the cost of multiple machines using VM Ware, but that also demands many hard drives to get any kind of performance at all. You try to carry three hard drives on your back. If WhiteHorse can deliver I will save a lot of money, not to mention a nice pretty diagram that integrates in the IDE and helps me compel fellow developers to think about the platform they are developing for.

Longhorn glossary Looking at the number of posts I want to do on the new Microsoft technologies released at the PDC, I thought that a 'Longhorn'-Era glossary (originally posted here) would be helpful in decoding some of the terms I may use in my blog entries. Here they are in no particular order:
"Longhorn" (code name): The next major release of the Microsoft Windows operating system. This is slated for release around 2006 (possibly Q3/Q4 of 2005) if the beta testing goes well.
"Aero" (code name): Longhorn 3D-rendering user interface
"Avalon" (code name): Graphics presentation technologies in Windows "Longhorn" that provides a unified architecture for presenting user interface, documents and media in the system.
ClickOnce: Technology in Windows "Longhorn" designed to speed and simplify deployment of applications.
"Indigo" (code name): .NET communications technologies in Windows "Longhorn" designed to build and run connected systems.
"Palladium" (code name): Microsoft's Next Generating Secure Computing Base (NGSCB) secure-OS subsystem that will debut in Longhorn
SuperFetch: Technology in Windows "Longhorn" designed to help applications launch more quickly.
"Whidbey" (code name): Next generation of the Microsoft Visual Studio system of software-development tools.
"WinFS" (code name): Next-generation search and data storage system that provides a unified storage model for applications running on Windows "Longhorn."
WinFX: Programming model Windows "Longhorn," used by software developers to build applications for the Windows platform. This is a superset of the current .NET programming model.
"Yukon" (code name): The next generation of Microsoft SQL Server database software - expected to ship second half of 2004.

So, why did I bother to write this? Good question. Sometimes I read these rants about how open source automatically obtains magical god-like quality. It's true in a twisted way: The ten open source projects that religious open source advocates will choose to point to probably have better quality than the average non-open-source product. My advice is to look at open source with an open but critical mind, the same way you should look at non-open-source products. Don't get caught up in the religion, because in the end, there's still poison in that kool-aid. Open source can benefit us all -- and I believe that it has benefited and continues to benefit us all. Let's not ruin it by attributing magical religious properties to it. Use it if it works for you. Contribute if you can and you want to. Report back bugs to help it improve. Ask for useful features. Be thankful for it being there. Just don't lie to yourself and others about attributes that open source does not intrinsically have. It still takes a strong vision, continued focus, great engineers, hard work and long-term dedication to make good software. There simply is no silver bullet.

Julia Lerman I cannot believe Don Box said at PDC that Indigo is being designed so that “even VB developers” will be able to use the more complicated features like security. Did anyone notice the loud groans in the room when he said that? aaaaaaaaaaaaargh! Believe me I really really really understand that there are a lot of people who use VB as a rad tool and that MS keeps them at the forefront of their thoughts when designing features for VB, but there are other types of developers who happen to use VB as their primary language who actually do more than use the wizards. And Microsoft needs to remember that before they make sweeping statements like that. It is insulting and it degrades us in the developer community. I'm not a plumber. I'm the first to admit it. But that doesn't make me a “mort“. Don Box Responds

Yes, the CLR and C# level the playing field so people who like case-sensitivity and curly-braces aren't bogged down in tedious detail, but VB is still a big deal and honestly has at least one killer feature that C# and C++ still lack. I'm reminded of the following verse which still has relevance today: My language, 'tis of thee, Sweet grammar of simplicity, Of thee I sing. Language where new things are tried, Language of Bill Gates' pride, From every mountainside, let VB ring

More MS humor

From Panopticon Central

Hey. I'm not a newbie or a script kiddie. And I don’t get paid less than other programmers, or only work on UIs, or write email viruses. And I don't know BillG, SteveB or EricR from Microsoft, although I'm certain they're really, really nice. I have a Handles clause, not a += expression. I speak VB and VBA, not C#. And I write it 'For Each,' not 'foreach.' I can proudly type names using any capitalization I like. I believe in line continuations, not curly braces; colons, not semicolons. And that ‘With’ is a truly proud and noble statement. CType is a cast, ReDim IS a statement. And it IS written ‘Mod’. Not ‘%’. ‘Mod’. BASIC is the oldest Microsoft language, the most popular programming tool in the world and the best part of Visual Studio. My name is Mort, and I AM A VB PROGRAMMER!

Declarative GUI prior art

From Jon Udell When I mentioned Apple's Knowledge Navigator video in a blog posting recently, it attracted an unusual amount of attention. Clearly many people long for the kind of human/computer interaction so clearly imagined in that video. This week's InfoWorld column asks the question: How can today's technologies deliver some of the kinds of intelligent assistance that we crave? My conclusion was that the principles of service-oriented architecture can apply on the desktop as well as in the cloud. If local applications exchange XML messages with one another, as well as with the services cloud, then the same techniques of observation and intermediation can apply in both realms. It's intriguing to note, in this vein, that Longhorn's communication subsystem, Indigo, aims to make standards-based XML messaging work efficiently across a broad range of topologies. In an article just published on MSDN, Don Box writes: Indigo makes service-oriented programming viable in a broad spectrum of mainstream applications. By taking advantage of various facilities of both the CLR and Windows, Indigo can be used in performance-sensitive situations such as single-host and even single-process integration. This scale-invariance makes Indigo-based services accessible to a broader range of deployment options than current technologies. [A Guide to Developing and Running Connected Systems with Indigo] Excellent! Five years ago, I got excited about the idea that a local Web server could enable a peer-to-peer style of computing in which user-facing applications and machine-to-machine services were made of the same stuff and therefore highly synergistic. I'm still jazzed about a unified service-oriented model, and look forward to seeing Indigo help make it a reality. So, in case you were wondering, I am not a complete black helicopter conspiracy theorist on Longhorn!

It looks like Longhorn may be borrowing some ideas from topic maps Longhorn: WinFS looks cool! The WinFS data storage system used in Longhorn seems cool... A short list of some powerful features

• There is a concept of Items and relations between Items
• An Item is something like a file, a folder, a contact, or a user defined type
• There are two types of relations: holding relationships and reference relationships
• With holding relationship you can model the well known folder hierarchy, but also much more because an item can be "hold" in more than one relationship (although cycles in the "hold" graph are not permitted)
• An item has a reference count of its holding relationships. When it has no more references it is removed from the store.
• Security is on Item level (which could indicate that Yukon, presumably the storage engine in a slimmed down version, has row level security)
• Every store Item has an unique ID that identifies the Item in the store (although not guaranteed over multiple stores)
• WinFS supports: Asynchrony (multiple queries and data retrieval at the same time), Transactions, Notifications (on Item changes, relation changes, and many more subtile things going on), Blob/stream support, Cursoring and paging (a query can result into many Items!)
• A powerful API is available to interogate the store
• Within the API powerful querying and filtering functionality is available
• Also direct SQL queries can be executed on the store for really powerful aggregation and grouping

Longhorn Eats, Sleeps and Breathes Declarative Programming Anyone that has not learned declarative programming definitely need to learn this stuff soon.

Mercury

Mercury is a new logic/functional programming language, which combines the clarity and expressiveness of declarative programming with advanced static analysis and error detection features. Its highly optimized execution algorithm delivers efficiency far in excess of existing logic programming systems, and close to conventional programming systems. Mercury addresses the problems of large-scale program development, allowing modularity, separate compilation, and numerous optimization/time trade-offs.

Mercury on .NET

Around 18 months ago, Microsoft approached the Mercury researchers at the University of Melbourne regarding an opportunity to participate in a research and development effort involving a multi-language platform, under the banner "Project 7". As well as offering access to early development tools, Microsoft offered a substantial grant to fund researchers, an opportunity to stay at Microsoft at Redmond for 3 months to learn the technology (alongside researchers representing other efforts), visits to other implementors working on other languages (e.g. Haskell), and ongoing support, technical conferences, and a stream of snapshots of ongoing work. This work was to remain secret (under a Non-Disclosure Agreement) until they were willing to announce their new platform and reveal its details. They asked for no special intellectual property rights, and indeed except for NDAs no contracts were signed. However, they requested that we provide feedback on what would make the platform better for Mercury, and what criticism (or praise) we (as language designers and implementors) could give on their work. We decided to accept their offer, for two main reasons. First, we have always tried to make Mercury available to the largest possible number of programmers compatible with our means. Distributing implementations on Unix-family platforms reaches large numbers of people, but there are even larger numbers whom it does not reach. The overwhelming majority of these people work on Microsoft platforms and need an implementation that works natively on that platform (i.e. not via systems such as Cygwin). By building a backend that targets .NET we can reach this audience. Second, we have long planned to implement a new backend that generated higher level imperative code than the existing backend (which basically generates assembler in C syntax), and have had fairly detailed designs for this backend. Unfortunately, we had no money for implementing this design, because this kind of work is very hard to get research funding for. The grant from Microsoft has allowed us to build a generic backend that can generate high level C code as well as code for the .NET platform. We expect that in the future it will also generate code for the JVM. (We have received a significant number of requests for a JVM backend.) The vast majority of the work for this project was conducted by Tyson Dowd and Fergus Henderson. Several other people at the University of Melbourne had signed the NDA, however many of the Mercury researchers did not as we saw no point in encumbering the entire group with such legal restrictions. As of the Microsoft Professional Developers Conference last week, this NDA has been lifted, and we can now talk about what we have been working on and the status of this project. This doesn't mean Microsoft is going to ship a product right now -- the development kits that have been distributed are pre-beta releases. But we can talk about it and people using the pre-betas can try out our work.

Brian Jackson - VB.Net and C# Diverging

Paul Vick added that VB.Net will not expose anonymous methods in the Whidbey release, primarily because Microsoft is reluctant to introduce this concept to VB programmers, many of whom are still getting accustomed to the OO concepts introduced in the current VB.Net. I found this very interesting, because it's the most significant example I can think of where VB.Net and C# make such a departure from one another on a core language feature. I'm not totally convinced this is a great idea. VB's watchword has always been productivity, whereas C++ has focused on power. C# is somewhere in between, but leaning, in my opinion, toward productivity. So, if a feature is good for C#, wouldn't it also be good for VB.Net? What does the decision to omit anonymous methods say about the future of language parity in the Microsoft-supported .Net languages?

Another interesting paper by Francis Heylighen I'm a little surprised that this paper doesn't mention blogs, but here is an interesting quote

As such, the web would turn into an intelligent, adaptive, self-organizing system of shared knowlege, structured in a much more flexible and intuitive way than the formal classification schemes conceived by Berners-Lee and others. Unlike material resources, knowledge and information do not diminish by being shared with others (economists call this property non-rivalry"). Since the learning web would make this sharing effortless and free, this enables a positive-sum interaction in which everyone gains by making their individual knowledge and experience available to others, this provides a continuing incentive for further cognitive integration. The web plays here the role of a shared memory, that collects, organizes and makes available the collective wisdom. It achieves this without demanding anything from its users or contributors beyond what they would have had to invest if they were working on their own, thus removing any incentive for free-riding.