What Will Programming Look Like in 2020?

Over on Lambda the Ultimate, Sean McDirmid has asked:

What will programming look like in 2020? Keep in mind that programming in 2012 mostly resembles programming in 2004, so could we even expect any significant changes 8 years from now in the programmer experience? Consider the entire programming stack of language, environment, process, libraries, search technology, and so on.

Most of the respondents believe things will look pretty much like they do today, while a few brave souls hope that more sophisticated type systems, AI-in-the-IDE, power-sensitive computing, and other things that are no longer science fiction will have gained ground. Personally, I think they’re all looking where the light is better. I think there will be big changes over the next seven years, though they won’t actually have moved into the mainstream by 2020: if we’re lucky, they’ll be where transactional memory is today (and if we’re unlucky, they’ll be marooned on the fringe with Prolog and literate programming).

Change #1: we’ll start treating programming language design as a usability problem, and use empirical techniques from HCI to decide how the “normal” bits of languages ought to be presented. Yes, truly novel language features have to be built a few times before it makes sense to do any comparative studies, but 90% or more of any programming language is stuff that’s been built many times before, so we actually can do A/B testing to see whether one way of presenting iteration is easier for people to master and debug than another. For my money, the PLATEAU conference series will be the place to be in 2020, just as MSR and CHASE are where the cool kids in software engineering hang out today. And no, this doesn’t have to be heavyweight or labor-intensive: I did a couple of field tests back in 2000 that took less than an hour each—personally, I’d like to see every enhancement to every programming language tried out this way as part of the proposal and review process.

Change #2: we’ll (finally) separate models from views in programs. Yes, I know, I’ve been predicting this since 2004, but I really do think someone will build a proper CAD system for software in the next two or three years. If you’re new to the concept, the idea is that we should separate the storage and presentation of programs, just as we separate the storage of the plan for a building (as a set of geometric “things” connected by constraints) from its presentation (as shaded isometric drawings, parts lists, wiring diagrams, and so on). Once we free ourselves from the legacy limitations of ASCII as both storage and presentation, we’ll be able to build intentional programming systems, which will, I believe, lead to an explosion in creative problem-solving the likes of which we haven’t seen since the first REPLs and spreadsheets appeared.

Both of these ideas are currently outside the mainstream of programming language research, i.e., they aren’t currently discussed on LtU with any frequency :-). That leads to an interesting follow-on question: if we look back eight years to Ehud Lamm’s re-launch post, how many of the things discussed then have moved from discussion to implementation to adoption, and how many of the things that have done so were missing from those long-ago discussions?