language-oriented programming

The term "language-oriented programming" (LOP) is these days mainly used by JetBrains and refers to the underlying paradigm of their Meta Programming System. I will blog about that later. For now I want to focus on Martin Ward, because the LOP term was actually coined by him in 1994 with a paper entitled Language Oriented Programming. There he describes what I consider the core idea of meta-programming. And in fact he names many of the benefits, problems, guidelines and other insights that one can find in today's discussions about MDSD. Here is an extraction of these:

benefits:

• smaller code size
• increased readability
• encapsulation of programming knowledge
• separation of concerns between design and implementation issues
• high development productivity
• improved maintainability
• improved adaptability
• fewer bugs
• highly maintainable design
• localized effects of design decisions
• highly portable design
• opportunities for reuse
• finding good notation can take you half way to a good solution

problems:

• good language design is hard
• writing very high-level languages can distance the programmer from certain efficiency constraints
• new languages need supporting tools for programming and debugging

guidelines for designing DSLs:

• common objects in the domain appear in the language
• common operations in the domain available as language constructs
• conceptually simple and easy to parse for humans and computers For me the readability for humans is most important. The problem of machine readability can be solved once, for instance by using an OMeta parser
• use latest developments in programming language design and implementation.
• as opposed to 4GL, restricting the language to a specialized domain
• orthogonal combination of new language constructs
• Hoare's four basic principles of language design:
  • security:
    • reject syntactically incorrect programs
    • running syntactically correct program should produce a result or an error message expressed in terms of the source code.
  • brevity of object code and compactness of run time working data
  • no impediments to the use of convenient high-level facilities in the language, e.g. concerning efficiency
  • the language should be parsable in a single pass with a simple recursive-descent parser. In those days PEGs did not exist. Today they are the way to go, in my opinion.
• have textual redundancy I disagree here. Redundancy must be provided and must be manually held in consistency. Both is time consuming and cumbersome. Furthermore redundancy increases code size without adding new functionality

other insights:

• DSLs may form language layers
  • highest level language is usually interpreted.
• a class library is in fact an example of a domain-specific language (albeit with a highly restricted syntax)
• language-oriented programming is a generalization of the compiler idea
• one can form new transformations by composing existing ones
• use system to maintain and enhance its own source code

conclusion

It's very interesting to see how old the idea actually is and how it is examined in the context of the 90's. Hey, in those days I was a young boy who went to the football area in his free time. Ward did not only think theoretically about the topic but provided concrete implementations such as the Wide Spectrum Language and the FermaT Program Transformation System.

But it's important to note that Ward did not see everything what the topic means today. For example, as far as I can see, he only had command languages in his mind, as opposed to descriptive ones which are preferred today. For him Tex, Latex, Perl and Emacs are domain specific languages. From today's perspective these languages are rather huge. Although they idea behind their invention is the same one would not call them domain specific languages today.

Although Ward coined the LOP term he again was not the first who came up with the idea of domain specific languages. In his paper he mentions the Draco project "which has recognised the value of capturing domain knowledge in the form of a language [and] aims to encourage the reuse of design information in future program development projects by the use of domain languages together with the recorded results of a domain analysis." It seams that the DSL idea is quite obvious as it came into the mind of many different people. In retrospect this is not surprising because the main paradigm behind it is to find appropriate abstractions, something humans always do in order to gain control over complex systems.

I won't go further back in history to investigate the origins of the DSL idea. I want to focus on today and as far as I can see what has always been missing are appropriate tools to specify and implement domain specific languages, write program with them and debug the programs. Ward only noted this as a problem without tackling it. For me, solutions to this are crucial for the idea to become practical. So next I want to have a look at what others like JetBrains and Intentional Software came up with.