What should programming look like?

Can it really be simplified?

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:

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.”

After some discusion of “uber-simplified” possibilities [19:10], Borenstein suggested that “more diversity is both good and very likely to be the future.” [21:32]

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]

Murray liked that vision, but noted the need for “teaching how to learn… the tools change so quickly” [41:55] and that it was critical to “lower the bar for that initial success point” [44:45].

Will programming follow these tracks? I’d like to think so.

tags: ,