The power of probabilistic programming is not in running the programs forward to generate output. That pretty much does just come down to calling random() sometimes to alter the flow of the program. Having built-in syntax for that would be nice for modelling stochastic processes, but we can already do that.
The big deal is being able to run the program backwards. I.e., you already have some set of output, obtained from some other source, and you want to figure out how that output could have been produced (i.e., how the source works). So, you write a probabilistic program that encodes your various hypotheses about how the source process works, and then run it backwards to figure out what the forward execution path would have had to have been to produce that output, and thus which hypothesis is correct. That's what "inference" refers to.
Inference is a basic process in scientific investigation- come up with a bunch of hypotheses, do an experiment that generates data through physical processes independently of whatever you hypothesized, and then go backwards to figure out which of your hypotheses would have had to have been true in order to get the experimental output that you did. Which hypothesis is true corresponds to a particular execution path through a probabilistic program, so having efficient implementations of probabilistic languages means we could do much better at accurate analysis of data, which is Good For Science.
general inference on a graph of dependant variables is NP-hard to do exactly. So you use a sampling based method to converge towards the right solution and stop when it looks about right. However, for many smaller problems there is an exact analytic solution.
Real problems in the wild are a mix of both types of problem, and intractable part and a part you can do precisely.
In an ideal world you would use the iterative methods ONLY for the parts that don't have an exact solution available. In practice once you have developed the general iterative solution, you might as well just use that for the easy parts too, as you are just burdening yourself with more development work and more scope for bugs by writing two inference implementations.
A language that allowed inference to be switched at no development cost it would be amazing
Aside from what other commenters already said, inference is fiddly and easy to screw up when you have to do it yourself. Errors in statistical analysis are not uncommon, even in peer-reviewed papers. Automating it is good for two reasons: first, it reduces the error rate in the kinds of analyses already being done; second, it opens up the option of doing much more complicated analyses, either with a larger number of hypotheses or with hypotheses of greater complexity, which would otherwise be ignored as infeasible.
Both of those result in the potential for greater confidence in the accuracy of conclusions reached from experimental analysis.
Experimenting with more models increases the likelihood you'll find a good model. A good model is, by definition, a more accurate representation of your domain than a bad model. It will also tend to generate more accurate predictions, if that's what you care about.
As a secondary point, re-implementing inference code for each new model makes it almost certain that there are bugs in said code. So even without changing the model, automatically generated inference code is likely to have fewer bugs and thus give more accurate inferences than hand-written code. (assuming it runs to convergence; naturally there are lots of scenarios in which naively generated code will be slower to converge than something hand-tuned).
I don't consider bugs in code a matter of accuracy of the model. And while you can compare the accuracy levels of various models, having a compiler do the inference or you do the inference doesn't chance the accuracy. I also don't subscribe to the idea that the right model for a scientific or statistical phenomenon is a random event.
(1) Even very simple linear models in effect encode uncountably many hypotheses (i.e., y = a x + b where a and b are real numbers). You can't just pull (a,b) out of a hat until the agreement looks good, because the hat is too big.
One tool is, obviously, analytic solutions (where possible) like least squares. Beyond that, iterative methods like the EM algorithm. Beyond that, sampling-based methods like MCMC. You can view MCMC as your idea ("generate a bunch of hypotheses and test them"), but with the change that it does not ignore the old hypotheses when generating a new one to test, it uses an old hypothesis to seed a new one, using a probabilistic update rule.
In the presence of a model, you can basically compile (in the CS sense) an inference program that deduces model parameters from input data. The project to do this has been worked on, in fits and starts, since the late 1940s, by a series of geniuses/visionaries.
(2) Once you have a multi-level model, with many parameters, trading off what you gain by tweaking one parameter versus another parameter becomes hard. If the data is
(x1,y1), ..., (xN,yN)
and you generate approximations Z1 and Z2 using two different models:
M1: (x1,Z1_1), ..., (xN,Z1_N), i.e. Z1_i = M1(x_i), and
M2: (x1,Z2_1), ..., (xN,Z2_N), i.e. Z2_i = M2(x_i)
what is the correct way to gauge agreement of Z1 versus Z2 to the target y? Only working through the model will tell you. For many reasons, least squares it not always suitable.
So even if you were content to keep generating hypotheses and checking agreement, you wouldn't know how to measure agreement.
The big deal is being able to run the program backwards. I.e., you already have some set of output, obtained from some other source, and you want to figure out how that output could have been produced (i.e., how the source works). So, you write a probabilistic program that encodes your various hypotheses about how the source process works, and then run it backwards to figure out what the forward execution path would have had to have been to produce that output, and thus which hypothesis is correct. That's what "inference" refers to.
Inference is a basic process in scientific investigation- come up with a bunch of hypotheses, do an experiment that generates data through physical processes independently of whatever you hypothesized, and then go backwards to figure out which of your hypotheses would have had to have been true in order to get the experimental output that you did. Which hypothesis is true corresponds to a particular execution path through a probabilistic program, so having efficient implementations of probabilistic languages means we could do much better at accurate analysis of data, which is Good For Science.