Yes it does. We (at the Netherlands eScience Center) will be building such an interface next January, extending Entangled (https://entangled.github.io). This approach uses Markdown and enables editing your code both in Markdown and generated source codes, synchronizing when files are written to. Currently with traditional documentation site generators like MkDocs, you can get nicely presented content, but what you suggest requires a bit more work. We will build better content navigation in Pandoc, and a side-by-side view as you suggest is definitely on the table. Also: outside contributions are more than welcome ;)
There are notable exceptions. In scientific programming, code is tightly linked to scientific context and explaining stuff in prose is vital for being able to understand. Often, people claiming their code just reads itself just haven't worked on hard enough problems. Other than that, people seem to mistake the reason for having documentation: we aren't necessarily (just) explaining how something works, rather why you made a certain choice, why the alternative doesn't work etc.
Yes, writing a good literate program is more work, and it may not be for everything, but there are many cases where this approach can help communicating your work and save time in the process.
That being said, I'm not a huge fan of Org-mode, since it forces Emacs onto your collaborators. A much nicer method based on Markdown is Entangled: https://entangled.github.io/, though disclaimer: I'm the author of Entangled ;)
In cosmology we use a similar procedure to generate initial conditions of sample universes. Just then the noise is in 3D. The article raises a question about the Gaussian nature of the generated noise. To generate non-gaussian noise, you need a way to correlate the phases, otherwise the central-limit theorem will always kick in.
There is so much hate here for the GIL, which is undeserved. You tend to not notice all the nice safety it gives you. If you want to speed up your Python code you could of course try to make it run in parallel: congratulations, you just wasted N times more CPU on slow interpreted code. You could have used an accellerator language like Numba, or write parts of your code in C++ or Rust and get a 10-100 times speedup on a single core!
The solution here is that you can edit code, with all your IDE features enabled, in tangled form. Changes are automatically merged into the Markdown by the Entangled daemon.
Hear, hear! I think this problem is also beautifully put by the Knuth in Surreal Numbers. Results are boiled down to the smallest possible representation, without giving a historical/pedagogical overview, or even the slightest hint about how the author himself also struggled with the material.
This also boils down to what you understand the word "elementary" to mean. It is definitely not synonymous to "simple", rather as Feynman put it, "only requiring an infinite intelligence to understand".
It's a nice figure displaying the presence of elements in the Earth core, human body and cell phones, but why does it give no hydrogen in cell phones?
Also the picture of "native gold" is really pyrite, also known as fool's gold.
My confidence levels for this article are low.