Complexity through good intentions
After I got some input from Scott Allen about my Rule Engine post, I took a look at PolicyActivity.
Take a look at the image, my commentary is below it:
Can someone please explain me who thought about this idea? When you get something like that, how are you supposed to actually look at this and figure out what is going on? You have no way to look at it and get an idea about what is going on in there. You have to go and look at those sub rules one by one.
For that matter, take a look at the text boxes here. You want me to write code there? There is actually intellisense on those text boxes, which scares me to no end.
How am I supposed to be able to get an idea on what is going on here? An overall view, not just inspecting a single leaf of grass at a time.
How am I to do code review on that? For that matter, how am I going to use source control with that. The answer, sadly, is again, binary source control. No diffs for you, nasty spoiled code driven developer. Take a look at this snippet.
<Rule.Condition> <RuleExpressionCondition Name="{p3:Null}"> <RuleExpressionCondition.Expression> <ns0:CodeBinaryOperatorExpression Operator="ValueEquality"> <ns0:CodeBinaryOperatorExpression.Left> <ns0:CodePrimitiveExpression> <ns0:CodePrimitiveExpression.Value> <ns1:Int32 >1</ns1:Int32> </ns0:CodePrimitiveExpression.Value> </ns0:CodePrimitiveExpression> </ns0:CodeBinaryOperatorExpression.Left> <ns0:CodeBinaryOperatorExpression.Right> <ns0:CodePrimitiveExpression> <ns0:CodePrimitiveExpression.Value> <ns1:Int32>2</ns1:Int32> </ns0:CodePrimitiveExpression.Value> </ns0:CodePrimitiveExpression> </ns0:CodeBinaryOperatorExpression.Right> </ns0:CodeBinaryOperatorExpression> </RuleExpressionCondition.Expression> </RuleExpressionCondition> </Rule.Condition>
I actually had to cut some name space definitions from there, just to make it fit the screen.
Now, please guess what this translate to. Imagine a slightly more complex rule, and then try to do a diff on the changes when someone modify it.
I am waiting to be educated how this is a good thing.
Comments
I knew you'd fall in love with this tool. :)
Like I said - pros and cons. The rules editor is a con. The verbosity of the CodeDOM is a con.
The pros are not having to write a prioritized inferencing engine that analyzes side-effects, produces tracking data, and that can execute rules from an embedded resource or database. It would be less work to use the CodeDOM to spit out readable code from that XML.
Ouuu... could you work in Rhino configuration like this? Xml is good so this much Xml must be better!
I am afraid that MS already did it.
http://www.ayende.com/Blog/archive/2007/04/01/Microsoft-Enterprise-Mocking-Block.aspx
Please tell me you can resize that dialog. <scream>I absolutely !@#$ hate it when it is not possible to resize a 4-line listview to be larger!</scream> Damn, I wrote a 228-line VB6 module in 2002 that allows one to make VB6 controls resize in a more flexible manner than WinForms does!
Ayende, you might just be a champion of a "return to simplicity". The only thing this GUI has over your engine is the elimination of some bug possibilities. It might also produce better error messages -- something you mentioned which tended to be a black mark on more complicated DSLs.
That image gives a proper example of how NOT to do it
Comment preview