With the hype growing to a feverish pitch about the public announcement of Xen, I thought I would share some insight into the knowledge I've had of the language for almost a year and a half. I'm still under orders not to post the video demonstration I have back to my blog (not because the subject matter is Xen, but because apparently the demonstration is internal to Microsoft... I still don't understand this (expecially now that the cat is out of the bag), but it certainly doesn't stop me from sharing some of the information contained in it. This will be an ongoing post as the demonstration is over an hour long, with lots of code samples to boot.
Post a Comment
Looks like C! And, uh, HTML... Great, just great...
That I'm not planning to be in the software industry long-term. Its all just crap. Well-hyped, very polished, crap, but crap nonetheless.
Why is there "hype growing to a feverish pitch" about Xen??? Its a simple hack on C# to make manipulation of XML and SQL easier! Its okay as a temporary measure to increase productivty in a very limited application-domain, but to merit "hype growing to a feverish pitch," I'd expect something fundementally new, and useful to more people than just those doing business application logic!
All the "innovators" working at Sun and Microsoft just need to sit there and read *every* paper on Citeseer. Then they need to go and *implement* Steal a clean object model from Smalltalk or Dylan. Steal continuations from Scheme. Steal procedural macros from Lisp. Steal a proper static typing system from ML. Steal ideas about prototype-based object-orientation from Self. Steal ideas about provable code from Clean and Haskell. Steal design-by-contract from Eiffel. Steal advanced compiler optimizations like region-inference and boxing-elimination from just about anyone!
I'm going to go sulk now...
What is the point of putting domain-specific syntax candy into the language syntax? Is it to change languages so fast that the competitors can not keep up?
C# has plenty of ways (operator overloading, implicit and explicit type conversions) to create domain-specific "mini languages". They should try to use this instead of putting more and more features into the language itself. They seem not to have learned anything from C++.
I really hope the mono project will not try to copy this monstrosity.
I really hope the mono project will not try to copy this monstrosity.
won't it have to stay compatible?
i would consider the current way that .Net (and most other languages) handles anything XML based to be a "hack"...it's half baked and needs much improvement. will it ever be perfect? probably not. can it be easier to use and have compile time type checking? can extracting data from XML documents be more intuitive? most definitely, and these are some of the fundamental concepts behind Xen. Bear in mind that none of this will see the light of day for at least 2 more years (perhaps orcas, perhaps not), it's just meant to provide an overview of some ideas we can expect from any language (not just C#) in the future as far as XML manipulation is concerned. no doubt other languages will implement it differently, but the basic premise will be the same.
> won't it have to stay compatible?
>
The goal of the mono project is not to be 100% compatible with everything microsoft does. That would be foolish and impossible anyway.
The goal is to provide a very productive architecture neutral software infrastructure for linux. To succeed in this they just have to provide a stable and fast VM, one or more languages that target that VM, and a set of libraries for most tasks.
Compatibility with microsoft .NET is just an added bonus, but if microsoft goes totally berserk and adds gazillions of useless language features to C# to "innovate", it would be much better for mono to ignore this and stick to the ECMA standard.
With any flexible language you should be able to make handling XML very intuitive *without* having to add syntax bloat.
If you have to add something to the core syntax whenever a new sort of data gets favorable, there is something seriously broken with your language.
can it be easier to use and have compile time type checking? can extracting data from XML documents be more intuitive?
---------
Just because it is useful does not make it any less of an enormous hack.
Bear in mind that none of this will see the light of day for at least 2 more years
----------
So what's with the hype and code samples?
no doubt other languages will implement it differently, but the basic premise will be the same.
-----------
No, the basic premise would not be the same. In a language with macros (Ocaml, Lisp, Scheme, Dylan, in the future, Perl 6, maybe even C++ with templates), this would be just another library. You'd have a macro package that handled the new syntax and transformed it to the underlying code. Programmers would just use the macros, and never even realize, or care, that it wasn't part of the native language. Indeed, in most Lisp/Scheme/Dylan, much of the language itself is macros on top of an irreducible core. So you want a new 'for' loop that handles XML documents easily? Just write a macro for it!
Consider what'll happen to Xen when the XML fad dies and a new one comes along. If the XML support is just a library, you would just have an obsolete library. If the XML support is in the language, you have an archaic language feature you can never remove because of backwards-compatibility concerns. This type of thinking is the reason why the C++ syntax is nearly impossible to parse!
"No, the basic premise would not be the same. In a language with macros (Ocaml, Lisp, Scheme, Dylan, in the future, Perl 6, maybe even C++ with templates), this would be just another library."
The funny thing is that as of .NET 2.0 C# itself has all the nessecary infrastructure. It has operator overloading, automatic type conversion and generics. It is not nearly as elegant as the languages you mentioned, but it would definitely be possible to write a very easy-to-use XML library in C#. So it is really strange that they invent yet another language.
But one should not be surprised. .NET has a very good core infrastructure, but the farther you get from the core, the messier it gets.
I dont think the point of xen is to write the complete application, but just the part that connects to the xml/sql. Due to the way the CLR works, I can write a 'wrapper' that connects to the sql, xml, xsl, etc... in a clean 'hackish' way, and then connect with C# to it. XML fades out? no problem. Just replace the implementation of the wrapper from Xen to Yen (for the new Yml format) and C# calls the same functions. Remember that in the CLR it dosnt matter what language you use and you can mix and match different languages allowing you to use 'hackish' languages like xen when they are needed with your regular code.
Macros are very hard to do well, and I dont know if .net is 'virtual' enough to be able to get them that much more descently then the horrible hack c/c++ macros are.
Think of this the same way that perl uses regexs nativly. Even though it is a 'hack' that should sit in a library in any descent language, perl was designed for that! Perl was not designed to be a general purpose language and that is why regexs belong nativly there. Eventhough I love python and hate perl, regexs in perl are so much more natural. (I know python has the same power of regexs, but its more cludgy)
Consider what'll happen to Xen when the XML fad dies and a new one comes along
-----------
i'm pretty convinced (along w/ almost everyone else) that XML is here to stay. why not make it an itegral part of a language? MS has already done so even before Xen...it's a fundamental part of datasets/adapters, remoting, and of course web services. XML isn't going anywhere, and as it's an open spec, languages themselves are forced to adapt to changes.
If the XML support is just a library, you would just have an obsolete library.
-----------
XML support in .Net is already libraries (SQLXml, MSXml, etc), and in essence if/when Xen is incorporated into .Net, it will in the form of libraries as well (namespaces), i doubt that MS would be foolish enough to dump this into MSCorlib, at least i certainly hope not! as for the syntax changing, really what is happening is the introduction of some new keywords, and actually the introduction of generics/iterators/partial types will have a more profound impact on the language itself as no doubt they will be in MSCorlib, but that's another discussion.
No, the basic premise would not be the same. In a language with macros
-----------
well, the 2 most used platforms out there (java and .net) don't have macros, so how exactly would they go about incorporating this?
No, the basic premise would not be the same
-----------
by premise, i meant "idea", not the actual implementation of the idea. the 2 most arcane parts of working with XML data is lack of strong typing when using XML data in a programming language (in .Net, everything is treated as a string), and dificulty extracting (querying) data from XML documents. this is something that absolutely must be addressed in any language that wishes to use XML data...that's the premise :-) each language will do it differently, and they will do it in the manner best suited for that language, but the idea will be the same.
....just as Visual Basic enabled millions of poor programmers to write desktop applications, these new language-things from Microsoft will enable millions of lousy programmers with just a certificate training course to write high powered network applications that access SQL databases, information in XML format, etc.
Who makes the world go 'round? Business programmers who need to get things done quickly or academics seeking clean languages?
If Microsoft hacks together an ungodly language that for at least a decade "gets the job done" for less competent programmers then they will win again as they did with Visual Basic.
Don't underestimate the knowledge that Microsoft gains from the feedback it receives from its incredibly large developer base. These are individuals from every sector of industry --- a better source from which to understand what the market needs than the set of open source developers who still haven't penetrated a lot of market niches.
Microsoft is good at learning what THE AVERAGE DEVELOPER needs.
Java, Mono, etc. users should continue like good Christians doing their own thing and spreading the faith...and eventually Ceasar will convert and purity will reign supreme in the world of software development 
"as for the syntax changing, really what is happening is the introduction of some new keywords, and actually the introduction of generics/iterators/partial types will have a more profound impact on the language itself as no doubt they will be in MSCorlib, but that's another discussion."
But the introduction of generics and iterators will benefit every .NET programmer and not just the people who work mostly with XML. And generics and iterators could not have been done in a library. XML support is easy to do in a library.
What should be done is to use the new language features like generics and iterators to make the existing XML libraries more user friendly.
If you add syntax to a language whenever you think it might be useful, you will end up with a huge unmaintainable mess of a language.
Existing languages really suck for working with databases and xml. This why so many projects end up ducttaping their components together with php, jsp, asp or whatever script language is available. Scriptlanguages are bad: the resulting code is unmaintainable and hard to debug. It has a tendency to accumulate stuff that should be implemented elsewhere and once it reaches a critical mass you have basically only have two alternatives: maintain it (costly) or to abandon it completely (costly).
This is the core (techincal) problem of modern business applications and none of the technologies currently in the market addresses it. Java is nice if you are properly trained but the mindnumbing simplicity of most business applications (open table(s), extract/update/select data, present to user/other applications)shouldn't require such a complex solution. The same applies to the .Net stack of technologies, which, though better integrated, still is pretty complex.
Currently both SUN and MS are talking about simplifying development with tools and new languages. Somehow, I believe MS has a more credible offering at the moment than SUN but time will tell. This Xen thing certainly seems to address some real issues. From the looks of it, you might get a significant reduction of lines of code when using this stuff for business logic when compared to the java/jsp combo or the .Net equivalent (C#/asp). Lines of code mean faster development and less maintenance cost per feature, assuming a constant cost per line of code (various studies confirm that this is true for most current languages).
i'm pretty convinced (along w/ almost everyone else) that XML is here to stay.
-----------
There have been many things that are "here to stay" that are now just forgotten memores.
it's a fundamental part of datasets/adapters, remoting, and of course web services.
-----------
Those things aren't part of the language itself, but the standard library. Language features should lend themselves to a wide variety of uses. For example, reflection allows for adaptors, persistence, RAD tools, and remoting to be built on top of it. Lambdas (which C# 2.0 will, happily, have) allows for generators, function objects, iterators, and objects to be built on top of them. Macros allow any number of domain-specific languages to built on top of them. Building those applications into the language itself is a totally different thing.
i doubt that MS would be foolish enough to dump this into MSCorlib, at least i certainly hope not!
----------
C# does not have a general mechanism for scoping syntax. So any new keywords will get dumped into the global namespace. Further, support for these new keywords, and their underlying semantics, will have to be added to the C# compiler.
well, the 2 most used platforms out there (java and .net) don't have macros, so how exactly would they go about incorporating this?
----------
Macros have been done before in infix languages. They aren't as elegant as prefix macros, but are still very powerful. See Jonathan Bachrach's paper on D-Expressions:
http://www.ai.mit.edu/~jrb/Projects/dexprs.pdf
Further, see Larry Wall's "Apocalypse 4: Syntax"
http://dev.perl.org/perl6/apocalypse/A04.html
Anyway, as tuttle points out, you might not even need full procedural macros for something like this. With metafunctions, C++ with templates might be able to do it too.
each language will do it differently, and they will do it in the manner best suited for that language, but the idea will be the same.
----------
Hacking XML into the language is fundementally different from integrating general support for domain-specific languages into the language. C# is admirably one of the few recent languages willing to go beyond the status-quo of language features. Their support of lambdas, operator overloading, and other features, as well as the "Polymorphic C#" project are evidence of this. C# does not deserve this hack.
All the "innovators" working at Sun and Microsoft just need to sit there and read *every* paper on Citeseer. Then they need to go and *implement* Steal a clean object model from Smalltalk or Dylan. Steal continuations from Scheme. Steal procedural macros from Lisp. Steal a proper static typing system from ML. Steal ideas about prototype-based object-orientation from Self. Steal ideas about provable code from Clean and Haskell. Steal design-by-contract from Eiffel. Steal advanced compiler optimizations like region-inference and boxing-elimination from just about anyone!
First, the papers on citeseer are there to be read. Any respectable language designer *must* go read the literature, and not just citeseer either. This is not stealing, publishing is all about telling others of your work so that it can be *used*.
Second, if you are in academics, you should know better than anyone that actually implmenting and using ideas is the best way to really study them. There are lots of hacky prototypes for different things, but rarely will a protype work with another prototype. Having trade groups pick and choose the most effective ideas and implement them in a single language is invaluable and also the natural way of things. Computer science people do not exist to create tools for businesses and desktop developers the world over to use. Rather they do science.
Finally, business logic makes up a HUGE portion of real everyday programming. Just because you or I do get excited by it, doesn't mean that the many many business logic programmers won't. This site is not about exciting new ideas in computer science, but rather everyday computer systems.
The problem is that C# isn't supposed to be a specialized business-logic language. Its supposed to be the general purpose language that is the future of Windows development.
Yes, I do agree there. Hopefully it will be possible to code to the different ECMA C# specifications and disable the extra gunk.
<!>Compatibility with microsoft .NET is just an added bonus, but if microsoft goes totally berserk and adds gazillions of useless language features to C# to "innovate", it would be much better for mono to ignore this and stick to the ECMA standard.</!>
Well this sounds all fine and dandy this looks more like another OSS excercise in futility. AFAIK Microsoft is the only one really pushing .Net therefore most people writing apps (and therefore apps themselves) will write them using Microsoft tools using Microsoft language additions. Therefore how many programs will be able to take advantage of this No_Microsoft-just-the-standards .Net? I'm betting it'll be few. I think people we'd be better off working with Netbeans to improve the best (IMHO) Java IDE out there... but as it is their free time I -unfortunately- can't tell people what to do with it.
"Well this sounds all fine and dandy this looks more like another OSS excercise in futility. AFAIK Microsoft is the only one really pushing .Net therefore most people writing apps (and therefore apps themselves) will write them using Microsoft tools using Microsoft language additions. Therefore how many programs will be able to take advantage of this No_Microsoft-just-the-standards .Net? I'm betting it'll be few."
A lot of people who write .Net programs will have no need to use XML extensively. Professional developers do not like ugly bloated languages, so they will stick to the standards.
This is not unprecedented: gcc comes with some really nice and (as opposed to this) useful extensions to ansi C++, and even though in some areas gcc has a marketshare of more than 90%, most people just stick to ansi c/c++.
"I think people we'd be better off working with Netbeans to improve the best (IMHO) Java IDE out there... but as it is their free time I -unfortunately- can't tell people what to do with it. "
Oh, the old "Everyone should use java instead" argument. Well, java has no value types. It is therefore extremely inefficient to do numerical stuff like complex numbers or vectors in java. So java is simply a non-option for an important part of software development.
Java might be o.k. for business logic, but it sucks for everything else. Its the COBOL of the 21st century. Nothing more, nothing less...
I wonder if the ultimate goal of microsoft .Net isn't simply to create one big application that would handle all type of database manipulation and data processing. Then programming in .Net would simply consist in setting up your preferences, and then the application would handle all the rest.
There was once a game creation tool called "click n play" where u could create your game simply by clicking on a few icons. Of course you could only create games among predefined type of game, but isn't .Net doing the same by introducing into the language things that are only usefull for a limited part of the programmers ?
Imagine that the C language was used to code OSes as well as word processors, as well as videogames.
Today, it seems like .Net languages are more and more closely related to the type of applications you want to create. Languages are going to be very specialised.
You want to create a web page ? well, then use the HTML.Net brand new language using CLR,
a word processor ? use the brand new MSWord.net language !
a videogame ? use the brand new DirectX.Net language !
an Operating System ? ....buy Windows ! )
The difference between tools and languages are going to be less and less obvious.
Maybe it's a good thing after all...
"The difference between tools and languages are going to be less and less obvious. Maybe it's a good thing after all... "
No. It is not. Domain specific languages are not new. And they are not an invention of microsoft. They are also a huge maintenance liability.
For example if you have a fortran program from 1980 it is not much work to port it to a modern language. But if you have a program written in a domain specific language from 1980 you have a major problem since nobody will know the syntax anymore.
The point is that there are plenty of languages that are flexible enough that you do not need domain specific languages anymore. You can have your cake and eat it too. You can have beautiful and short syntax with a minimalistic language.
The nice thing about having extensible syntax (via macros or other means) is that you have the advantages of a domain-specific language, without having to maintain and deal with a seperate language. As long as the syntax doesn't gratuitously deviate from that of the underlying language, it works very nicely for certain purposes.
"The nice thing about having extensible syntax (via macros or other means) is that you have the advantages of a domain-specific language, without having to maintain and deal with a seperate language. As long as the syntax doesn't gratuitously deviate from that of the underlying language, it works very nicely for certain purposes."
I know. But obviously the majority of software developers don't. I think it would be possible to do most of the syntax candy shown in this article in straight C# by using operator overloading and implicit type conversions. You would need a few more characters here and there, but nothing dramatic. I did something similar for defining sets of inequations in C#.
You seem to have a great deal of knowledge about modern programming language concepts. Maybe you should write an article with some simple examples about it for OSNews. I am sure they would publish it. If you do, I will write an article about uniqueness typing in clean.
I read here that XML is apparently a fad or at least isn't garunteed to stay. I think this notion really, really doesn't matter since the number of XML and HTML projects out there probably outstrips most languages. I can garuntee there are more applications for XML and HTML than there are for smalltalk, lisp, ml, schema and python along with a lot of the other languages that were listed. One of the things that seems to have been forgotten is that HTML is XML. Which means that the billions of pages and billion, if not trillions of dollars invested in HTML and XML is worth many, many languages. XML is here to stay because HTML is here to stay. At least long enough that it's worth these extra language features.
A comment on this attitude against domain specific functionality. There is a difference between the ability to do something and the ability to do something well.
Those that read the circles, triangles and squares article know what I'm about to say already. The object-oriented data model doesn't really work all that well with the XML data model. Read the "polygon" article. It answers most people's questions.
XML isn't a format or a domain specific technology. It's a way of storing data like text files or binary files. It's just another way of persisting data.
And as for the SQL inclusions. SQL has been around almost as long as databases have. How many decades do they have to be around before a language decides they're worth something.
And a final note. Languages currently allow for the simple inclusion of vocabulary (variables and functions). Perhaps it's time to all for the inclusion for the simple inclusion of grammar as well. And no MACROS don't do it. There are many, many reasons MACROS don't work. I think part of it is that they were conceived by the devil.
Orion Adrian
-- "One of the first things mentioned is about declarative languages": mentioned where?
-- "one of the fallbacks of declarative languages": should be "drawbacks"
-- Numerous grammatical and typographical errors, including such basic errors as sentences beginning with a lowercase letter.
I only made it through the second paragraph before giving up. If OSNews can't reject articles that are this badly written, they need to edit them before publication.
"And a final note. Languages currently allow for the simple inclusion of vocabulary (variables and functions). Perhaps it's time to all for the inclusion for the simple inclusion of grammar as well. And no MACROS don't do it. There are many, many reasons MACROS don't work. I think part of it is that they were conceived by the devil. "
Procedural macro systems are exactly what you wish for. A simple way to enhance the grammar of the language. The macro systems of modern languages are much cleaner and less error prone than C style #defines.
-- "One of the first things mentioned is about declarative languages": mentioned where?
----------
there was a demonstration that went along with this article, and actually the declarative languages are mentioned in the same sentence, XML and XSLT
-- Numerous grammatical and typographical errors, including such basic errors as sentences beginning with a lowercase letter
----------
i wrote for content, not to win a pulitzer. i have yet to find a tech site where any percentage of user submitted articles are grammatically/typographically perfect.
i can also safely say at this point that i am thankful i wasn't a compsci major. thanks for all of your comments though.
"i wrote for content, not to win a pulitzer. i have yet to find a tech site where any percentage of user submitted articles are grammatically/typographically perfect."
Not bothering to capitalize "I" makes you look like an amateur.
Go find a proofreader.
can garuntee there are more applications for XML and HTML than there are for smalltalk, lisp, ml, schema and python along with a lot of the other languages that were listed.
I hope you can realize that *this* is the bad part. XML is f*g abused.
I hope you can realize that *this* is the bad part. XML is f*g abused.
---------
Eh? You think that people using XML is a bad thing because too many people use it or you think that it's a bad thing because people use it when they shouldn't? Frankly, if you're going to blast a technology for overuse then you need to back up your claim. Otherwise I'm just going to have to ignore your opinion. But giving you the benefit of the doubt, I'm going to respond to your comments.
XML usage is a good thing because the more people use it, the more technologies will be built around it. The more tools and technologies there are to work with it, the easier it is to use.
Your personal dislike for the technology isn't really pertinent to the people who find it very useful. If you have real numbers that show that XML usage has and will over the long run increase costs for companies and individuals then please let's see them. If this is mearly your opinion based on your reaction than please at least put something constructive to the discussion in your post.
XML is extensible and extendable. It's a markup language that allows for the creation of readable structured data that can be shared across platforms. It's currently one of the few technologies that does this. It's also the most popular. It is also the foundation for the creation of metadata markup that will allow for next-generation file systems. This is why it's used so often.
Orion Adrian
I don't see anything amazing here. The easiest and coolest way I've worked with XML in a language recently was using the new SimpleXML extension that comes with PHP 5. Of course, that only works with reading in documents (which you can then modify), but if you want to create documents from scratch, you can use the DOM extension or write your own classes (which I have easily done in Objective-C/Cocoa -- even easier to do in PHP I imagine).
See here:
http://www.php.net/manual/en/ref.simplexml.php
In my opinion, there is no reason to use a compiled language for Web development at this point. In fact, I'm beginning to feel scripted languages are the wave of the future for ANY "average" software project. There's only one reason not to use a scripted language: speed. But the speed of these languages are jumping ahead by leaps and bounds -- even desktop apps can be written in them now. (Code accelerators, such as Zend's for PHP, can help a lot here as well.)
So, my question is: who needs Xen? Who needs a new language? If Microsoft's existing languages were good enough, they could handle XML with ease. A new language just for one file format seems...crazy!
Jared