I am particularly interested in Groovy’s support for Domain-Specific Languages.
It occurs to me that providing users with a domain-specific language is very close to issues that surround the design of interfaces for users.
That is you don’t write a “domain-specific language” and then expect others to use it. Well, you could but uptake might be iffy.
Rather the development of a “domain-specific language” is done with subject matter experts and their views are incorporated into the language.
Sounds like that might be an interesting approach to authoring topic maps in some contexts.
From the website:
- is an agile and dynamic language for the Java Virtual Machine
- builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk
- makes modern programming features available to Java developers with almost-zero learning curve
- supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain
- makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
- increases developer productivity by reducing scaffolding code when developing web, GUI, database or console applications
- simplifies testing by supporting unit testing and mocking out-of-the-box
- seamlessly integrates with all existing Java classes and libraries
- compiles straight to Java bytecode so you can use it anywhere you can use Java
Questions:
- What areas of library activity already have Domain-Specific Languages, albeit not in executable computer syntaxes?
- Which ones do you think would benefit from the creation of an executable Domain-Specific Language?
- How would you use topic maps to document such a Domain-Specific Language?
- How would your topic map record changing interpretations over time for apparently constant terms?