{'fraction_non_alphanumeric': 0.022817460317460316, 'fraction_numerical': 0.000992063492063492, 'mean_word_length': 5.726666666666667, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Open challenges in incremental coverage of legacy software languages

Legacy software systems were often written not just in programming languages typically associated with legacy, such as COBOL, JOVIAL and PL/I, but also in decommissioned or deprecated 4GLs. Writing compilers and other migration and renovation tools for such languages is an active business that requires substantial effort but has proven to be a successful strategy for many cases. However, the process of covering such languages (i.e., parsing their close overapproximation and assigning the right assumed semantics to it) is filled with unconventional requirements and limitations: the lack of useful documentation, large scale of codebases, counter-intuitive language engineering principles, buggy reference implementations, fragile workarounds for them, etc. In this short paper, we motivate the incremental nature of software language engineering when it concerns legacy languages in particular, and outline a few related challenges.