Arbitrary Programs that Halt
There are many issues in your question. I am no longer very expert in some
of them, but let's try.

Basically, a standard program as you like it takes some input $I$,
satisfying some property $P$, and does things with it so as to obtain
an output $O$ satisfying some property $Q$ involving $I$ and $O$:
$Q(I,O)$.

This program solves a problem corresponding to a constructive proof
that $\forall I, P(I) \implies \exists O, Q(I,O)$. The problem is to
find $O$ when given $I$. This may actually be read as a specification of the problem, of the program.

It is easy to apply this to a sorting program, for example.

This works nicely in functional programming.

But when you quit functional programming, things become harder to
explain.

Typically, printing a string is a side effect, hence not functional.

If instead of printing you were considering just producing the string
"Hello world", for whatever purpose, the you would have a functional
program meeting a degenerate case of the above schema, because there
is no input.

The problem reduces to: produce the string "Hello world"
and corresponds to the specification $\exists O, O=\text{"Hello world"}$.
The lack of input makes the universal quantifier unneeded.

But printing is something else, as is network reconfiguration. They are not directly functional operations.

Now, it is possible to simulate non-functional structures in a
functional context by building appropriate domains of computation. But
this often makes things a lot more complex. And the understanding I
tried to give is no longer so obvious.

Dealing with these issues has been one of the main purposes of
denotational semantics. Much of the research in language design is
about bridging the gap between functional understanding and the
requirements of non functional practices.