Got an idea for a new programming language? Thinking about implementing one on a new platform? It may be easier than you think. Early in my teaching career, I got interested in the problems that confront – and sometimes discourage – novice programmers. One of the problems that beginners had (and probably continue to have) is that they focus more on syntax than on semantics. That is, they get so hung up on how to express something in, say, C or Java (syntax) that they neglect to ensure that what they are trying to express actually makes sense (semantics).
As it happened, I was teaching a course in program design that didn’t focus on any programming language at all, just logic. Research published by David Scanlan of California State University, Sacramento confirmed my classroom experience that, properly used, old-fashioned flowcharts did a good job of conveying program logic to students. Since I required flowcharts for most of their assignments, wouldn’t it be great if I could evaluate the students’ designs by simply running them? With these two streams of thought converging, I set out to develop a visual programming language with simple, yet robust syntax.
In 1989-1991, I designed a language named “FLOGO” (not to be confused with the robotics programming language for children developed at MIT a few years later). FLOGO consisted entirely of 6 symbols (derived from standard flowcharts) and 11 keywords together with variable identifiers and basic mathematical and logical expressions. With the design in hand, the next step was to build an IDE (in object-oriented Turbo Pascal). The IDE enabled the construction of programs by dropping symbols (such as input, output, or branch) onto a spreadsheet-like grid, adding imperative text to the symbols (restricted by the type of operation the symbol represented), and connecting the symbols to specify execution sequence. The programmer developed what was essentially a directed graph representing the program’s logic.
Dr. Jack Crenshaw to the rescue!
So far, so good, but to be useful, the graphs had to be exectutable. Never having taken a compilers course – but owning several books on the topic – I was a bit apprehensive. Then I came across a series of articles (originally posted, I think, on CompuServe) that presented a very straightforward way of parsing input and emitting machine code. With very little effort I was able to turn the principles into an interpreter that ran inside the FLOGO IDE.
So if there’s a compiler in your future and you think LEX refers to Superman’s nemesis and and you’re pretty sure a YACC is a big, hairy animal, have a look at “Let’s Build a Compiler!” by Dr. Crenshaw. His examples are written in Pascal but other than “begin” and “end”, where C and Java programmers would expect “{“ and “}”, the code should be easy for users of those and similar languages to follow.
In case you’re wondering, FLOGO has been lost in the mists of time. I published (including the FLOGO language design) but perished anyway and didn’t have time to pursue it after leaving academia. The language specifications and code got lost in their travels from hard drives to 5-1/4″ floppies to other hard drives to 3-1/2″ floppies across multiple computers. A couple of paper copies of conference proceedings are all that remain.
