Jonsey - whether as his actual opinion or as "Devil's advocate" to get me to try to justify mine - argued in a response to my essay introducing the Hugo programming language and authoring system, that Hugo is not a "domain-specific language" (DSL), and I'd like to offer my reasons why it is, why there's nothing wrong with it being one, and what alternatives should be considered.
I'm not alone in making this observation. I was having a conversation with a user of this board and when I stated that my opinion was that Hugo is a DSL they agreed. There are other similar interactive fiction development systems such as
to clarify, a domain-specific language is one where the grammar, commands and syntax is primarily oriented to the solution of a specific problem or class of problem, as opposed to general-purpose languages that are open to virtually all types of problems. Macro languages such as those used in spreadsheets or the macro languages available in macros of word processors are examples of domain-specific languages. The original MSDOS bach language is an excellent example of a DSL.
Prior probably to 1990, the most popular programming language in the world was... COBOL. While it was capable of being a general-purpose language, it was strongest in the domain-specific handling of record-oriented processing, especially either batch or pseudo-interactive. Handling payments, making them or taking them; generating reports, sorting, searching and the other features directly related to business processing, made COBOL an ideal language for those purposes. And is still used on large mainframes, as there are programs, written in COBOL, that their owners have spent decades updating and invested literally millions of dollars in the care and feeding of those applications. These applications literally manage trillions of dollars of assets. And as long as what is done on those mainframes is the same workloads, COBOL will continue to be used. It is a general-purpose language whose domain-specific attributes make it perfect for those problems.
I would not consider COBOL a good language for writing a word processor or web server, it just does not have the specific features useful for those types of applications. PHP is a very good language for writing server-side applications on web servers, but chances are, COBOL works better for the retrieval and processing of data on mainframes, because those programs have been well-debugged over decades, all the bugs have been worked out.
The same thing applies to Interactive fiction. If whichever language used fits the problem domain, then the language is the right choice. The question is whether the language does support the features needed now. When Interactive Fiction was exclusively text-based, then any of these languages would be acceptable. We may want to ask, are the additional graphic-related features adequate for today's story demands? Graphic images and video playback along with sound selection might be enough, or it might not.
Perhaps what is necessary is not merely Interactive Fiction tools, but general game production tools, but possibly with either much lower learning curves than full-blown Unity- or Blender-engine based games. Maybe some of the features of these IF languages along with additional features more appropriate to games than typical general-purpose languages. Perhaps more event processing capacity, better string and numeric functionality, ability to handle other things than we have been doing so as to allow for things like visual novels. Handling SVG images would allow for dynamic images that can change as needed. Being able to click on, not just images, but motion pictures as well.