I DSL sono una delle cose più belle di Visual Studio
Team System.
Mi segno questo post di Don Box che mi è sembrato molto interessante... e che
guarderò bene quando sarò meno stanco...
Here are a few examples I've encountered over the past couple of years here in the big house:
- XLANG. XLang is a DSL for modeling message passing
concurrent processes. We shipped it in BTS in 2000 and it (along with WSFL)
were seed material for BPEL4WS.
- MS Business Rules Engine (BRE). BRE defines a DSL
for modeling event/condition/action triples that many BTS customers are
quite happy with. JESS and ILOG/JRules are comps from outside of MSFT.
- MSBUILD. MSBUILD defines a DSL for describing
dependencies between artifacts and rules for producing those artifacts.
Comps are ANT/NANT and the various MAKE tools that have existed for decades.
- Windows Workflow Foundation. WF is the closest I've seen to an extensible "DSL engine" in the mainstream commercial dev universe. While it won't ship until 2006, it is used by various Office 12 applications, most notably Sharepoint.
All of these systems are examples in which (a) the user specifies their software at a higher level of abstraction than imperative code and (b) that specification has a data representation (often XML-based) that can be processed/visualized/interpreted without actual execution.
More importantly (in my mind) is that all of these systems integrated the model definitions into the actual execution of the system.
In my mind, the only way this stuff will get traction is if we change the runtimes to work in terms of higher-order expressions. Otherwise we're stuck in the 1980's CASE world where box-and-arrows and code were like matter and anti-matter, despite the best attempts at roundtripping UML and code.
Fonte: DSLs in the field