Reengineering Tips for Choosing the Correct Programming Language

Ryan Berkheimer, CEO, ZVS

At ZVS, we regularly do reengineering/refactoring work on large polyglot software systems, with Shell (Bash), Java, Fortran, Go, and Python being some of our most commonly encountered languages. When folks come to us for a reengineering effort, before the first code review, we can generally predict a lot of the patterns we will encounter.

As part of our service, we advise our clients on patterns of behavior that they should implement in new projects to avoid getting to a place where they need to do repair work. Here are 5 of our favorite rules of thumb when tackling a new project:

  1. Don’t mix languages upward. Are you making system calls from python, fortran, or java? You’re going to run into problems with this if you ever try to port your software (even docker will fail you here eventually due to bit rot). Bash (or csh, zsh, ksh, etc.) is your glue language, use it as such. This will also provide better mutability on the system level, in the case that other languages become involved (it’s a lot easier to glue together a fortran/java/c/python polyglot system using bash than doing it from python).
  2. Are you using repeatable functionality? Probably time to move out of shell into a more advanced language. Bash name-spacing is much less developed, consistent, and stereotyped than programming languages like python or java.
  3. Are you starting to use awk and sed a lot in bash? Is this program long lived? Move it into another language, where you can define functions that people later on will understand more easily. System level tools are fine for one-off processes, but they are so flexible that they often become liabilities in larger and long-lived systems.
  4. Are you doing systems type work? Generally it’s fine to keep this in shell. Shell is a systems language, so is safe and even preferred to be used as such. Although again, you might have better choices here. What if you eventually move from a directory or ftp ls to object storage? If you have your code in python, you’ll already be able to swap out functions, because you’ve already reasoned the program in that way. Bash will take longer to refactor because you did it in a one-off way.
  5. If you’re starting out doing something and you don’t know if it’s going to be one-off or not, don’t worry about the language you’re doing it in so much. Do it in whatever’s easiest. BUT – once you’re done, do a second pass while it’s fresh. Make sure you’d be comfortable maintaining the code in the case that it becomes a long-term thing (it happens more often than not).

We hope these tips are useful for your own work. If you’d like to discuss how this would apply in your own systems, please feel free to contact us!

Leave a Comment