Tuesday, March 17, 2009
Why a Domain Specific Language is better than a Framework!
If you are a programmer you use frameworks. Some frameworks such as a collection framework are almost indistinguishable from the language. I know in my C# code I find almost all my classes contain either 'List' or 'Dictionary'.
Other frameworks such as ADO .net are very large and require quite a bit of time learn. They provide an indispensible service to your application but are very difficult to learn and use. The application code that employs the framework is almost unintelligible. Adding more comments or the more judicious use of variable names seems to have no effect on making the code look better. The problem is that most frameworks need to expose details of internal concepts to application as numerous tunable parameters and properties. This is required since a typical framework has no other mechanism of inferring intent.
The need for the framework to have numerous tunable parameters and properties (lazy loading, concurrency issues, etc) compounds usage problems. This is because in order to be used correctly they need to be understood. Subtle errors in understanding a concept of a framework produces either subtle errors in the application or causes the application not to run a peak performance.
Using a domain specific language addresses a number of these problems.
- A domain specific language after all is just another language. Most languages can be learned in a few hours to a few days. When we wrote Jetfire we started with C# syntax adding few specific features. A programmer's investment in understanding languages could be reused. The additional features in Jetfire, for example, are consistent with the C# programming paradigm.
- The code in a DSL is designed to be understandable and compact. Unlike working with a framework where hundreds of lines of code are required just to provide initialization, working with a DSL typically requires very little code.
- When you write code in a DSL the language is able to understand the programmer's intent and therefore is able to hide most of the complexity. For example Jetfire understands that variables should be saved to persistent storage. Therefore Jetfire does this automatically without the application programmer writing extra code. Jetfire also knows if a variable is used inside a method that it doesn't need to be saved because that variable is only valid as long the method is executing.
Further reading:
Labels: Jetfire, persistence
Thursday, June 12, 2008
Hello World with Jetfire
Well what do we mean by a lot simpler. Well lets look at "Hello World".
namespace test
{
workflow HelloWorld
{
DateTime creationTime = DateTime.Now;
public string Hello
{
get{return "This workflow was created at:" + creationTime.ToString();}
}
}
}On the surface it looks almost like C#. The only significant difference is that 'class' has been replaced by 'workflow'. Other than that it is valid C# code.
So what is the difference? Why bother with Jetfire? Well the big difference is that Jetfire really starts where C# ends. For example, once a Jetfire instance of the HelloWorld object is created it is persistent until it is deleted. That is why there is a time stamp in this example so you could see when each instance was created. Try it for yourself.
In C# to make an object persistent you need to write code to save it to database or a file. Yes, you can serialize the object; however then serialization breaks if you change the code, and so on. With Jetfire there is nothing more to do. The objects and code are persitent. When the code changes a new version is automatically created.
This is part of goal of having the programmer focus on the problem, not the programming infrastructure. Hopefully the "HelloWorld" example gives some introductory insight to the features of Jetfire.
Labels: Jetfire, persistence
Subscribe to Posts [Atom]
