<< C# 2.0 is done | Home | rails:ConditionalRender - still trying to get WebForms to work right >>

Acropolis: Yet Another Executable XML

image_thumb3_thumb_thumbI would really like to understand the attidute behind "no code* (TM) " approach.

* Except a whole lot of of XML that you are not supposed to look at but usually have.

 

The new announcement from Microsoft is hitting all the key points that scream "STOP" in my case:

 

Tomorrow you will build parts, behaviors, navigation, and even business logic (via Windows Workflow Foundation) all in a designer. You will even wire components and dependencies and define how they interact, all without writing or generating any code.

I do believe that I have heard this promise before. About Object Oriented Programming, COM, XML, Web Services, SOA, etc.

Being a developer is about telling the computer what to do. Trying to hide this behind a wizard is nice, but it is not an approach that scales, period.

I am not going to program in this, but it looks like that is what I would need to do if I wanted to understand what is going on.

<CsamlFile xmlns="http://schemas.microsoft.com/winfx/2006/xaml/csaml"
           xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <NamespaceDeclaration Identifier="MyNamespace">
        <ClassDeclaration Identifier="MyClass" 
                          Access="Public">
            <MethodDeclaration Identifier="Main" 
                               Access="Public" 
                               Modifier="Static" 
                               ReturnType="{x:Type void}">
                <InvocationExpression
                  MemberAccess="System.Console.WriteLine">
                    <InvocationExpression.ArgumentList>
                        <Literal Type="{x:Type string}"
                                 Value="Hello, CSAML! ">
                    </InvocationExpression.ArgumentList>
                </InvocationExpression>
            </MethodDeclaration>
        </ClassDeclaration>
    </NamespaceDeclaration>
</CsamlFile>

Oh wait, there is a designer?

Nice, I saw how that turned out for SSIS, BizTalk, etc when we are talking about even moderate complexity. How do I debug it? There is a special tool? How do I profile it? There is nothing for that?

Can we please stop trying to run away from code? If I want declerative language, I will write a DSL, and it sure as hell wouldn't be in XML.

I am all for smarter frameworks and making our life easier, but I am completely against trying to get to: "all without writing or generating any code"

Newsflash: XML is code, period.

Print | posted on Wednesday, June 06, 2007 10:47 PM

Feedback

Gravatar

# re: Acropolis: Yet Another Executable XML 6/6/2007 11:35 PM Chris Holmes

"XML is code, period."

Yeah, and code that isn't easy to check at compile time either.

Gravatar

# re: Acropolis: Yet Another Executable XML 6/6/2007 11:45 PM Patrik Löwendahl

It's the developers version of "the search for the holy graal" only for us it is "the search for the perfect abstraction level".

Everytime MS introduces a new abstraction level they do it with "less code" arguments. But everytime we end up just writing different code then we did before.

Gravatar

# re: Acropolis: Yet Another Executable XML 6/6/2007 11:54 PM Glenn Block

Agree it's a lot ot promise, though that is the goal. As for p&p we'll be looking more toward the strategy you just outlined and we'll leave it Acropolis folks to put their money where their mouth is.

Gravatar

# re: Acropolis: Yet Another Executable XML 6/7/2007 12:04 AM Patrik Löwendahl

a bit of a trackback: http://www.lowendahl.net/showShout.aspx?id=135

Gravatar

# So true 6/7/2007 12:57 AM Miles Thompson

Thanks for saying it. I hear this a lot, and especially from Microsoft. And its not just at the framwork level, you also hear it a lot at the components level, where, perhaps a little more excusable I find it just as annoying..

MS.AJAX? "Write ajax without having to write any Javascript" Yay. I mean, not yay. Ajax after all *is* mostly javascript, and as a programmer who already has some famiilarity with Javascript and the XmlHttpObject thingamy - what use is it to me to get a framework that 'hides' all that so I have to understand some other abstraction instead of the 'real' code. What would be much better is 'our beautifully crafted javascript is easy to read and hides all the nasty/complex bits in layers that mean you don't need to worry about it unless you really want to in which case its still done in an elegant and easy to understand manner'.

MS Sharepoint/Office 2007 - deploy your entire intranet without writing any code. Again. This is really going to just push the 80/20 rule even further - meaning it took me just 10% of the time to build 90% of the app - but unfortunately given that the business/client/whatever actually needs that last 10% i still have to crack open the 'orrible leaky abstraction and hack around to build that last 10% and burn through 90% of my project time. Argh.

Gravatar

# re: Acropolis: Yet Another Executable XML 6/7/2007 6:08 AM Mike D

Oren,

That looks like a hibernate mapping file :-)

Gravatar

# re: Acropolis: Yet Another Executable XML 6/7/2007 6:26 AM Brad Abrams

Excellent points Oren -- But the acropolis project is a LONG way from this place... while some might be dreaming about that... we are (IMHO) staying well grounded in acroplis... we are using declarative where it is a known-good solution (writing up compontents) and using imprative code where it is still a better option (writing business logic).. Check out the application.axml file from any of the samples and let me here what you think!

Check this out for an example: http://msdn2.microsoft.com/en-us/library/bb499796(vs.90).aspx

Gravatar

# re: Acropolis: Yet Another Executable XML 6/7/2007 7:49 AM Ayende Rahien

@Brad,
Writing up components? Did you mean "wiring" ?
If so, this approach _still_ has severe scalability in most cases, you usually need to do the interesting stuff in a smart way and that calls for imperative approach.
I wrote a DSL for configuring an IoC because XML configuration broke down very fast when you threw real app on it.

Gravatar

# re: Acropolis: Yet Another Executable XML 6/7/2007 10:42 AM Patrik Löwendahl

Something really strange happened on my blog. here is the post re-posted: http://www.lowendahl.net/showShout.aspx?id=136

Gravatar

# re: Acropolis: Yet Another Executable XML 6/7/2007 5:19 PM Nate Kohari

What, you mean creating an XSD for an XML syntax isn't as good as a compiler? :>

Seriously, Acropolis looks interesting. I'm curious to see where they're going to go with it. Honestly, though, I wish Microsoft would start focusing on tools to make good developer's jobs easier, rather than tools to make bad developers into mediocre developers...

Gravatar

# re: Acropolis: Yet Another Executable XML 6/10/2007 3:30 AM Karthik

Seems like MS still can't seem to get away from focusing on pushing Business Analysts into writing their own apps.

You hit the nail on the head by saying this approach doesn't scale.

If it did, the whole world would be writing every business application in MS Access.

Gravatar

# re: Acropolis: Yet Another Executable XML 6/10/2007 6:44 PM Keith Elder

I weighed in on this topic but the trackback isn't showing up. Click on my name to get to my comments / post.

Gravatar

# re: Acropolis: Yet Another Executable XML 6/11/2007 2:02 AM Matt

ahhh... it's rare that you need to be corrected, but respectfully, I think you missed the mark on this one.

First, that code snippet and Petzold link above are from his April Fool's post. It's worth mentioning that in your write-up even if it was your intended point :) "CSAML" is not real. The markup for acropolis is XAML, which has a debugger, has several designers, and (so far) scales well.

Your other points are valid, IMO, but not universally. I don't think acropolis is intended for scenarios where scalibility and performance truly count. According to MS:

"Code Name 'Acropolis' is a toolkit for creating modular, business-focused Windows client applications."
http://msdn2.microsoft.com/en-us/library/bb499794(vs.90).aspx

That's pretty vague but I read it as: acropolis targets enterprise developers who need to build little one-off apps. For them, being able to put something together quickly is priority #1. Right tool for the right job, etc.

We'll have to wait and see if acropolis actually moves the state of RAD forward. Judging from the samples, I think it has some potential for certain scenarios.

Gravatar

# re: Acropolis: Yet Another Executable XML 6/20/2007 1:19 PM Colin Jack

I agree with the previous post, if MS emphasize that this approach is only suitable for some situations then I think its a decent idea.

Ofcourse that little one-off app might well become a core part of the business and then need maintenance....

Gravatar

# re: Acropolis: Yet Another Executable XML 6/27/2007 8:01 AM jg

This is ridiculous, who would ever want to program using XML. That's just balogna! Did anyone see this: http://www.charlespetzold.com/etc/CSAML.html? Did you see how the translate a SIMPLE arithmetic statement into over 20 lines of XML... and the guy says "This statement translates without much fuss into the following chunk of CSAML:" I don't know about you guys, but writing more lines of code is much more fuss than writing one line.

Gravatar

# re: Acropolis: Yet Another Executable XML 7/5/2007 9:31 PM Nate Kohari

@jg: You *do* realize that the Petzold link is a joke, right? :)

Comments have been closed on this topic.