Even as we all scramble to use the programming tools we have today, developers look ahead hopefully, dreaming of better tools. What shape should those tools take? Who should they be for?
A few months ago, I had the privilege of talking about programming’s future with three great and very different programmers:
- Chris Granger of Light Table, who combines expansive visions of programming capabilities with an interest in making it approachable.
- Greg Borenstein, author of Making Things See, who explores the intersections of software and hardware.
- Scott Murray, author of Interactive Data Visualization for the Web, Assistant Professor of Design at USF, and a contributor to Processing.
I’d encourage you to listen to the whole conversation, but to get started, you might explore these highlights.
Chris Granger opened with a problem: “We don’t have a framework for understanding what’s wrong with programming.” [2:48] He suggested “three buckets” [3:18]: incidental complexity [3:23], observability [3:47], and the nature of programming as an indirect exercise in translation [4:49].
Greg Borenstein came to those problems from a teaching perspective: the challenges of installation and getting started [6:01], and the classic motivation question: “Can you do something with it that you want to do?” [6:35]. Fitting programming to domains is difficult [8:10].
Scott Murray returned [10:40] to the problem of invisibility in programming. Declaring himself someone who codes more than programs, he talked about his relationship with students used to doing primarily visual work. Recreating a computer system in their heads is tricky, but it helps to get some early kind of visual response before you get your final output [12:50].
Borenstein talked about the challenges of multiple audiences for different programming approaches [14:43], and Murray talked about how “wanting to understand programming comes later, once you’ve made… whatever it is you were working toward, that initial impetus.” [16:11]
Granger questioned the way programmers describe some of their challenges: “it can either be easy, or it can be powerful. I believe that’s a false dichotomy.” [17:55] He wondered what the future might look like in “10, 20 years… not a new version of C++ with its complexity. What you’re going to see that looks something stupidly simple…. will make programmers… focus more on the domains to solve problems.”
Much of the rest of the conversation was about reducing the gap between programming and the problem domains programming attempts to address. Murray talked about the “it depends…” problem of the “which language should I choose?” question [25:00], and Borenstein needed to “push back… against programming languages that look like domain… bad history” [27:08]. Murray suggested that “different modules for different domains” might help [29:40], and Borenstein noted how hardware creates extra stresses: “You can do a lot in hardware without actually knowing anything about hardware… but then you face this cliff wall.” [32:20]
Granger wondered “If we can build a foundation for these very direct, very observable domain editors” and “turn programming into a medium for thought, not just a way to tell the computer what to do, but as a way of expressing ourselves.” [37:00]
Borenstein marveled at the “undigested wonders strewn about the place…” and hoped that new capabilities should ” become like this new color of paint people can use… controlled by people making culture.” [38:40]
Will programming follow these tracks? I’d like to think so.