McGrath: It's very likely. There's always been this mismatch between the view of the world that XML espouses and that of mainstream programming languages. Simply put, there are two main views of data structures in the industry, and there have been since the 1970s: programming languages can be structured around objects, which is the way C++, Java and Python work, and there's also the view that data can be structured around tables, which is the way relational databases have worked. But there's a mismatch between both those views and XML.
Why doesn't XML conform to those paradigms? McGrath: It doesn't fit into a traditional table or object situation.
XML has the most affinity with functional programming languages, and those go back to 1959. Arguably, XML is just a modern incarnation of a language called LISP that was invented back then by John McCarthy at MIT.
What's happening today is developers, when facing the need to process XML, go through a number of hoops to make XML fit their programming environments. If they're in a programming environment like SQL, so they'll do their best to make it look tabular. If they're programming environment is something like Java or Python, they'll try too hard to make it look like objects. In both cases there's a lot of work you need to do; you can't just import an XML file and magically have it available to your program. You have to first put it through some sort of transformation, which requires work that is unnatural or unwieldy.
McGrath: This is just pure conjecture, but when they say a data-oriented language, they probably mean a language that's more LISP-like. I suspect they're aiming for a development language where developers could, in one or two lines of code, import an XML document into their program and naturally access the content of that XML file without having to turn it into a collection of tables or objects.
Since today XML is being wrapped into IDEs so that things are more automated, what do you think the language would be like?
McGrath: I suspect the language will be LISP-like, in that it will blur the distinction between programming code and data. One of the great innovations of LISP was to treat chunks of code and chunks of data as the same thing. To a LISP program, a piece of programming code is effectively just a piece of data, and although it takes a little bit of getting used to, even for a seasoned programmer, it's a powerful idea to use chunks of programs as if they were chunks of data. Mainstream languages have a clear divide in that a program is a program and data is data, and there's a big gulf between the two.
"You can't just import an XML file and magically have it available to your program. You have to first put it through some sort of transformation, which requires work that is unnatural or unwieldy." -- Sean McGrath
Could this replace or hinder another major development language?
McGrath: No, not to my knowledge [because] I don't know of any other company that's pursuing functional programming languages as mainstream technology, and perhaps this will change that.
Who would benefit the most from a new language like this, and who would be hurt most?
McGrath: I don't think anyone would be adversely affected. I would be looking forward to it because the time has long come for something like this. It's not like X# is going to be something radically different. The power behind the theory of functional programming languages for XML has been well known for some time, but it's been on the periphery.
I suspect the immediate impact will be in the Java community, because it would realize that it needs something like this. The benefits from a programming standpoint will be dramatic, but it involves looking at the world in a different way. With the absence of a large vendor backing it, it takes a lot to get something like that going. The fact that Microsoft backed XML in the early days had a major effect. By 1998, the spec became a mainstream technology.
Can you describe some instances in which a language like this might be used?
McGrath: I think it would be a huge help for Web services because there's a debate raging as we speak about what Web services really are. One way of viewing them is as a way to allow computer programs to talk to other programs over the network, basically one piece of computer code invoking another piece of computer code. But another way to view them is as pieces of application software sharing data with other software applications, and that's the document style of Web services. Basically, if you treat a Web service as remote procedure call, it in effect is just a stripped down version of CORBA, which is how people were addressing these problems 10 years ago. The real power of Web services is around sending data, not pieces of programming code.
As a programmer, you have to put an emphasis on how you easily get this data and easily transform the data from one language to another. What you need is a good transformation language to do that, and that's where I think X# could be heading.
Strategically, why would Microsoft be looking to develop a language like this?
McGrath: It helps make the case for .NET being something very different technologically from what has come before. It makes the case for saying that .NET supports XML from the ground up, rather than having XML support by means of the object-oriented worldview or the tabular worldview.
I suspect they're thinking [that,] with X#, manipulating XML structures would be as easy as manipulating standard data types, like strings and integers and so on.
FOR MORE INFORMATION:
CLICK to ask expert Sean McGrath about X#
CLICK for news: Insiders say Microsoft prepping new X# language
CLICK for more articles by News Editor Eric B. Parizo