It’s worth watching for, as indications are that X# would be used to treat XML as a first-class citizen in the .Net programming arena. Read the article at TechUpdate.
It’s worth watching for, as indications are that X# would be used to treat XML as a first-class citizen in the .Net programming arena. Read the article at TechUpdate.
Only microsoft would turn a markup language into a programming language. XML was designed for documents, like HTML. Would you want your web browser written in HTML? Really? Me too!
Is Windows ready for the desktop? I think not — not with a vital feature like XML missing.
Only in the commercial software world is stuff like this a “mistery”. Open source projects are not shrouded in vaporware.
I respectfully suggest that you may have misunderstood.
One of the background murmurings in the community for years has been a move towards a more powerful view of XML as the InfoSet, with the XML documents we are all familiar with as being (one) serialized form of that infoset.
As you can see from the referenced articles, there are a bunch of research projects, both in academe and the commercial world, where people are looking at developing a couple of key practical things in this area:
1) a language to deal with associative information structures 2) effective serialization technology 3) effective search technology
Each represents an important step on a path which is leading us…somewhere… I’m not sure where, yet.
We’re definitely on this path, though – we’re seeing traditional relational databases iterate towards the second and third goals, and it sounds like X# (and others) could be part of the solution to the first. However, the problems with associative information are significant for traditional data management techniques.
If I were to guess where we are going? We are moving to a new set of paradigms which are taking us perhaps from a ‘data processing’ to an ‘information management’ approach to applications development. We are also becoming more ‘services’ and ‘information’ rather than “program data” and “program function” orientated. These are subtle distinctions that we are still struggling to understand and of which the implications are still emerging.
One emergent property of software development over the past 10 years has been a dependence on metadata, runtime inspection and code generation; I suspect that the solution to the problems I alluded to previously will be found down this road.
And to have a quick moan at the end: many commercial companies have fantastic researchers in this area (not least some of the folks in the MS labs just down the road from my office here in Cambridge), and they are contributing heavily to the body of knowledge in this area (they publish academic papers the same as anyone else). So please stop this petty ‘non-commercial/commercial’ sniping in an area that is very much at the bleeding edge of academic research. It really is pointless.
well i can see a GNU R# popping up… based around the future-enabling, business workflow smoothing, productivity boosting, and fully automatic personal relationship managing RDF.
but seriously…
xml… blaaaaaa
You are kidding right?
-G
Damned Bill, this guy is incredible !
I just hope that the mysteryware will be a little bit cheaper than the vaporware… And while i indulge in wishful thinking, less bugs and more documentation will be fine too, and… let’s talk, some compatibility…
After all, the first of april is not so long ago ;-)))
With X#,
— the new file system for Longhorn can be called the “#X-Files”.
— the new Microsoft slogan can be “the answers are in here… somewhere”
And this just scratches the surface. X# is definitely the way to go, if only for the marketing. Oh that’s right. It’s only about the marketing. So even better!
Because if you read the article you woul know that X# is about replacing xsl stylesheets, not turning xml into a programming language.
And anyone who has messed around a little with xsl knows it’s a very weird, unnatural and really obnoxious language, so a replacement is welcome.
The article says that it is *not* likely to be a replacement for XSL stylesheets – and has more to do with schema and the InfoSet.
more proprietary lock-in from the folks at MS, like we didn’t have enough already…..
Oi. Why is it that some people seem to think that any new feature or application that Microsoft adds- dare I say invents [1] – that people just gripe about how it’ll cause vendor lock. If someone else would’ve done the same thing, people may talk about why the feature or new app was dumb or why it could be useful… but when MS does it, everyone freaks out about proprietary lock in.
Guess what? Anyone who wanted this feature could just implement it. After all, if it was good enough to worth using the MS implementation, one imagines that it would be worth having a version that ran on non-MS platforms.
I personally don’t think that any of us can judge the usefulness of this X# very well- I am inclined to wait until there is something to judge. Imagine that! It sounds like it could be useful, but rather than having a new language, I’d rather have a really good XML library that provided the same functionality in a way that was just as natural to use for any .NET language. Within the confines of C-ish languages (C#, Java), providing an XML-specific syntax that both a) fits in with the rest of the syntax and b) isn’t a pain in the ass (like much of Algol-derived languages already is!) may be a bit hard, but I think it is worth trying. Something like the native XML data manipulation (I saw something about it on lambda.weblogs.com for JavaScript) *might not* be so bad.
[1] On occasion!
Oi. Why is it that some people seem to think that any new feature or application that Microsoft adds- dare I say invents [1] – that people just gripe about how it’ll cause vendor lock. If someone else would’ve done the same thing, people may talk about why the feature or new app was dumb or why it could be useful… but when MS does it, everyone freaks out about proprietary lock in.
Guess what? Anyone who wanted this feature could just implement it. After all, if it was good enough to worth using the MS implementation, one imagines that it would be worth having a version that ran on non-MS platforms.
I personally don’t think that any of us can judge the usefulness of this X# very well- I am inclined to wait until there is something to judge. Imagine that! It sounds like it could be useful, but rather than having a new language, I’d rather have a really good XML library that provided the same functionality in a way that was just as natural to use for any .NET language. Within the confines of C-ish languages (C#, Java), providing an XML-specific syntax that both a) fits in with the rest of the syntax and b) isn’t a pain in the ass (like much of Algol-derived languages already is!) may be a bit hard, but I think it is worth trying. Something like the native XML data manipulation (I saw something about it on lambda.weblogs.com for JavaScript) *might not* be so bad.
[1] On occasion!
Oi. Why is it that some people seem to think that any new feature or application that Microsoft adds- dare I say invents [1] – that people just gripe about how it’ll cause vendor lock. If someone else would’ve done the same thing, people may talk about why the feature or new app was dumb or why it could be useful… but when MS does it, everyone freaks out about proprietary lock in.
Guess what? Anyone who wanted this feature could just implement it. After all, if it was good enough to worth using the MS implementation, one imagines that it would be worth having a version that ran on non-MS platforms.
I personally don’t think that any of us can judge the usefulness of this X# very well- I am inclined to wait until there is something to judge. Imagine that! It sounds like it could be useful, but rather than having a new language, I’d rather have a really good XML library that provided the same functionality in a way that was just as natural to use for any .NET language. Within the confines of C-ish languages (C#, Java), providing an XML-specific syntax that both a) fits in with the rest of the syntax and b) isn’t a pain in the ass (like much of Algol-derived languages already is!) may be a bit hard, but I think it is worth trying. Something like the native XML data manipulation (I saw something about it on lambda.weblogs.com for JavaScript) *might not* be so bad.
[1] On occasion!
My apologies for the million posts- Safati was telling me it couldn’t get to comments2.php (or whatever), so I kept pressing submit figuring it out work eventually. Evidentally it was working the whole time! UFF!
C#, J#, now X#
Then they’ll have to start using shift-4 instead of shift-3,
e.g. M$
Is it just an impression, or is this “lock-in” argument being over used recently. I don’t remember it being used as zealot argument 1-2 months ago, now I see people arguing with it in every news about MS. Stupid.
I think the reason people are getting worried about lock-in is that Microsoft is enroaching on fundementally different software markets. Back when MS was just making applications, at least standards themselves were still independent. For example, Microsoft’s implementation of TCP/IP is a little bit non-conformant. It’s implementation of C++ (Visual C++ 6.x) was for the longest time *very* non-conformant. But at least C++ and TCP/IP were still independent, and belonged to no-one*. But now, Microsoft is getting in on the standards game, and that’s scaring a lot of people. People remember the whole D3D vs OpenGL mess, and now that Microsoft has left the ARB, while holding some important OpenGL patents, the s**t has hit the fan. People are, justifiably, leery of their further involement in making standards.
PS> The whole idea of a company owning a language is stupid. To CS people, it would be like asking a mathmatician what company owns calculus!
Well, if you chose X# for processing your XML data, you’re _actively_ making the choice to lock yourself onto the .NET framework.
So that lock-in argument doesn’t pull here.
But if I were to choose to use OpenGL, which is an open standard, I am now sweating because of Microsoft’s patents on OpenGL.
They screw those that don’t even use their stuff…
Some of the comments I’ve read seem to suggest that XML isn’t in .NET. On the contrary, it’s absolutely pervasive. Especially when dealing with configuration, it’s virtually impossible to get away from it. (And who would want to? I love it.)