The Future of Coding Environments
How would Scotty or Geordie go about writing code for the Enterprise? Would they write code at all? Would they just interact with the Computer via speech or holodeck, or would a keyboard of some sort still have a place?
In any case, my interests have always stretched beyond matters of organisational effectiveness, beyond matters of human and humane relationships, and beyond matters of how the work of software and product development might better work.
One of my other abiding interests has been the nature of programming. Indeed I spent more than two years, decades ago, on conceiving, designing and implementing a proof of concept for the kind of development environment I’d like to use myself, when writing code. At the time, the work was codenamed “Simplicity”.
My core feature set / wish list includes:
- Editing source code directly in the AST, rather than editing source code in text files
- Direct and incremental compilation of source code as it’s being entered
- Multiple coders editing in the same AST concurrently
- Live editing of the AST “in production” (with appropriate safeguards built-in)
- One homogenous AST for each entire (live production) system
- Source code control / version control features built right in (and automated away from distracting the coders)
OK, so this may not be the kind of development environment Scotty or Geordie would recognise. But it’s a world away from all the crap we have to put up with today.
So why don’t we see more movement towards the emergence of some of these features in our development environments today? In a word: conservatism. Developers en masse seem disinclined – or unable – to look anew at their tools, and dream.
“The future is a foreign country; they do things differently there.”
The Mjølner Environment ~ Görel Hedin, Boris Magnusson