There are too many complaints heard about customers who are changing requirements. This is BS. The requirements are not changing, our knowledge about the requirements does. Most of the time the customer cannot be blamed for the missing pieces. Nobody knows all the requirements at the beginning. Too bad if the environment forces us to pretend that our knowledge about the requirements is complete. The process should allow requirements to be developed together with the product. The exceptions to this rule are trivial cases.
There are compiled and interpreted computer languages.
There are many languages, which are called compiled, but their “compiled” code is some kind of intermediate code, not machine code. The software which executes the intermediate code is often referred as Virtual Machines. In my eye these VMs are only interpreters. Weak ones: they require preprocessed sources.
Real compilers produce machine code. If you want speed, you need machine code. Using the right algorithm for the computing is even more important.
Using the good algorithm is essential, but then you want the software spend the time on executing operations defined by the algorithm, and not wasting the time on interpreting code and searching for the operands. The fastest code finds the operands in fixed relative positions of a single context. Searching for operands by name on several contexts which embed each other could slow down the execution of the algorithm multiple times.
Sounds like this is about programming.
Requirements are often complex and this make every software which can do something what is more than trivial also complex.
What makes the requirements complex? Partly because we have to support a lot of legacy stuff in every system. Software is usually built on top of existing libraries. It would be insane to develop button drawing functions in every software which has GUI. This desktop would be ugly, unreliable and too much time wasted.
Selection of cross-platform widget libraries is shockingly short (not counting the wrappers).