http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Mats, thanks for asking the hard questions. 1/ No, it is not just a method signature. How do you import a custom assembly with external code? How do you enter a new namespace? The language doesn't let me make it work. I want to do something that is complex, and I want to be able to do that with all my usual tools, so I use C# and compile an assembly And then I can immediately use it like this: import Complex from SomeComplex if ComplexCalculation(account): do stuff Extensibility of the DSL with external factors is important. 2/ The point of writing the book is that _you_ will be able to write the DSL easily. 3/ My claim is that the cost of doing something like this is that you have very low cost for this. I'll try to post a more appropriate example soon. 4/ There isn't much cost in there, but there is a lot of value in being expressive. There is also more value in being able to actually look at things without the programming language overhead. I don't think that I disagree with that there will be times that an API is good as a DSL, but I think that I have a different idea about where that line is at. http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment9http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment9Fri, 30 Nov 2007 22:20:15 GMT1) Just a method signature, which can easily be generated at any point. If we generate it early, we could let the user edit his code snippet inside it in VS, giving IntelliSense, error handling etc. Otherwise we could generate it late, essentially creating a VB/C# scripting environment rather than a "DSL" environment for our users. In both cases, the user would only have to write those lines I showed in the example 2) Well, this is just what I mean - I'll bet that I can explain that && means And faster than you can build a new DSL to make that ugliness go away.......hmmm....actually, I take that back. But I'll bet that _you_ can explain it faster than _I_ can build the DSL ;-) Seriously, yup it is ugly, but I have the feeling I could solve it with a post-it saying "&& means And, || means Or" instead of building a DSL. I think I would at least ask the customer to decide between these options. 3) Agreed, but I would argue that you need a certain level of sophistication in your language before you can start exploiting this type of potential with a DSL. Some domains and project scopes definitely warrant this approach, but unless it can be clearly established that this is the case in one's current project, chances are that the overhead involved in developing and supporting a DSL can not be warranted by a potential that may never become used. If the API approach becomes as clear or at least almost as clear for the actual use cases, why not go with it? All I'm saying is that the example you showed looked clearly of the kind where an API would suffice just as well. I'd love to see an example that actually motivated the DSL over the API for a business DSL, because as far as I have seen, those are rare...(though certainly not non-existing) 4) Indeed, but you can improve the API. I'm not saying that DSLs don't have value, I'm saying that in most cases I have seen, they do not have enough value when compared to an API that it motivates their higher overhead. Better tool support for DSLs would definitely change this equation. /Mats http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment8http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment8Wed, 28 Nov 2007 14:42:31 GMTSeveral reasons. The first is that the examples that you gave are not stand alone examples, you need to wrap them by quite a bit of syntax to make them work. The second is that the C# ones introduce syntax which is really not fun to explain to the user (&&, what is that?). The third is that instead of introducing language semantics, you introduce operations on API, there is usually a distinct difference between them. The language semantics are meant to be clear, readable and similar to a written language, an API has different design goals. The forth is that while it is not shown in this example, I have a long way to go with the DSL approach, where the VB.Net / C# approach I have no way to improve on the current syntax. http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment7http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment7Wed, 28 Nov 2007 14:15:07 GMTWhy is this: if CallMinutesForCurrentMonth > 300 and HasBenefit “300 Minutes Free!!!”: AddCallMinutes -300, "300 Minutes Free!!!" so much clearer than this: If client.CallMinutesForCurrentMonth > 300 And client.HasBenefit(“300 Minutes Free!!!”) Then client.AddCallMinutes(-300, "300 Minutes Free!!!") End If or even if (client.CallMinutesForCurrentMonth > 300 && client.HasBenefit(“300 Minutes Free!!!”) client.AddCallMinutes(-300, "300 Minutes Free!!!"); There's definitely going to be a non-trivial cost involved in developing and supporting a new DSL for the customer. To me it seems that someone who could parse your DSL example could be trained to understand the VB.NET or even the C# example for a much smaller cost than developing a new DSL? /Mats http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment6http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment6Wed, 28 Nov 2007 14:07:25 GMTSQL is the most used DSL in existance; if one would prefer to use C++ or Java to do what SQL does (hide the complexity of data access from the user) then I think something is probably amiss. Wrapping data access in a low level data access layer and a high level business objects layer of course is a different task, but I think going back to file based data access simply to reject DSLs would represent madness. A good DSL does one thing, and does it very well. It should also be easily *wrapped* in a traditional procedural language so that those missing features and irregularities can be handled in a structured way. The biggest problem with DSL creation is that often we don't keep it *simple* enough. We try to turn it into a full blown development language with general purpose features that mask the distinction between the tasks that the DSL is designed for, and those that the system's infrastructure should be providing. This is where DSLs can fail to provide the value they were intended for, not simply by doing the job they were intended for: partitioning business rules, data access, logic processing and system configuration away from the infrastructure of the core system. http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment5http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment5Tue, 27 Nov 2007 15:23:58 GMTThat is why my DSL language of choice is Boo, it is a CLR language that can integrate cleanly into a bigger application. http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment4http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment4Tue, 27 Nov 2007 01:11:36 GMTFrankly, I prefer C++ or Java. The problem with DSL's is that inevitably some aspect of the applcation is outside the 'specific domain', even if only a little bit. Then you either have to jump through many hoops or resort to a 'general puprose' langue anyway. I prefer to work with standard and widely used languages, because of tool support and a large body of accumulated experience in the development community. These concerns usually outweigh the 'advantages' of some proprietary and narrowly focused 'language' or syntax, which very often is neither consistent nor complete. http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment3http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment3Mon, 26 Nov 2007 22:06:04 GMTSteve, That is a very good point, I never considered it in this sense. Probably because I don't think of this as a DSL. http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment2http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment2Sun, 25 Nov 2007 17:44:40 GMTThis business DSL stuff you are talking about. It's been around for years. It's called a Business Rules Engine. Look at iLog for an example. http://www.ilog.com/products/rulesnet/index.cfm But there are dozens upon dozens of these out there. http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment1http://ayende.com/2968/why-we-need-for-domain-specific-languages#comment1Sun, 25 Nov 2007 17:38:29 GMT