BASIC is 50 years old. That's a long run for what began as a way of teaching users to code, and ended up as one of the most popular development platforms around.
I grew up with BASIC, a language that made it easy for me to try out ideas and explore what computers could do. It allowed me to try out new code quickly, and to see the results then and there in glorious 8-bit color. It's shaped the computing world, encouraging users to become developers.
But times have changed, and the tools and technologies we're using to build apps have changed, and are going to continue changing.
The long slow switch to a world of services has proven to be the point where BASIC has started a long slow slide into niche programming. Microsoft has done a lot to make Visual Basic a tool for building service endpoints, but it's playing second fiddle to C#. Even so, it has its place, as part of tools like Microsoft's power user development tooling Visual Studio LightSwitch.
Fifty years is a long time, and BASIC has done well to last this long, especially when you think of other popular languages that have faded away or been transformed into something different. Now it seems to be BASIC's time to go, its strict procedural nature unsuited for tomorrow's world.
So what's next, and how do we teach it?
If BASIC and its descendants aren't part of the future, what's tomorrow's programming world going to look like? Recent experimental tools from Microsoft and Google point to an increasingly bifurcated approach to development. Cloud services will have deep programming capabilities, either through hosted virtual servers or through platform as a service features. On the client side, visual programming tools will allow users to build and create endpoints for a wide range of devices, with only minimal coding required to glue elements together.
We see glimpses of that future in tools like Microsoft's Project Siena and its Windows Phone Studio, in the rise of its functional programming languages like F#, in Google's Dart language, and in Facebook's reworking of PHP as Hack. They're all designed to work asynchronously, either to deliver or consume services, running on mobile devices or across cloud compute fabrics.
If everything is changing, then how do we teach people to program? Event-driven functional programming isn't intuitive, as it's hard to visualize how asynchronous components come together to make a working application. The Lego model we've used for object-oriented component development doesn't work here, though it comes closer than most metaphors
I often end up visualizing event-driven programming as one of those Rube Goldberg machines, with each functional block a different element, all coming together to give a result, but this metaphor won't work for many other people. So it's good that other developers and designers have been thinking about this, and have come up with innovative ways to start getting developers to think about how they're going to need to work. They're starting at the right place, in elementary schools.
It turns out that our schools already are using the tools and technologies we're going to need to teach new ways of programming. Microsoft's Kodu educational gaming environment and its more complex and hobbyist-oriented sibling, the game-building tool Project Spark, are both event-driven, asynchronous development environments. Elements in the visual game worlds are given reactive "brains" that can be programmed to respond in set ways to set stimuli. There are no limits to what can be programmed, and everything you see on the screen in Kodu or Spark is able to interact with any other component. Programming is via a visual programming environment that lets you construct programs using icons and numbers.
The game-building concepts at the heart of tools like Kodu translate well to tomorrow's IT world. They let us learn to think of program elements as isolated, asynchronous functions that respond to events; either completing an action, or delivering an event to another element. Actions can process event information, or change UI state.
It's an extreme version of the service-oriented model we're using for much modern application development. However it lets us break down our code into key functions, a simpler way of looking at things and of understanding the asynchronous connections between components. It's also a technique that works well with the Internet of Things, where those software functions are often single purpose sensors and actuators; themselves event sources and sinks.
There's still a place for BASIC-like language elements. They let us understand the structure of a program that took in an input, processed that data, and delivered an output; and the heart of any functional element will be some form of procedural code, just like that BASIC program. They've stopped being the be-all and end-all of our programs, instead becoming simple code elements that combine to build the complex structures our users demand.
BASIC taught us what we needed to know to get here. It'll be tools like Kodu and Project Spark that pick up its baton. They're not just tools for kids and gamers, they're what we need to be learning to get ready for a world of distributed systems and cloud services. Give them a chance, and they'll take us to where we need to be tomorrow, giving us the foundations for another 50 years of computing.