They can also design their own ISA. An ISA is a document, they can write their own. Now, can you think of reasons why they wouldn't want to do it that don't also apply to MIPS?
Besides the dependency management, another major problem of Python is the deployment. Although Docker is not a dependency management tool, it can be used as a deployment tool which encapsulates the application to be deployed, python runtime and all other shared libraries dependencies alongside the configuration. Another deployment tool that is worth mentioning is Pyinstaller. It can pack the python runtime, the application and all dependencies into a single native executable. Pyinstaller is better for Desktop applications and for building single file executable applications.
Python dependency management of packages using C or C++ behind the scenes is really problematic and sometimes, the installation may fail. In this case, a solution is to use Conda or mini conda which provide many pre-compiled packages and also Clang C++ compiler.
An alternative way to allow people without software engineering background to play with Python data science and machine learning tool may be providing pre built Docker images with everything pre-installed which may save one from configuration trouble.
Docker is also useful for learning about new programming languages without installing anything. With just one command $ docker "run --rm -it julia-image", one can get a Docker image containing a GOLang compiler; a Julia language installation; a Rust development environment and everything else. Docker is really a wonderful tool.
Docker is definitely an interesting tool for that, but my biggest problems is that I have to teach them Docker, which is a totally new layer of abstraction they haven't seen before.
How do you approach this? How technical are people you prepare Docker images for?
You don't need to teach docker. All you need is providing a docker image with everything pre-installed such as Julia, R language, Python, numpy, pandas, Tensorflow and maybe Vscode. And also any Linux distribution, then one can just type "$ docker --rm -it -v $PWD:/cwd -w /cwd my-image ipython" For better convenience, it is better creating a command line wrapper or shell script that saves one from typing that such as $ ./run-my-image ipython. I don't prepare anyone, but I guess that if I knew anything about docker and was given a docker image with everything ready and pre-configured and also a shell script or command line encapsulating all docker command line switches, I would find it more convenient than installing everything myself or fighting some dependency conflict or dependency hell. So, docker can be used as a portable environment development. VScode, aka visual studio code, also supports remote development within docker containers with extensions installed per container. I am a mechanical engineer by training, but I found docker pretty convenient for getting Julia, Octave, R language, Python, Jupyter Notebook server without installing anything or fighting with package manager of my Linux distribution when attempting to install a different version of R, Julia or Python. This approach makes easier for getting bleeding edge development tools without breaking anything that is already installed. I even created a command line wrapper tool for using docker in this way that simplifies all those case: $ mytool bash jupyter-image; $ mytool daemon jupyter-notebook ...
The trouble of distributing Qt in binary format is the C++ non standard ABI problem. Qt has to be compiled for every possible compiler and many different versions of the same compiler, in order to avoid linking error. On Unices, most compilers, specially GCC and Clang, are using the Itanium ABI, but on Windows, compilers still have different ABIs, so linking against Qt shared libraries built with older versions of MSVC compiler may result in linking error. On Linux, there still the problem of implicit dependency on GlibC (GNU C Library), most applications built using newer versions of GlibC will not work on distributions using older versions of GlibC. It would be nice for Linux Desktop, if GlibC did not break the binary compatibility.
That said, the most suitable way to get Qt binaries for development may be using a C++ package manager such as Conan or Vcpkg which can cache the library compilation output and reuse it on many different projects without recompilation, unless the current compiler has an incompatible ABI.
Conan C++ package manager recipes can also provide pre-compiled binaries which reduces the compile time pain. Another interesting tool is the conan server which allow fetching conan recipes and pre-compiled binaries on the local network or across the internet.
In practice there are not so many. And e.g. on Windows I use an old VS compiler version and can then also use it with later VS versions (but not vice versa). Linux is also no issue because Qt is usually part of the distribution, i.e. there is no need to compile it as long as you depend on the standard version (not a custom one).
Personally I don't work with package managers, but prefer so setup and control the environment myself. It's not that difficult, and there is also Docker.
On Windows, MSVC does not provide guarantees that it will not keep the ABI on new releases. The drawback of using the Qt provided by the Linux distribution, is the reproducibility of the development environment as it is not possible to control the version of the Qt installed and also to have multiple Qt installations with different versions. As a result, the compilation of a Qt application may fail on different Linux distribution which uses a different and incompatible version of Qt. Docker can solve the reproduciblity of the development environment problem, but it still does not integrate well with development tools such as IDEs, building systems and so on.
The advantage of a package manager is the reuse of binary artifact on many projects and also the control over the library version. Conan package manager could be used for providing pre-compiled binary artifacts of Qt library. For instance, provides pre-compiled boost library and poco library for lots of different compilers, compiler versions and operating systems which saves one from building and installing those libraries.
In the case of SpaceX, it seems that they use embedded Linux and C++ with x86 processors, same as standard PC processors. A reason for using embedded linux is that, it allows using standard C++ or even scripting languages for controlling the hardware from the user-space by just reading and writing files. Linux device drivers (aka kernel modules) maps the hardware to special files on /sys or /dev. For instance, it makes possible to control a GPIO (General Purpose IO) which the device driver maps to sysfs special file system, by just writing 1 or 0 to the file a like /sys/class/gpio/gpio4/value which would enable GPIO 4 and turn on a LED attached to it. Another practical example about this feature is that, on Linux, it is possible to turn on or turn off the keyboard capslock LED by writing to some /sys/class/leds file such as "$ echo 1 > /sys/class/leds/input7\:\:capslock/brightness" which turns on the Capslock LED. By writing 0 to it, the LED is turned off.
This feature of Unix and Linux allows controlling the hardware with any programming language capable of reading and writing files, including Python and standard C++. I guess that they may be using standard PC hardware with industrial IO card. They may also use a single-board computer or custom board with x86 low-power variants processors built for embedded applications as SOC system-on-chip. One example of low power x86-SOC based processor is: https://www.cnx-software.com/2015/04/09/vortex86dx3-is-a-new...
