Let me start with a bit of a history lesson. For over a decade now, we've known a particularly annoying quirk of Moore's law. That's the "law" that says that the number of transistors on a chip doubles roughly every one and a half years. A lot of people, however, interpreted Moore's law as meaning that the speed of processors would double at that rate. For a while, that was indeed the case.
Then, somewhere around 2005 or so, we hit a roadblock. The standard bag of tricks for converting more transistors to more speed (e.g., deeper pipelines, redundancy for overclocking) started to run dry. Mind you, we were still getting more and more transistors on the die, but we couldn't use those to make things faster.
Intel et al. had more transistors. Since they couldn't make them do things faster, they made the transistors do more. Enter multicore.
This scared a lot of people. After all, a lot of people had been banking on the false interpretation of Moore's law. After all, if it runs slow now, it'll run just fine in 2-4 years. With CPU designers shifting their emphasis to multicore, getting that kind of speedup meant reorganizing your code to run in parallel. The natural speedups of yesteryear were no longer "free", and the research community shifted to ways of exploiting natural parallelism in user code.
And that brings us to the present, as well as my thought of the week. Text editors are fundamentally bad for programming.
I know that sounds a bit radical, but hear me out. The fundamental data representation of a text editor is serial: A string of instructions. For a serial program, this is perfect. The order is there, and the computer knows exactly how to execute these instructions serially. A text editor encourages people to think serially about their code. For parallel programs, however, this is a horrible idea.
What we as the research and software development communities need to explore are non-linear approaches to representing code. Graph-based data-flow diagrams are a start. For example, one (admittedly crude from a full development standpoint) nonlinear programming environment is Yahoo Pipes.
Nonlinear features can be increasingly found in IDEs and programming models as well: Eclipse's "Go to {Definition, Call Sites, …}" features (now present in nearly every other major IDE) are canonical examples of this, making it easier to mentally trace nonlinear code execution paths. Models like Map Reduce compartmentalize parallel computations (each Mapper/Reducer is a separate class), forcing a developer to consider them as individual components of a bigger program.
Now, that level of serial thinking is still necessary. CPUs still operate one instruction at a time, but can we do better? Can we create a programming environment that actively encourages users to compartmentalize their computations?
Consider the following simple program
A = input.right;
foreach(i in input.left){ B += i.left; C += (i.right > 0?i.right:i.left) }
B += input.right;
And compare to the following structure:
The parallelism is inherently visible, and easy to follow -- even if the rest of the graph may not be.
How can we replace the text editor? How can we come up with better ways to represent data flow in a computation. Can we take cues from programming environments like Alice or Apple's Automator? Can we create a non-linear text editor… something that inherently displays the branching structure of a program?