It is not the parser I fear
Martin Fowler talks about the almost instinctive rejection of external DSLs because writing parsers is hard. I agree with Fowler on that writing a parser to deal with a fairly simple grammar is not a big task, certainly there isn't anything to recommend XML for the task over an textual parser.
The problem that I have with external DSL is actually different. It is not the actual parsing that I object to, it is the processing that needs to be done on the parse tree (or the XML DOM) in order to get to an interesting result that I dislike.
My own preference is to utilize an existing language to build an internal DSL. This allows me to build on top of all the existing facilities, without having to deal with all the work that is required to get from the parse tree to a usable output.
In the case of the example that Fowler uses for his book (the state machine outlined here), the use of an internal DSL allows me to go from the DSL script to a fully populated semantic model without any intermediate steps. I give up some syntactic flexibility in exchange of not worrying about all the details in the middle.
The benefit of that is huge, which is why I would almost always recommend going with an internal DSL over building an external one. Here is a simple example, a business rule DSL:
suggest_preferred_customer: when not customer.IsPreferred and order.Total > 1000 apply_discount_of 5.precent: when customer.IsPreferred and order.Total > 1000
I wrote the code to use this DSL as a bonus DSL for my DSL talk in DevTeach. It took half an hour to forty five minutes, and it was at 4 AM. I extended this DSL during the talk to support new concepts and to demonstrate how easy it is.
I got to that point by leaning heavily on the host language to provide as much facilities as I could.
In short, it is not the parsing that I fear, it is all the other work associated with it.
Comments
What about XAML as a facility for DSLs?
You can't express any sort of advance concept in XAML.
Only prop assignments, and those aren't nearly enough
I look forward to your book so I can figure this complexity out.
If I'm programming in C#, can I use this Boo syntax? I'm confused how this all works.
Or do I have to write my app in Boo ? Does Boo support asp.net mvc?
Confused - I just see those small snippets of code but don't get the bigger picture
If you are programming in C#, you can utilize DSL that uses Boo, yes.
You don't have to write your applications in Boo, but you will be happier if you do :-)
Yes, Boo supports MS MVC.
Thank you. Your test setup helped me understand. So the DSL using Boo is in a class library that the C# main project can call?
I can see now why using Boo for a DSL is so powerful.
I'd love to see a Boo MS MVC - that would be incredible. Not to tax you, but a simple Boo 'hello world' MS MVC app with Boo controllers, actions and UI would open the door to a world of new possibilities! (Currently I use Spring.NET, NHibernate and MVC for my web applications)
Questions:
Is there any intellisense, etc... support using Boo in VS 2008 ? (I use resharper)
I've seen you replace xml with Boo for Binsor. I'd like to see Boo replace Spring.NET and NHibernate mapping files. I assume this would be equivalent of creating my own DSL?
Lastly, with Boo being so unheard of (not to diminish it), and it's capability so high with DSL's - I do think 'selling it' as a DSL language would create more interest.
Sorry if this is not understood, I'm just exploring the capabilities - sky is the limit here, getting acceptability in the workplace is another issue - although 'DSLs' are quite the buzzword !
Creating a Boo DSL API to be called by any .net language would be where I'd go with it initially.
I'll go buy your book :)
Thank you
There are several projects to provide support for boo in VS 2008, including intellisense.
Yes, you would need to create your own DSL for that, not a hard task
Yes. That is exactly how it should be done!
Yes. That is exactly what should be disliked!
I believe we share the same yantra here... ;)
it compelled me to send you an email this time. p.s.
If anyone is interested I put up an (interpretation of) the State Machine described in the Martin Fowler referenced above using Rhino DSL/Boo here: http://www.codeplex.com/SimpleStateMachine
Comment preview