Or even, come up with a new, batteries included version.
Eg. keep the Java syntax, but add one standard package manager (instead of ant, mvn, gradle), one standard test framework, standard formatter, etc. Call it 'Java++' or whatever.
Or even, come up with a new, batteries included version.
Eg. keep the Java syntax, but add one standard package manager (instead of ant, mvn, gradle), one standard test framework, standard formatter, etc. Call it 'Java++' or whatever.
Alternatively you build a thing that every other system could be auto-migrated to, which inevitably means supporting every possible feature of everything in play and slapping an ANSI standard label on it; and then watch as everyone extends the standard arbitrarily
I guess you don't get much for yourself, but you get closer to some form of community standard. This ultimately helps your codebase "grow" when you need help from, or need to hire, other people. Other people that know those standards.
Unless that 25% usage choice eventually grows to full usage… but I can’t predict the future — so I’m just betting on it. But that bet also does very little for me even on success (it’s definitely nicer to be normal, but it’s hardly critical), and I could just as well make the migration after it’s become a real standard with no risk.
So why am I migrating?
However, there are very painful things like modern compilers which are massive undertakings for an old languages. It cost Microsoft 3-4 years to rewrite the C# compiler to be modern. But the benefit is a language server which keeps pace with the compiler and refactorings on the same AST (aka more stable/reliable).