| General-purpose Programming Language |
Website Links For Programming |
Information AboutGeneral-purpose Programming Language |
| CATEGORIES ABOUT DOMAIN-SPECIFIC PROGRAMMING LANGUAGE | |
| domain-specific programming languages | |
| programming language classification | |
|
DSLs have also been called by various names:
DSLs focus on doing one kind of task well. For instance, GraphViz is designed to create images of graphs in a variety of formats, but GraphViz lacks the capability to perform some basic tasks, e.g., accessing a network socket, receiving additional user input, or manipulating strings. USAGE PATTERNS There are several usage patterns for DSLs: #DSLs which operate standalone, and are called via direct user operation (often on the command line or from a Makefile ), like GraphViz . #DSLs which are implemented using programming language macro systems, and which are converted or expanded into a host General Purpose Language at compile-time or read-time. #DSLs are called (at runtime) from programs written in General Purpose Languages like C or Perl , to perform a specific function, often returning the results of operation to the "host" programming language for further processing. Generally, an interpreter or Virtual Machine for the DSL is embedded into the host application. #DSLs are embedded into user applications, like macro languages within spreadsheets, and they are used to execute code that is written by users of the application, dynamically generated by the application, or both. Many DSLs can be used in more than one way: GraphViz can be run on a command line, there are Perl modules which output GraphViz data, and GraphViz has been embedded into other applications as a visualization component. CONTEXT A DSL is created specifically to solve problems in a particular Domain and is not intended to be able to solve problems outside of it (although that may be technically possible). In contrast, General-purpose Programming Languages are created to solve problems in many domains. The domain can also be a business area. Some examples of business areas include:
A DSL is somewhere between a Tiny Programming Language and a Scripting Language , and is often used in a way analogous to a Programming Library . The boundaries between these concepts are quite blurry, much like the boundary between scripting languages and general-purpose languages. DSLs are languages (or most often, declared syntaxes or grammars) with very specific goals in design and implementation. A DSL can be either a visual diagramming languages, such as those created by the Generic Eclipse Modeling System or the Generic Modeling Environment , programatic abstractions, such as the Eclipse Modeling Framework , or textual languages. For instance, the command line utility Grep has a Regular Expression syntax which matches patterns in lines of text. The Sed utility defines a syntax for matching and replacing regular expressions. Often, these tiny languages can be used together inside a Shell to perform more complex programming tasks. The line between DSLs and , GIF , JPEG , etc, where Csound compiles to audio files, and a ray-tracing DSL like POV compiles to graphics files. A computer language like SQL presents an interesting case: it can be deemed a DSL because it is specific to a specific domain (in SQL's case, accessing and managing relational databases), and is often called from another application, but SQL has more keywords and functions than many scripting languages, and is often thought of as a language in its own right, perhaps because of the prevalence of database manipulation in programming and the amount of mastery required to be an expert in the language. Further blurring this line, many DSLs have exposed APIs, and can be accessed from other programming languages without breaking the flow of execution or calling a separate process, and can thus operate as programming libraries. Some DSLs expand over time to include full-featured programming tools, which further complicates the question of whether a language is domain-specific or not. A good example is the Functional Language XSLT , specifically designed for transforming one XML graph into another, which has been extended since its inception to allow (particularly in its 2.0 version) for various forms of filesystem interaction, string and date manipulation, and data typing. In Model Driven Engineering many examples of DSLs may be found like OCL , a language for decorating models with assertions or QVT , a domain specific transformation language. However languages like UML are typically general purpose modeling languages. To summarize, an analogy might be useful: a Very Little Language is like a knife, which can be used in thousands of different ways, from cutting food to cutting down trees. A DSL is like an electric drill: it is a powerful tool with a wide variety of uses, but a specific context, namely, putting holes in things (although it might also be used to mix paint or remove screws). A General Purpose Language is a complete workbench, with a variety of tools intended for performing a variety of tasks. DSLs should be used by programmers who, looking at their current workbench, realize they need a better drill, and find that a specific DSL provides exactly that. REQUIREMENTS Design goals Adopting a DSL approach to software engineering involves both risks and opportunities. The well-designed DSL manages to find the proper balance between these. DSLs have important design goals that contrast with those of general-purpose languages:
Redundancy of a program is defined as the average number of textual insertions, deletions, or replacements necessary to correctly implement a single stand-alone change in requirements. For a language, this is averaged over programs in the problem domain. This measure is useful because, the smaller it is, the less likely that bugs can be introduced by incompletely implementing changes. Idioms In programming, idioms are methods imposed by programmers to handle common development tasks, e.g.:
General purpose programming languages rarely support such idioms, but DSLs can describe them, e.g.:
EXAMPLE UNIX shell scripts give a good example of a DSL for data organization. They can manipulate data in files or user input in many different ways. Domain abstractions and notations include streams (such as stdin and stdout) and operations on streams (such as redirection and pipe). These abstractions combine to make a robust language to talk about the flow and organization of data. The language consists of a simple interface (a script) for running and controlling processes that perform small tasks. These tasks represent the idioms of organizing data into a desired format such as tables, graphs, charts, etc. These tasks consist of simple control-flow and string manipulation mechanisms that cover a lot of common usages like searching and replacing string in files, or counting occurrences of strings (frequency counting). Even though UNIX scripting languages are Turing-complete , they differ from General Purpose Languages. There is no mechanism for creating complex data structures such as lists and trees. There is no support for object oriented design. In practice, scripting languages are used to weave together small UNIX tools such as AWK (or gawk), Ls , Sort or Wc . Although notorious for its use of Greek letters and special symbols, the APL programming language, with its interactive session, provided for rapid design and deployment of interactive and scriptable domain specific languages. These usually, by design, required no special input consideration from its users such as APL keyboards or fonts. SOFTWARE ENGINEERING USES There has been much interest in domain-specific languages to improve the productivity and quality of Software Engineering . DSLs could possibly provide a robust set of tools for efficient software engineering. Such tools are beginning to make their way into development of critical software systems. The SCR (, a dependency graph browser to display variable dependencies, a Consistency Checker to catch missing cases in well-formed formulas in the specification, a Model Checker and a Theorem Prover to check program properties against the specification, and an invariant generator that automatically constructs invariants based on the requirements. A newer development is Language-oriented Programming , an integrated software engineering Methodology based mainly on creating, optimizing, and using DSLs. ADVANTAGES
DISADVANTAGES
SEE ALSO
EXTERNAL LINKS
REFERENCES #Constance Heitmeyer. Using the SCR Toolset to Specify Software Requirements. ''Proceedings, Second IEEE Workshop on Industrial Strength Formal Specification Techniques'', Boca Raton, FL, Oct. 19, 1998. #Diomidis Spinellis. Notable design patterns for domain specific languages . ''Journal of Systems and Software'', 56(1):91–99, February 2001. doi:10.1016/S0164-1212(00)00089-3 #Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domain-specific languages. ''ACM Computing Surveys'', 37(4):316–344, 2005. doi:10.1145/1118890.1118892 #Dunlavey, "Building Better Applications: a Theory of Efficient Software Development" International Thomson Publishing ISBN 0-442-01740-5, 1994. > |
|
|