On my way home from my workout I thought about service programs, signatures and binder language. Every once in a while when someone asks about service program signatures I get a scolding for suggesting the usage of binder language.
Don't use binder language! Just recompile every program which has the service program as a dependency.
is the most common answer.
Yes, this might work in some cases. But as service programs should be the base for your applications you will have many service programs and some service programs will be a central piece of work in your system. When you have hundreds or even thousands of programs and/or service program one little change in a service program may ripple through your whole system and may result in a recompile of your whole system. And for what? Because you added a new procedure to a service program? This may not be an acceptable situation.
And this also leaves the developer with a bad experience with service programs. It may even have the opposite effect. Instead of embracing the ILE concept and service programs the developer may get driven away from it by this experience.
Another point is that in the open source world we don't know the dependent programs and thus need to be even more careful with compatibility and the service program signatures.
So why not use the tools available to make it work for you?! Binder language is one of those tools. But yes, you must know what you do when using Binder Language. But hey ... don't you always have know what you do?!
And when we look at the world outside of IBM i native languages we see that most of them manually set the compatibility of the different versions of a program or library. The most common versioning scheme is semantic versioning. They don't recompile whole systems. They use the version number to determine if everything is still compatible. A good example of that is Java (with Maven).
I think we just need a better tooling support. I will add this to MiWorkplace step by step.