If not Basic then where should we GOTO?
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.
** 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 .
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 .
posted by Mike Griffiths | 2:59 AM
5 Comments:
A tidied-up variation on shellscript would seem ideal to me. If(cond)/End if is a bit wordy, if(cond){} is a bit terse, but if (cond) fi seems just about perfect, ne? As for the environment, have you ever seen PLT Scheme's DrScheme? That would be a pretty spiffy ideal to aim for.
Thanks for the input - and yes I have a copy of PLT's DrScheme and the IDE has a lot to recommend it as a model.
This is Edward Nilges, author of Build Your Own .Net Language and Compiler.
Thanks for your kind words about the book, and, I agree that it needs more about the CLR.
However, I think the Go To should stay retired. I agreed with Apress that the book should be about VB, and should compile a subset of QuickBasic, and this necessitated implementing the Go To.
However, I think that introductory programming classes should NOT teach the Go To, except where it is needed to simulate the Bohm-Jacopini control structures.
The Go To emerged from John von Neumann's bias against the very idea that programming had any intellectual content whatsoever. Von Neumann, a designer of some of the earliest stored-program computers, felt that "programming" was and should remain the low-level, invisible, clerical entry of the thoughts of mathematicians into the machine.
This is because, like most educated men of his time, Von Neumann was an unconscious Platonist who believed in the innate superiority of the Idea to brute reality, and our ability to think of ideas outside of reality.
Von Neumann therefore was opposed to any notion of programmer "creativity" or even the necessity of programmers to "think".
In a "von Neumann" stored-program architecture machine, therefore, the "ideal" flow of control, the "simplest", is also the most primitive: "go there to get your next instruction".
It simulates what the "low level" employee is told in a factory: " go there and don't ask questions".
Almost deliberately, this prevents the "mere programmer" from forming concepts above her station in life.
Whereas the purpose of the braces of C family languages (just like the isomorphic begin and end keywords of languages in the Algol family) is to allow the "mere programmer" to have an original thought, to form in fact a Platonic Idea on the shop floor, for braces, as well as begin/end, are a "closed" generative concept that form a new "statement", with all the rights of a "simple" statement, from a list of statements.
The very idea, that "this sequence of statements forms a new Idea" generates the use of functions (subroutines) by default instead of by exception as they were used in the go to era, and what this means is that the "mere" programmer, in response to the command of the mathematician or business manager, is participating in idea formation...and, this is a good thing.
Unfortunately, von Neumann as an aristocratic refugee from Communist Hungary was blind to the very idea that "mere" workers could or should do this, a micro and electronic participation in management in order to achieve management goals which demanded that they think in an unalienated fashion.
Von Neumann found however uptake in the first commercial sponsor of the computer, IBM, a corporation founded on a stratified work force, separated into "thinkers" and "doers". This in fact generated the job description of "coder" in early mainframe programming, a "low level" employee whose job it was to mindlessly use the limited functionality of the early languages (including lots and lots of Go Tos) to accurately replicate the pure and non-contradictory ideas of management.
But as it turned out in the 1960s, management's ideas weren't as pure as was predicted in the Platonic model, and typically failed to take into account all sorts of aporias (missing elements) and contradictions.
To actually want to go back to Go To is a prescription for disaster. Already, large American cybernetic systems including its military intelligence system and NASA are teetering on the brink of self-destruction because of what Edsger Dijsktra called "unmastered" complexity, in which "low level" engineers are commanded not to think but merely to code and implement to the next set of Power Point "goals".
To say that "beginning" programmers are "confused" by block structure or recursion is to accept a moronization in which people are less confused than simply alienated by mass media from the very idea that they could actually control some small part of social reality, and instead seek some sort of limited "skill", just enough to get them a toe-hold on economic security, one that grows more fragile every year.
In writing the compiler for the book, I found of course no need anywhere for "go to" unless you count early exit from a loop, and, I used an object oriented approach throughout. In so doing, I discovered that OO encourages the replacement of "loops and arrays" by recursion and that the only way to understand large systems is through recursion, not iteration.
But because of my weariness and disgust with the way in which American programmers and their managers continually seek to "simplify" their work by externalizing complexity (getting rid of Hungarian notation, and now back to Go To), even though as a result their jobs are shipped to India, I am now doing education in Hong Kong. And when I do computer science education, I do not hear from Chinese students that block structure is "too hard".
Thank you for the comment and I agree with all that you conclude. I am particularly interested in your comments on Von Neumann – I suspect that when we have sufficient perspective to write a proper history of the emergence of computer technology in the mid 20th Century the social and psychological factors influencing the pioneers will get their full due.
My post was, of course, using the GoTo statement as a metaphor.
I personally abandoned the GoTo as soon as the languages I worked with would allow. Debugging one’s own code in a line numbered Basic variant with only the GoTo to manage execution sequence was nightmare enough – debugging someone else’s was infinitely worse. Having said that; when I am called, once or twice a year, to write a new program in the (otherwise) excellent VMS Basic language I have to use one. I never did find a way of writing a program in that language that avoided the use of a single instance of the GoTo – to hop around any subroutines that would otherwise have been executed by the code dropping into them – on the way to the End statement that had to be the last.
I strongly agree that CS undergraduates and aspiring professional programmers arriving by any alternate routes should only be presented with the very best tools, techniques and, above all, knowledge that we have to impart. Otherwise there is no hope for the future. True, the best is demanding but surely it is better to “flunk” half the class than downgrade what is taught to meet the ability of those that do not possess the relevant aptitudes or mental capacity. The world has no need of any more bad professional programmers – there is already a seemingly endless supply.
Back at my post’s theme – I do think that there is an unmet demand among those who do not have great aspirations in this sphere – but aspirations none the less. We assume literacy and numeracy as foundations for “civilised man”. An interest in, and an understanding of, science is clearly standing out as an all too frequently missing element but I also think that some level of “computer literacy” should be thought of as a requirement for all. By “computer literacy” (we need a new word coining here) I do not mean a simple facility with MS Word and Excel but the ability to create new functionality – basic programming indeed.
I do not see a conflict between the needs of the many and what we need of the few.
In my original post I omitted a link to Amazon for Edward Nilges’s book plus I note that you can find some blog posts here and here.
Amazingly I came across a reference to a book titled "Structured Vax Basic: A GoTo-less Approach" written by Wilson T Price and published in 1988 I think. I just had to have a copy (at $2.79 a bargain even with international shipping) although I suspect it will be a while before it arrives.
I might just find out how to cut out that last GoTo statement in my VMS Basic programs.
Post a Comment
Links to this post:
Create a Link
<< Home