8

We have a scripting language that we use internally for many things. It began as a simple evaluation statements for dynamic labels to become a Turing complete language used pervasively throughout our system.

Problem is that it was never designed for this and it shows. Development environment is anemic, scripts produced are not testable and still to this day there is not formal definition of the language.

A growing sentiment among the language's users feel that it has done it's job and it's time to let go but we are faced with a difficult challenge to migrate existing codebase to whatever new solution would be devised. This very argument is used against the idea of migrating.

Have you ever faced a similar situation ? and if so what strategies did you use to stop usage of the old and promote the new ?

One last thing (thanks Morons) is that many of these scripts are not documented and their original purpose is lost though they are still in active use. The scripts are also used at customer sites to customize the system so we have literally thousands of these scripts a large portion of which is not under source control or any versionning mechanism for that matter.


Accepted answer.

Difficult choice this is. All answers were good and sound advice though I think the best lies somewhat of a hybrid of Moron's and Oliver's.

I ended-up accepting Oliver's because it is the answer that stands the best chance of getting accepted higher up (ha! politics!). Packaging the old scripting environment in a callable statement that can be integrated in the new environment would provide a quick and easy upgrade path.

Once done we can control better creation of new scripts by displaying warnings or disallowing all-together old scripts from being edited or created forcing to go with the new language.

Thanks all for your input !

Newtopian
  • 7,221

3 Answers3

11

The fact that you are dealing with a custom scripting language is irrelevant. You are migrating a set of scripts from one language to another.

There are 2 basic strategies:

1) Take an on large effort to convert all the scripts upfront (as a project)

2) As you need to make changes to particular scripts, rewrite them in the new language. After some time, when there is only a few scripts left in the original language, go ahead an take on a project to finish those off. *

Either way you need to set a hard and fast rule: No New code is written in the legacy language.

*You may also set a rule on how much you are allowed to edit before having to re-write the whole thing, But this is likely to be abused as a loop hole.

Morons
  • 14,706
5

Another approach would be to port your scripting run time to the new scripting language of choice and provide ways for executing legacy scripts within the new language.

LegacyRuntime.execute(String script);

Being able to mix old and new code should ease the transition.

OliverS
  • 1,285
5

I had such an experience.

My approach was to reverse-engineer the language implementation, deriving a more or less formal specification for its syntax and semantics (imagine deconstructing a BNF out of a handwritten parser in Fortran77, with several thousands of keywords). Then I've implemented a compiler for this language, translating it into an idiomatic Lua code (even preserving most of the comments).

You can choose any suitable popular scripting language or implement your own better designed DSL. Compiler could be used as a transparent translation layer (keeping the legacy scripts intact) or for rewriting the scripts for a better further maintenance.

SK-logic
  • 8,517