DSL : Java Glossary

Digital Subscriber Loop

DSL (Digital Subscriber Loop) technology often called ADSL (Asymmetric Digital Subscriber Line technology). It is a way of using old telephone lines for high speed digital communications. It competes with cable for providing home Internet access.

Domain Specific Languages

DSL (Domain Specific Language) is also a specialised language for dealing with a particular narrow class of problem. You can either create an entirely new language or embed it in an existing one. Embedding has the advantage of giving you the full power of the underlying language for extensions. Making it a separate language gives you greater freedom in designing the syntax.

The advantages of DSLs (Domain Specific Languages) are:

• Terser code. This makes it easier to see the forest for the trees. It makes maintenance easier. It makes bugs less likely.
• Non programmers can often use the languages directly.
• You are not locked into one vendor or platform. You can port your system and all your application code works identically and unmodified.

• Abundance: data entry.
• Ant: build, cross-platform scripting.
• AWK: text manipulation with regular expressions.
• JavaCC: parsing.
• JESS: rule inference engine.
• Ladder Logic: used in process control automation.
• Martin Fowler’s Agreement language: invoices and payments.
• MatLab: algebra and calculus.
• PostScript: typesetting.
• PUT language: language for describing how to do things, such as assemble a stereo system.
• SQL: databases.
• XML: wasting bandwidth

Most DSLs are much smaller, simpler and local than the examples I gave and hence not well known. I wrote one called JCLGEN to simplify IBM (International Business Machines) mainframe JCL (Job Control Language). I wrote another called QSL (Queue Simulation Language) to efficiently collect statistics on queue simulations. I wrote Abundance to handle data entry and lookup.

What we nearly always do is twist a problem around until it can easily be specified to a computer. What we could do is create a DSL that let people describe the problem in the same terms they about it. Then have programmers figure out a way to translate this into something the computer can understand.

Which approach is best? If the problem small, there is not enough payback for creating the translator. So you should go with the traditional approach. If the problem is large, then you save enormous amount specifying the problems, maintaining the policies, proofreading… if you code in a DSL.