VB.NET as a DSL
Posted by Dan Byström on July 4, 2008
The other day I got a glimpse of something that could turn out to be really useful. Or maybe a Pandora’s Box. I really don’t know until I investigated it more. 🙂
I was asked to add some simple string manipulation functions (to something that we for simplicity can think of as a report generator).
After thinking about the problem I decided that I would violate the YAGNI (you ain’t gonna need it) principle and give the customer the full Monty directly. Why? Because I realized that it was so incredibly easy to give them the possibility to write full fledged VB.NET code directly that it would probably take the same amount of time to code as some basic string manipulation functions together with a UI!
Consider the following facts:
- It is extremely easy (and fast) to compile a piece of VB.NET (or C#) code into an in-memory assembly and execute that code. It takes roughly 20 lines of code.
- This dynamically compiled code can easily be given access to any specified part of the application or it’s business objects (just by adding the appropriate assemblies).
- Of course the code to be compiled can be preprocessed first, in order to provide the user with a syntax as simple as possible.
I think that these facts taken together implies that opening up parts of the business logic code to the user / customer / domain expert could be worthwhile.
So, the next time I feel that:
- I am just transforming the domain expert’s words into executable code
- I may not have fully understood the intention of the domain expert
- the code I’m writing is likely to change in the future
Then I will definitely consider making that code modifiable by both the domain experts and me (or most likely: read by the domain experts and modified by me and them together). The choice of VB.NET over C# seems obvious; novices read Basic easier – it is no coincidence that “B” in BASIC stands for Beginner. Many users have also encountered VBA while playing around with macros in Word and Excel. Ekeforshus