Common criticisms here would be that these endeavors stifle creativity and show the adoption of modern solutions. That said, I find conducting “code archeology” to figure out the idiomatic way of doing something in an old project very rewarding. Because computer programs exist in people’s mind’s, doing that with the support of original developers or subject matter experts is some of the most effective knowledge transfer I’ve ever witnessed.
That makes sense. I’m also involved in localization efforts. In niche cases, it’s paid off to work with the clients directly on that. You get you a good balance between correctness and day-to-day usefulness.
Since ladder is mostly diagram-based it almost doesn’t need to be localized and isn’t jarring when you use non-English variable and function names with English keywords.
Industrial controls equipment made by German companies can be programmed in English or German. You can also switch languages (German/English) at any time and the IDE switches over all the keywords.
There’s a lot to talk about from this point alone, but I’ll be brief: having gone through university courses on processor design and cutting my teeth on fighting people for a single bit in memory, I’m probably a lot more comfortable with that minutia than most; having written my first few lines of C in 10 years to demo a basic memory safety bug just an hour ago, you’re way way ahead of me.
There are different ways to learn and gain experience and each path will train us in different skills. Then we build teams around that diversity.
Like if the variable is then used in a function that only takes one type? Huh.