Syntax is everything. Syntax is nothing.


Some random thoughts about programming language syntax and development tools.

The following is a distillation of an IRC conversation I had tonight on #dylan (freenode.net) that started with a discussion of the role of syntax in programming languages. I’ve just excerpted some of my messages as a starting point. I wanted to capture some of the ideas I’ve been mulling over for probably most of my career here in my blog. At some point I’d love to find the time to expand on this and include example screen shots.

Syntax is everything.
Syntax is nothing.
Syntax is UI, and language usability is vital.
Language usability has several factors, including syntax, semantics, library availability, variety and quality, and culture, but doing something about syntax may be the easiest and at least as important and productive as improving the others.
If you’ve developed interactive GUI applications, just think of typical programming languages—which use plain text files to represent programs—as user input, model, and view.
Those really need to be separated out in any good program.
Today, we’re stuck with a very clumsy UI for most programming languages.
Instead, we should represent the program in a more computer-tractable form (eg., an abstract syntax tree) and separate out presentation and user input.
Allow for both textual and graphical presentations and editing.
Some people think of “pretty printing” and “structured” or “template editors,” but I’m talking about going way beyond those, which are still fairly primitive.

It all starts with this idea: Renaming an identifier and all its occurrences should just be a matter of changing a string in a table somewhere.
There should be no recompilation.
There should only be one change recorded in the revision control system.
It should be instantaneous.
You should immediately be warned about any conflicts with pre-existing names, and in the absence of warnings you should have confidence that the renaming was done correctly.
(Actually, you could allow name conflicts, since the computer knows which are which, but you’d want to resolve them eventually to avoid human confusion.)

If you remove a parameter from a function definition it should remove it at every call site. It could even do dependency tracking and remove any code used exclusively to generate the argument at each call site.
If you swap function parameters, it should reorder them at every call site—and warn you if it alters semantics.
If you move code it should only record one change, it should indicate whether there are any semantic changes, and it should attempt to keep the code working. eg., If you move some code that uses a local variable, it should automatically move the declaration of the local, too, if necessary to keep it before the code that uses it.
You should be able to expand a body of code and see the macros or functions it calls inline. (In fact, it should display the expanded code as it would appear during execution from that particular call site, using as much static analysis as possible to indicate what the code will do at runtime.)
You should be able to view change information and quickly move forward and back to see how a piece of code changed over time.

And, of course, the code should be formatted to maximize readability and adding code should not require typing every comma, brace, and semicolon yourself.
You should never be able to introduce a syntax error.

You should be able to, say, select part of a body of code and tell it to create a new function with that code and replace the original instance with a function call.
You should be able to view expressions formatted like math formulae, or trees, or RPN; whatever works best to make it readable.
You should be able to tell the computer to simplify an expression, or solve for a different variable, just as in a math program.
The environment should allow you to add pre/postconditions and invariants even if the language proper does not.
And it should make it easy to create test rigs for individual functions, where it automatically determines a good set of test arguments and records the results.

See what happens when you get me going on syntax?
I’ve been thinking about this since my first full-time programming job, where there were a dozen different code formatting styles. It drove me nuts.
It all started with the idea of being able to always view code the way I want to, regardless of how other people viewed it.
Part of what attracted me to the Dylan programming language was Apple Dylan’s focus on code presentation and storing everything in databases.
Just a few of these ideas made it into Functional Developer, a Dylan implementation I worked on when it was still named Harlequin Dylan. I cannot overstate how much I would like to take these ideas further.

The basic mantra is: Make it easier to write correct code faster.

All this computing power, yet programmers have some of the poorest tools, compared with shrink-wrap applications.

Posted: Tue - March 23, 2004 at 02:08 AM          

©