All app and program developers know the pain of setting up a development environment.
In the world of smartphone apps, where applications are isolated from each other to avoid interference, the old situation of a new app not working correctly due to the influence of other ones past installed has been dramatically reduced.
However, suppose you want to “develop an app” rather than simply install an app. In that case, you need to install various programs dedicated to building apps (such as a program editor like Visual Studio or AI creation libraries like TensorFlow).
These are usually called “development environments,” but here, let’s call them “development tools” to distinguish them from “virtual environments,” which will be discussed later.
Development tools change the settings of the OS (environment) more frequently than typical applications. Furthermore, in many cases, developers build new apps one after another.
Therefore, it is necessary to add new development tools for new apps, again, and again, and again, and so on. Sometimes the configurations of each development tool are not compatible with each other.
Most of the development tools have instructions on using and installing them. However, this only works in a “clean, no other development tools” environment.
In an environment with a unique history full of past development tools (also called “Omakan”), it is often impossible to install as described in the document (or rather, impossible to install without modification).
Developers then have to figure out which setting in their environment is causing the problem. However, this process is just a waste of time (it doesn’t produce anything, and the know-how gained is often not applicable elsewhere).
In other words, it’s tough to fix your old environment.
So it’s better to build one from scratch.
This situation is where the “virtual environment” approach came into vogue.
Next entry (coming soon)
