May I start with a quotation?
The act of focusing our mightiest intellectual resources on the elusive goal of goto-less programs has helped us get our minds off all those really tough and possibly un-resolvable problems and issues with which today's professional programmer would otherwise have to grapple.
John Brown (I am assuming John Seely Brown but please correct me if I’m wrong)
Many will be to young to remember the first flush of “structured programming” and the demonisation of the “GoTo” statement. I suppose it was true that in the absence of the “GoSub” (that early and soon forgotten “silver bullet” of programming) many programmers managed to produce a great quantity of un-maintainable spaghetti code that was clearly un-maintainable. All that happens now is that the mess written by poor programmers is hidden inside classes (OOP being a more recent silver/spent bullet) where we cant see it. Yet there was nothing fundamentally wrong with the unequivocal GoTo. It lives on in the Assembly code underlying most programming languages – without the Jump statement no branching of the code would be possible. And what after all is the “break” statement popular in so many languages (or say the VB Exit For) but a GoTo in disguise **.
Mark Guzdial of Amazon recently wrote a blog entry titled “Plea to Language Designers: Bring Back GoTo!” in which he made the persuasive case that there was an enduring need for programming languages accessible to a much wider audience than just the professional developer. Indeed he suggested that new languages might try and “span” the requirement providing a simple procedural syntax at one level while also supporting the complex needs of the professional with additional structures and syntax more suited to building large software applications. Mark identified the GoTo as a statement epitomising the simple procedural languages that were available everywhere at one time.
So where are the programming languages for non programmers?
I suppose that spreadsheets (and in particular the near ubiquitous MS Excel) provide an end user programmable facility meeting some of the need. Most people with reasonable numeracy skills can manage multi-stage calculations using a spreadsheet. However few try to manipulate text using such tools – indeed the complexity of text processing seems to be amplified by the spreadsheet paradigm. Even fewer venture into scripting languages like VBA – I suspect because they are hidden away “behind” the spreadsheet rather than brought to the foreground and into the focus of the average user. Spreadsheets have their limitations both in their functionality and in their user interface (VBA or no VBA) and I think what we are looking for should not come as a side effect of an application but should be a tool in it’s own right.
I think there is a genuine need for a general purpose programming language specifically designed to be accessible to all. A language that can run across multiple platforms and become the “natural” choice for authors writing books on general aspects of computing, magazine articles aimed at the hobbyist and further education tutors offering courses to adults. The “slot” that Basic filled so well for so many years.
I have been re-reading Edward Nilges’ “Build your own .NET Language and Compiler”. This is a thorough (yet non academic) introduction to language design and compiler writing, written in an entertaining style – a good read. The general theme of the book is the design and implementation of a “Quick Basic” clone to run against the .NET Common Language Runtime (CLR). However the book is not dominated by the Basic language and deals well with domain specific languages and many of the fundamental issues facing a language designer. The only disappointment of the book is that while it deals with the “front end” of the task of compiler writing in great detail it falls very short when it arrives at the “nitty gritty” of CLR code generation itself. One can surmise that this part of the book was deemed by the author or publishers too “dry” for the intended readership. However the supporting web site offers downloads of all of the code described in the book – together with the “finished” product. Reading the book can re-kindle the sense of excitement generated by the first brush each of us had with a computer programming language.
I mention this book here because one’s first thought for a new Basic would be – why not Basic? What were the strengths of Basic and what weaknesses might we avoid in a replacement? [I am using the past tense here to differentiate between the modern OO forms of Basic such as VB.NET and the original interpreted versions implemented on so many computer platforms over the years.]. Interestingly, some of the weaknesses of early Basics have the potential to become strengths. Early Basics were interpreted, line by line which was slow and precluded statements and data constructions that bridged multiple lines. With faster processors and modern JIT compilation techniques interpreted languages are now all the rage. Early Basics had a cavalier attitude to variable declarations (although they were almost all strongly typed) and that is a feature of some modern scripting languages. Basics have often been generous in allowing automatic “casting” between types and that does feel like a strength.
The early Basics had line numbers as logical labels and interpretation/execution proceeded in the order of the line numbers – allowing for the odd GoTo of course. This worked, but was clumsy – later Basics introduced labelled subroutines and then proper Functions (including void functions or subroutines with passed parameters and line numbers began to disappear. Originally variable scope was global with terse memory saving variable names and limited data types. Later Basics allowed some limitation of variable scope, user defined data types and long variable names to match the descriptive language keywords. Later Basic code could be written in a descriptive and often self documenting manner.
What are the “ideal” characteristics for a new basic language? (note the lower case b)
We could probably argue all day but we would need to keep things simple and accessible.
- On balance I would plump for an interpreted case insensitive procedural language with descriptive keywords (that’s the Basic bit).
- I’m ambivalent on the question of C style “braces” around statements verses the end of line character combined with block ending keywords like “End If” or “End Case”.
- I think I would envisage targeting a subset of the .NET Framework CLR (or DLR) but the Java byte code runtime would be a valid alternative.
- Again I am ambivalent about strong verses weak typing – weak typing gets “newbies” writing code faster but can demand a better understanding of data types when things go wrong that that required by a language with clear typing from the very start.
- There are interesting issues arising around the natural UI of such a language – should it be the ubiquitous “desktop style” window with a full set of “widgets” or a graphical plane that also acts in a similar way to a “console” or terminal window?
** Bizarrely the GoTo lives on (just) in VB.NET whereas the oh-so-useful GoSub did not make it in the jump from VB6 – as the Return statement was claimed by the language designers for Functions I suppose .