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.
Note: This article was submitted for publication by Jayson Knight, a certified Microsoft Solution Provider.
I won’t rehash the whole “programming with rectangles, triangles, and circles” paradigm that seems to be the encompassing theme of Xen, simply do a search on any search engine for Xen/X# for that kind of information.
One of the first things mentioned is about declarative languages, XML and XSLT falling neatly into that category. one of the fallbacks of declarative languages is lack of typing/loose typing, and being late bound and uncompiled/interpreted. the ultimate end goal of Xen will be something that is 100% reliant on the CLR type system, and also fully compiled and optimized. while there are numerous primitives in XML/XSLT, extracting this data from the document at this point is done almost entirely using string types for all of these. this is something that simply must be overcome (v 2.0 makes some serious inroads into this, but nowhere near as much as Xen, as you’ll see shortly). in the .Net world, there are basically 3 seperate type systems:
The SQL type system, encompassing TSQL and SQL types (varchar, money, etc)
The XSD type system, which provides Xml serialization functionality and encompasses XML, XPath, XSLT, and XQuery
The CLR type system, which includes all of the .Net types that i am sure everyone is quite familiar with
There are 3 sets of API’s to bring these 3 type systems together:
ADO.NET for the CLR – SQL bridge
SQL XML for the SQL – XSD bridge
System.Xml for the XSD – CLR bridge
now for some code. here the way you would typically handle some data extraction from and XML document using the DOM:
decimal AddTotal(XmlDocument doc, int zip) {
decimal total = 0;
foreach (XmlElement item in
doc.SelectNodes(“order[Zip=‘”+zip+”’]/item”))
{
XmlElement price = item.SelectSingleNode(“price”);
XmlElement qty = item.SelectSingleNode(“quantity”)
decimal p = Decimal.Parse(price.InnerText);
decimal q = Decimal.Parse(quantity.InnerText);
total += p * q;
}
return total;}
This is most defintely a functional snippet, however it’s string based typing with lots of casts, and overall isn’t that readable, and notice the way the XPath query is assembled using an assortment of double and single quotes. of course, you can use the XmlSerializer class to work around some of the typing issues as such:
class Order {
public Item[] Items;
}
class Item {
[XmlAttribute] int id;
public int Zip;
public decimal Price;
public decimal Quantity;
}XmlSerializer s = new XmlSerializer(typeof(Order[]));
Order[] orders = (Order[])s.Deserialize(stream);decimal AddTotal(Order[] orders, int zip) {
decimal total = 0;foreach (Order o in orders) {
if (o.Zip == zip)
{
foreach (Item item in o.Items) {
{
total += item.Price * item.Quantity;
}
}
}
return total;}
While this example is functionally equivalent, it’s actually much more verbose and harder to read due to the fact that we lost out querying language and had to basically roll our own by using a nested foreach loop, and an “if” test. Xen is attempting to merge the two programming models together, and here is a sample (syntax will probably change by the time it’s released, look at the concepts more than anything else) written in Xen, with key code in red:
public decimal AddTotal(Order orders, int zip)
{
decimal total = 0;
foreach (Item item in order[Zip == zip].item)
{
total += item.price * item.quantity;
}
return total;
}
What in the heck is “Order”? what is this new syntax on the right side of the foreach loop? it’s a little hard to explain without first giving a short history lesson on XSD types, and the importance of them (obviously) in the integration of Xen with C# (which is elegantly described as Xen = C# + XSD + XML + XQuery + SQL). here are the basic types in XSD that Xen will attempt to roll up:
sequence
choice
all
* + ?
T , U
T | U
T & U
attribute
attributeGroup
required
typedef
mixed
xml:space
T requires expr
and a short example using some of these types based on an SVG scenario:
<PRE>
<xs:complexType name="container">
<xs:complexContent mixed="false">
<xs:extension base="t:shape">
<xs:sequence>
<xs:element name="desc" type="xs:string" />
<xs:element name="title" type="xs:string" />
<xs:choice maxOccurs="unbounded">
<xs:element name="rect" type="t:rect" />
<xs:element name="line" type="t:line" />
<xs:element name="g" type="t:group" />
<xs:element name="ellipse" type="t:ellipse" />
<xs:element name="polygon" type="t:polygon"/>
<xs:element name="styles" type="t:styles"/>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</PRE>
So the question is how to take this declarative model and model it in Xen? here it is:
public class rect : shape
{
attribute int x;
attribute int y;
attribute int width;
attribute int height;
}class container : shape
{
sequence {
string title;
string desc;
choice {
rect;
line;
group g;
ellipse;
polygon;styles
}*
}
}
As you can see, the XSD constructs of “sequence” and “choice” are made first class citizens of Xen, as well as the notion of zero or more as indicated by the asterisk for the “choice” block, and attributes are strongly typed and mapped to CLR prmitives. this is quite obviously quite an improvement over the XSD way of handling things. so that covers the XSD part of the equation, now on to the XML portion and what is slated to be included. There are 5 fundamental XML Literals that are mentioned, along with their importance to the XML language, they are:
namespace “URI” { }
using prefix = “URI”;
Foo f = ;
Code snippets: ;
XSD validation by the compiler
One ramification of this is that the Xen compiler will be doing the XSD validation at compile time. of course you can validate in the current version of .Net, but a realistic situation is that you will be building an XSD document at runtime to be sent to perhaps another application to be consumed, what happens if it’s not valid? Trying to track down the source of the error is also time consuming and arduous. the benifits of moving this sort of validation into the compiler should be quite obvious. here is an example of some code that uses current XML technologies in .Net to build an HTML table:
protected override table GetResult() {
table result = new Table();
tr row = new row();
result.Items.Add(row);
th cell = new th();
cell.InnerText = “ID”;
row.Items.Add(cell);
cell = new th();
cell.InnerText = “Name”;
row.Items.Add(cell);
…
foreach (tr row in GetCustomersByCountry(this.country)){
table.Items.Add(row);
}
return result;
}
Here is a Xen example using an XML literal to describe the table declaratively:
<PRE>
protected override table GetResult() {
return <table>
<tr>
<th>ID</th>
<th>Name</th>
<th>Company</th>
<th>Address</th>
<th>City</th>
<th>Zip</th>
<th>Phone</th>
</tr>
{GetCustomersByCountry(this.country)}
</table>;
}
</PRE>
It’s still strongly typed (demos to come later), and it gets compiled completely down to IL via the Xen compiler. notice the curly braces following the closing < /tr> tag, that’s an example of a code snippet XML Literal in Xen. The last part of Xen that i will touch on in this post is querying…the Xen way. there is quite a bit of useful information here, and one of the most exciting is SQL DML keywords (SELECT, DELETE, UPDATE, INSERT) becoming first class citizens as you will see. Querying takes on a new form in Xen. For now, it’s being modeled after XQuery, but with a few changes:
no more “/”, these will become “.” to follow the paradigm we are all used to with C#/VB.NET/etc
0 based indexes instead of 1 based
XPath aggregates are supported (avg(), sum(), etc)
Queries are strongly typed, and mapped to the CLR
Xen/C# variables can be plugged directly (and typesafely) into queries (without all the messy “” and ”)
of course, here is a short snippet demonstrating some of these (this also explains the red code in one of the first samples):
Book[] books = …;
string name = “Joe Bloggs”;
string* titles = books[author == name].title;
What this example does is select all of the books with the author name of “Joe Bloggs”, then return this as a stream to the variable “titles” of type string*. the asterisk simply means a stream of strings, 0 or more values, a better definition is IEnumerator typed as “string”. a good question is why not just return to an array of strings? you can’t gaurantee the richer symantics of an array (indexing, counting, etc) over any query due to limitations of SQL itself.
we are at the last part of the equation in order to implement the ADO.NET programming problem, the SQL portion. the full set of SQL DML operations need to be implemented, and in it’s prelimenary form, Xen will add two more; “Replace” and “Move” for XML design reasons (where in a tree you want to do these operations). here is a list of each, and their Xen implementation:
Select – select * from Customers where Zip == 98072
Update – update group.employee.salary *= 1.1;
Insert – insert group.employee[salary>100] before foo;
Replace – replace group.employee[salary>100].bonus with 10;
Move – move group.employee[salary>1000] after wdinc;
Delete – delete group.employee[salary>1000000];
I think they are pretty self explanatory, it’s also worth noting that Xen isn’t rebuilding these notions, it’s simply a wrapper on top of the existing model that’s already in place…why reinvent the wheel. here is an example of ADO.NET code, and it’s corresponding Xen counterpart:
SqlCommand cmd = new SqlCommand(“select *” +
+ ” from orders”
+ ” where Total > @threshold”,
this.Connection);
cmd.Parameters.Add(“@threshold”).Value = threshold;IDataReader r = cmd.ExecuteReader();
while (r.Read()) {
…
}
Becomes:
foreach (OrdersRow row in
(select * from orders where Total > threshold))
{
…
}
Again, the benefits should be pretty apparent just from glancing at the code. one of the final things i will touch on is XSLT in Xen. here is a short snippet of XSLT that has an embedded C# function in it to calculate the balance of a ledger and return it to the XSLT document:
<xsl:for-each select=”Ledger/*”>
<xsl:value-of select=”user:Total(.))”/>
xsl:for-each>
<msxsl:script implements-prefix=’user’ language=’C#’>>
decimal balance = 0;void Total(XPathNodeIterator iter) {
XmlNode node = e.NextNode();
string s = node.SelectSingleNode(“amount”).InnerText;
decimal amount = Decimal.Parse(s);
if (node.Name == “deposit” || node.Name == “balance”)
balance += amount;
else
balance -= amount;
return balance;
}
]]>
msxsl:script>>
One of the things about XSLT is that, while it certainly tries to be, it’s not a general purpose programming language, so you will always run into those boundaries and end up in the classic ASP paradigm of embedding script into your XSLT docs if you need anything dynamic. here is the same code block implemented in Xen:
int position = 0;
foreach (Item c in ledger.child::*) {
if (c is Deposit || c is OpeningBalance) {
balance += c.amount;
} else {
balance -= c.amount;
}
yield {balance};
}
And again, the advantages should be pretty apparent. *note* if you are wondering what the “yield” statement does, check out some info on iterators in the v 2.0 release of C#, the statement does the exact same in this situation as it does for iterators.
So that’s the end of the first part of my multi-post on Xen. This was meant to be purely an informative post, i am saving opinions for another time. also, the code examples in this post are meant to be informative only as no doubt the syntax will change drastically before Xen ever sees the light of the CLR. In a future post I will touch on how Xen may be implenting some of the new features of C# v 2.0 (we’ve seen iterators here, generics, etc are also tied in to Xen), as well as some more XPath information and some samples of what Xen can do to enhance existing applications. as always, comments are welcome (please note that i am not an XML guru). This is pretty revolutionary stuff, and it makes me remember why I chose to be a programmer in the first place.
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