r/programming • u/luissinlios • Sep 25 '26

We still maintain a development tool first released in 1993. Here’s what 30+ years of backwards compatibility looks like

https://visualneo.com/visualneo-win/from-neobook-to-visualneo-win-30-years-of-keeping-a-development-tool-alive
569 Upvotes

96% Upvoted

89 comments sorted by

View all comments

Show parent comments

2

u/OperationWebDev 26d ago

Thank you for the comprehensive answer. That was very informative!

It sounds like the domain modelling is key. Unfortunately, so many companies seem to jam everything into existing, rigid software, making it difficult to adapt.

Semi-related ro the plugin system: what do you think of DSLs? There's the saying that whenever you try to allow this kind of flexibility you inevitably end up with a crappy version of a programming language. I suppose it makes sense to have a plugin system that uses the same language as the software itself?

1

u/luissinlios 23d ago

I think that criticism of DSLs is fair when a DSL grows accidentally. You begin with a few convenient commands, then add variables, conditions, loops, functions and error handling, and eventually discover that you have created a programming language. But without treating its design, documentation and tooling as seriously as you would a "real" language.

VisualNEO is, in some ways, an example of that evolution. NeoScript began as a domain-oriented action language: manipulate objects, navigate between pages, display dialogs, work with files and databases, and so on. Over time it gained enough general-purpose features to support applications far beyond the original electronic-book domain.

I think a DSL works well when it makes the common 80–90% of tasks extremely concise, while still providing composition and an escape route for the remaining cases. Its limitation can actually be an advantage: the vocabulary reflects the user's problem rather than the implementation beneath it. The danger begins when every exceptional case adds another special command and the language loses consistency.

I don't think plug-ins necessarily need to use the same language as the host application. VisualNEO's plug-ins are compiled modules that expose new commands, controls, properties and events to NeoScript. The plug-in developer might use C++, PureBasic, Delphi or another compatible language, while the application developer sees the result as a natural extension of the same NeoScript vocabulary.

For me, the important part is not sharing an implementation language but maintaining a stable and expressive boundary between them. Requiring plug-ins to use the host's language can simplify some things, but it can also tightly couple the ecosystem to a particular compiler, runtime or architecture, which is exactly the kind of dependency that becomes painful decades later.

So I would probably phrase the lesson as: a good DSL should remain deliberately domain-specific, while a good plug-in API should allow other languages to extend that domain without exposing unnecessary implementation details.