+972 52-548-6969
Acropolis: Yet Another Executable XML
I 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.
Comments
"XML is code, period."
Yeah, and code that isn't easy to check at compile time either.
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.
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.
a bit of a trackback: http://www.lowendahl.net/showShout.aspx?id=135
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.
Oren,
That looks like a hibernate mapping file :-)
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
@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.
Something really strange happened on my blog. here is the post re-posted: http://www.lowendahl.net/showShout.aspx?id=136
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...
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.
I weighed in on this topic but the trackback isn't showing up. Click on my name to get to my comments / post.
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.
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....
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.
@jg: You do realize that the Petzold link is a joke, right? :)
Comment preview