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?
I think you are being unfair to LtU. “Treating language design as usability problems” appears quite frequently in the discussion, and is one important interest of several of the big mouths there, for example dmbarbour ( http://lambda-the-ultimate.org/node/4534#comment-70983 ), Sean McDirmid ( http://alarmingdevelopment.org/?p=680#comment-59689 ) and Leo Meyerovitch (and his wider search on explanations of programming language adoption trends, http://www.eecs.berkeley.edu/~lmeyerov/#socio ).
Changing the tools of the trade to something less text-centered is also a well-battered idea there, with suggestions in the range of programming for less precise devices such as touch screens ( http://lambda-the-ultimate.org/node/4257 ), programming with pen and paper ( http://awelonblue.wordpress.com/2012/10/26/ubiquitous-programming-with-pen-and-paper/ ), etc.
If those weren’t more heavily featured in the “programming in 2020″ thread, it’s probably because that could have been a bit boring to the frequent visitors there.
Excellent predictions here. OOP has slowly starting dominating, but a very slow start. Models and views will most definitely separate business logic from design, which has always been a good practice.
I’m not sure what you mean by “a very slow start” — as far as I can tell, OOP does dominate now. And the model-view separation encouraged by web apps (including various PHP frameworks) isn’t what I had in mind: when I look at Rails, Django, or [name of three-tier web framework goes here], all the pieces are still represented as ASCII, rather than SCID (source code in database).
> Change #1: we’ll start treating programming language design as a usability problem [...]
This claim that e.g. Microsoft didn’t research the usability of c#, seemed quite preposterous to me, so I did a quick search for “c# usability” and the first hit was this post about a study they did about the generics feature about 10 years ago.
http://blogs.msdn.com/b/ricksp/archive/2004/02/10/70885.aspx
> Change #2: we’ll (finally) separate models from views in programs. [...]
To build other visualizations of programs structure wouldn’t require a non-ascii storage format, so the visualizations is not being held back by ascii. In some sense we already have other visualizations in the form of syntax highlighting, intellisense and refactoring support. But it seems to have turned out that little beats ascii when it comes to compactness, expressibility, flexibility and productivity for developers. I suspect a “CAD system” would mostly be a desire of non-developers.
1) Yes, the work of Steven Clarke and others at Microsoft was one of the inspirations for this article: but as far as I can tell, none of the new features in Python 3, or the latest rev to Javascript, were tested this way. I’d welcome evidence to the contrary…
2) I think this comes down to a matter of definitions: if you regard JSON and XML as ASCII, then yes, we could use ASCII as the representation. We can also store photographs as ASCII (open parenthesis, number, comma, number, comma, number, close parenthesis for each pixel). Regarding the other arguments, “compactness” is moot, “expressibility” clearly favors model-view separation, “flexibility” probably does as well, and “productivity” is unknown.
Separating storage from representation of programs has been tried many times over the last thirty years, e.g. Gandalf, Smalltalk, Charles Simonyi. It turns out that representing programs as text files has huge advantages. It’s simple, robust and works well with existing tools such as VCSs. Maybe it’s time for another try, but you’d better bring something new to the table.
My prediction: in 8 years we’ll be using record and replay debugging all the time and wondering why we ever didn’t.
You’re right, it’s been tried many times, and the tight reinforcing circle of “programs are text so we all invest in text-based editors and other tools which encourage us to store programs as text” is a hard one to break. As I said eight years ago, I think that means that when change does come, it’ll come from one of the sole-source proprietary tool vendors (MathWorks, Wolfram, Microsoft) who can do the whole toolchain at once.
But yeah, record and replay debuggers are probably going to be one of those “why didn’t we?” things
I believe it’s getting harder, not easier, to break that reinforcing circle — thanks to open-source projects, and more recently Github. Yes, it might work for people who don’t share code or do so only through some kind of captive portal.
We do have one programming model that’s not text-based — spreadsheets. I’m not sure if you want to build your intentional future based on them, though
.
I think for your #2, there will be a parallel development in somewhat the other direction, and that is programs that run in the datastore. Specifically some of the work that is being done with Postgres where it would be possible to run an entire website just from within the Postgres process using embedded interpreters instead of a separate process that talks to the database. Another recent project I’ve seen along similar lines uses a search engine not as an index of db content, but as the sole db for meta data, and s3 as the bulk media datastore. This alone doesn’t mean a complete paradigm shift in the way code is written – but will result in some changes to the way systems are architected.
I think we will also see more non-programmer oriented logic and analysis tools, tools that allow a constrained set of operations on data and result in visualizations – swiss army knives for data, instead of an unlimited toolbox of full programming languages.
And of course, the big changes are the ones nobody saw coming
Interesting comments as usual Greg.
On the separating presentation from representation – suprised as a HPC guy you haven’t commented on things like Profiling tools, and things like Doxygen ??
Ever since I started in scientific computing and parallel programming and often had to deal with large, often idiosyncratic (though to some extent time-tested and working) legacy code-bases in C or C++ in the early 2000s, I’ve always thought those kinds of tools were essential. Though they are admittedly after-the-fact viewing tools, rather than interactive editors.
Didn’t companies like Rational Rose try to re-train us from typing code to drawing pretty UML boxes so the code could later be auto-generated back in the early 2000s? (I know you’re no fan of UML of course
)
And wasn’t the success of Python and Ruby partly a response to this, an argument that good and productive programming was as much about fine-grained craft(carpentry) of well-written texty modules, not just big engineering and systems design?
I think my view is influenced by working on numerical simulation programs with mathematicians – who still see text and symbolic manipulation as perhaps still the highest ‘form’ of their discipline, even if they’ve taken mightily to IDEs like MATLAB, and Sage, and visualisation aids? I think working with them a lot influenced me to see the value of the “Code is the Design” school of thought, even if with my training as an engineer I continued to also draw lots of diagrams with arrows and boxes when thinking about how to improve the damn things and introduce design pattern thinking etc where it seemed appropriate.
Re literate programming, I’d like to see this still continuing to improve, and really thought things like Sphinx and Crunchy (http://showmedo.com/videotutorials/video?name=1430000&fromSeriesID=143) were a material step in a useful direction here in the last few years.