The Old Joel on Software Forum: Part 3 (of 5)

XAML Revisited

http://msdn.microsoft.com/msdnmag/issues/04/01/DevelopingAppsforLonghorn/default.aspx

Pretty good article. Lots of cool screenshots.

..
Monday, November 17, 2003

I don't think XML is good for programming, unless you write some sort of Lisp...

Almonimus
Monday, November 17, 2003

Can you share your reasoning on that? I don't know if I agree, or disagree, but just knowing your opinion doesn't help anybody understand the issues.

Joe Blandy
Monday, November 17, 2003

I think the right thing to do language-wise is to define a canonical export to XML.

Thus the source can always be viewed as XML, but you don't have to program in angle brackets unless you want to.

Portabella
Monday, November 17, 2003

> I don't think XML is good for programming, unless you write some sort of Lisp...

Some XML languages (eg, Water) do just that.

Portabella
Monday, November 17, 2003

Microsoft's initiative of letting people design user interfaces using XML will help unify the programming model for desktop apps with the programming model for web apps.

For web, we use HTML, and for desktop apps, we shall use XAML.

In time, they shall blur the distinction, and also enable us to use XAML on the web.

This will, as usual, increase their market share, because Linux folks won't implement this feature for a year or two.

I know, I know, there is the Mozilla XUL, but who cares about a browser used by 0.01% of all the users??

Jaxx
Monday, November 17, 2003

> because Linux folks won't implement this feature for a year or two.

Actually I thought it was Microsoft who won't be implementing this for a year or three ;)

Portabella
Monday, November 17, 2003

Please, stop confusing XAML with XUL just because both have something to do with UI and are written in XML.

XUL uses predefined tag names, which are hardcoded in the parser to match a certain (smallish) set of UI controls and their properties available in the Mozilla codebase.

XAML is much more flexible than that.
XAML is a mechanism for dynamically mapping XML to the .NET type system. So, when you write:

<Window width="500">

This is an instance of a class called Window, and its .width property is set to 500 - but these are not some magic Window and width which exist just for XAML's sake, these are the same Window and width exposed via the CLR metadata which enable you to write:

Window w;
w.width = 500;

in C#, or to edit the width property in a dialog layout editor.
XAML doesn't "know" about Window and width the way XUL knows about its Window and width equivalents.
Any CLR types you create and register into the system will be made available to XAML.

Phoenix
Monday, November 17, 2003

"Any CLR types you create and register into the system will be made available to XAML."

*cough* security hole *cough*

Almost Anonymous
Monday, November 17, 2003

Isn't the hole more in how it's implemented? I mean, the concept of "any executable code you install on your PC can be run to do anything" is a security hole...

The important thing is ensuring the user has complete control over *what* gets installed.

Philo

Philo.
Monday, November 17, 2003

Phoenix did a good job explaining the significance of this. You aren't programming with XML, you're declaring objects and their layout with it. XML allows a much more natural representation of a group of objects that are hierarchical in nature than a procedural language. Rather than a bunch of lines of code creating the controls and calling methods and setting properties to add them to their parents, position them, set visibility, etc., you get a declarative syntax of these things with a visual structure that mimics the logical structure. It's sort of like a factory pattern on steroids.

SomeBody
Monday, November 17, 2003

Reasoning.. hmm..

Ok, it goes like this: Writing programs in XML format means using a non-intuitive approach (I am talking about the concept of writing and conversing here, which we use for a *very* long time, not "procedural vs. oo" or "XAML vs. XUL") of recursive representation of information instead of continuous one.

Therefore using XML to *store* data *objects* is a good idea, writing code with it just sucks. Believe me - I've tried. I would even go further to say that having some meta language which then translate to XML could be a valid idea if that XML would amount to anything - but it doesn't, see- after we have this XML representation we convert it into Byte codes anyway, so why would we need this extra layer between the actual code and the symbolic representation of that code?

I vote against using XML for anything but holding pure data, and even that got flamed a while ago by one of the original designers of XML, saying that the amount of non-intuitive regular code you need is huge (I use XML on daily bases for the last 3 years, so this is in no way an old engineer gripe)

Almonimus
Tuesday, November 18, 2003

It's not "writing programs" - nothing non-trivial would be XAML only. It's just snippets describing/implementing the visual part of your application. Think of it as a replacement of the resource files (yuck!) and the sequence of GDI/GDI+/WinForms/Swing/whatever calls you use to create your controls. Events coming from controls will be handled in any CLR language. Business logic will be handled in any CLR language.

Here :

http://msdn.microsoft.com/msdnmag/issues/04/01/Avalon/

you can see the example of a ultra-simple application which Charles Petzold has written for his classic Programming Windows in C/GDI, then for Programming Windows in C#/WinForms, and now for C#/Avalon. The C/GDI version is 250 lines, the C#/WinForms is 100 lines, the C#+XAML/Avalon version is 60 lines.

Phoenix
Tuesday, November 18, 2003

> I vote against using XML for anything but holding pure data

I tend to agree, but I also think XML languages (eg, XSLT) are inevitable.

Again, I think the right answer is a source-level binding to XML.

XAML might be another "makes the trivial parts seem hard, and the hard parts seem trivial" kind of solution. Most people like the idea of the boilerplate being done declaratively instead of in code, but to link the app together via XML declarations (even if they map to C#) may be too much.

Portabella
Tuesday, November 18, 2003

Hmmm.... interesting.

But also, not very technically challenging in itself. There are at least half a dozen Python libraries that do this sort of object pickling; you can write one yourself in an afternoon or two.

Obviously, I don't think that cloning this is a big deal at the XML level. The bottleneck, if any, would be in the API referenced by the XML, and the embedding of C# in the XML. IIRC, MS has been trying to patent the .NET API. But at least there are *two* non-MS C# implementations in progress.

Phillip J. Eby
Tuesday, November 18, 2003

"Again, I think the right answer is a source-level binding to XML."

Kind of like this?

http://homepage.mac.com/jimbokun/Excelsior.html

(for Objective C, there's Castor for Java, etc.)

or do you mean something else?

Jim Rankin
Tuesday, November 18, 2003

> or do you mean something else?

Yes.

I mean that the *source code* has both an XML representation and an ordinary one, so that the language *is* XML, but doesn't have to always be written that way.

Portabella
Tuesday, November 18, 2003