Over a cup of tea in bed I was pondering the future of business data processing and also general programming. Many problems of power-computing like web programming or complex algorithmics, and also end-user programming seem to stem from assumptions embedded in the heart of what we consider a programming language, many of which effectively date from the days of punch cards.
Often the most innovative programming/scripting environments, Smalltalk, Hypercard, Mathematica, humble spreadsheets, even (for those with very long memories) Filetab, have broken these assumptions, as have whole classes of ‘non-standard’ declarative languages. More recently Yahoo! Pipes and Scratch have re-introduced more graphical and lego-block style programming to end-users (albeit in the case of Pipes slightly techie ones).
What would programming be like if it were more incremental, more focused on live data, less focused on the language and more on the development environment?
Two things have particularly brought this to mind.
First was the bootcamp team I organised at the Winter School on Interactive Technologies in Bangalore. At the bootcamp we were considering “content development through the keyhole”, inspired by a working group at the Mobile Design Dialog conference last April in Cambridge. The core issue was how one could enable near-end-use development in emerging markets where the dominant, or only, available computation is the mobile phone. The bootcamp designs focused on more media content development, but one the things we briefly discussed was full code development on a mobile screen (not so impossible, after all home computers used to be 40×25 chars!), and where literate programming might offer some solutions, not for its original aim of producing code readable by others, but instead to allow very succinct code that is readable by the author.
if ( << input invalid >> )
<< error handling code >>
else
<< update data >>
(example of simple literate programming)
The second is that I was doing a series of spreadsheets to produce some Fitts’ Law related modelling. I could have written the code in Java and run it to produce outputs, but the spreadsheets were more immediate, allowed me to get the answers I needed when I needed them, and didn’t separate the code from the outputs (there were few inputs just a number of variable parameters). However, complex spreadsheets get unmanageable quickly, notably because the only way to abstract is to drop into the level of complex spreadsheet formulae (not the most readable code!) or VB scripting. But when I have made spreadsheets that embody calculations, why can’t I ‘abstract’ them rather than writing fresh code?
I have entitled this blog ‘part 1’ as there is more to discuss than I can manage in one entry! However, I will return, and focus on each of the above in turn, but in particular questioning some of those assumptions embodied in current programming languages:
(a) code comes before data
(b) you need all the code in place before you can run it
(c) abstraction is about black boxes
(d) the programming language and environment are separate
In my PPIG keynote last September I noted how programming as an activity has changed, become more dynamic, more incremental, but probably also less disciplined. Through discussions with friends, I am also aware of some of the architectural and efficiency problems of web programming due to the opacity of code, and long standing worries about the dominance of limited models of objects
So what would programming be like if it supported these practices, but in ways that used the power of the computer itself to help address some of the problems that arise when these practices address issues of substantial complexity?
And can we allow end-users to more easily move seamlessly from filling in a spreadsheet, to more complex scripting?