So many thought-provoking answers. Let me add some more thoughts.
I like the idea of having a bi-directional conversation with the computer. I tell it to do X. It does it. If it doesn't give me the output I expect, I modify the instructions or add more. The "code," which is nothing more than a sequence of instructions, evolves to the functionality I desire.
I learned to program on an Apple //, using Applesoft (interpreted) Basic. I'd type in a statement on a line. It might gripe about that statement (if it was significantly flawed). I'd build a sequence of statements (a program). At any time, I could run the program and see how it behaved. The program evolved. It was a bi-directional conversation between myself and the machine. I could decide which parts of that conversation to keep in that context, which parts to throw away.
Context is important; being able to save your work establishes, and allows you to regain, said context. Because the context needed for this problem is not, necessarily, the same context you need for another problem.
Interpreters are notoriously slow. If you can get a particular piece of functionality "nailed down," it would be helpful if it could be compiled (for faster performance) and added to the environment, able to be called from interpreted statements. This is more of a polyglot approach, frequently found with Lisp systems. You can work with a REPL, building functionality, then export some of the statements from history into a file, edit it, compile it, make the compiled code part of the environment / context, go from there. I tend to think that interpreters / REPLs are a much more natural way for functionality to evolve, with compilers only getting involved once we want to optimize performance. Varying fractions of the context / "code" would get compiled. Eventually, maybe all of it. But maybe not.
All program code, today, is typed in as text then parsed into an Abstract Syntax Tree. Skip the text, create the tree directly; make creating functionality more like dragging / dropping elements of functionality from a palette into a workspace, rather than typing. Put the nodes and trees into a 3D immersive environment and "code" in VR. Just how much more complexity could you view and comprehend if it was a 3-dimensional tree of nodes and connections, hanging in space?
What is there to prevent you from creating (I hesitate to say "writing") "code" which would run across multiple processors? Nothing. Provide an input system which lets you see / manipulate collections of data and your "code" could scale. Any languages out there which do this already? Oh, let's see; there's APL / J, which has had interpreters available since the 1960s. And R, more recently. And SQL; I use the latter, pretty heavily, and it's not uncommon to see the machine chew through gigabytes of data, using a dozen or more cores. If I had more data and more cores, I could use those and do even more analysis on larger pools of data. SQL doesn't really do rigid sequences; this subquery calculates this, which gets used by that subquery which calculates that, with the results bubbling their way up to the final result. There's little in the "code" which imposes serial bottlenecks.
Even if there IS a sequence involved, what's to stop you from running this rigid sequence across millions of data elements / subsets, in a map / reduce paradigm, auto-scaling it to, potentially, unlimited numbers of discrete cores? Money, time and hardware. Google did exactly that for their search engine.
The sum of these thoughts is pretty far from the modern paradigm of typing code into a text file, feeding it to a compiler, linking it and testing, then going back to typing for the fix or the next stage in the development. Since tablets and VR really aren't good environments for typing, I expect to see some of these developments sooner, rather than later.