You can't build a whole program with a DSL, but you often use multiple DSLs in a system mainly written in a general purpose language. DSLs come in two main forms: external and internal. An external DSL is a language that's parsed independently of the host general purpose language: good examples include regular expressions and CSS.
External DSLs have a strong tradition in the Unix community. Internal DSLs are a particular form of API in a host general purpose language, often referred to as a fluent interface.
The way mocking libraries, such as JMock, define expectations for tests are good examples of this, as are many of the mechanisms used by Ruby on Rails. Internal DSLs also have a long tradition of usage, particularly in the Lisp community. This improves programmer productivity, which is always valuable. In particular it may also improve communication with domain experts, which is an important tool for tackling one of the hardest problems in software development. CSS is an excellent example of this, most people who program CSS don't consider themselves to be programming.
Despite this, however, I don't generally think that end-users will usually write in DSLs directly - it's the communication enhancement that's important. Although DSLs have been around for a long time, the lack of knowledge of how to program with them is a significant barrier - which is exactly why I've worked on this book. The books provides techniques to develop both internal and external DSLs, giving you both the information to choose between them and a good package of information to begin your work.
I also stress the importance of layering a DSL over a library, so that you usually build both together. Interpretation reading in the DSL script and executing it at run time is usually easiest, but code-generation is sometimes essential. Usually the generated code is itself a high level language, such as Java or C. I was asked to put together a discussion of DSLs for non-technical types.
So here it comes. The trouble is that there is no precise definition for a DSL and there is a large gray area between DSLs and other things. Most new ideas in software developments are really new variations on old ideas. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach.
Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development.
Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness. Most of our software logic is written in our programming languages, these give us the best environment to write and evolve such logic. But there are circumstances when it's useful to move that logic into a data structure that our imperative code can interpret - what I refer to as an adaptive model. Here I'll show some product selection logic in JavaScript and show how it can be refactored to a simple production rule system encoded in JSON.
This JSON data allows us to share this selection logic between devices using different programming languages and to update this logic without updating the code on these devices. Will DSLs allow business people to write software rules without involving programmers? When people talk about DSLs it's common to raise the question of business people writing code for themselves.
That is that one of the original aims of COBOL was to allow people to write software without programmers, and we know how that worked out. So when any scheme is hatched to write code without programmers, I have to ask what's special this time that would make it succeed where COBOL and so many other things have failed.
A common phrase that's bandied about when talking about DomainSpecificLanguages or indeed any computer language is that of noisy syntax. By Syntactic Noise, what people mean is extraneous characters that aren't part of what we really need to say, but are there to satisfy the language definition.
Noise characters are bad because they obscure the meaning of our program, forcing us to puzzle out what it's doing.
0コメント