Monday, November 12, 2012

The IDE

Time to look at the tools to use with my language.

Background

There have been many attempts to create a graphical programming language or, at least, a graphical IDE. I think these are doomed to failure. Here's why.

When I started programming, flowcharts were The Tool to use. Being graphical by nature, they should have been easy to use. But they weren't.

Flowcharts took a long time to create. Drawing boxes and arrows took time and if you made a mistake, corrections were painful. To make a correction, you had to erase the problem area and squeeze the new diagram into the space. Then came pseudo-code.

Pseudo-code was much easier to use. For one thing, you didn't have to draw an arrow to the next step; just place it on the next line. In fact, there were no arrows at all.

Mistake were easy to take care of. Just draw a line through them and rewrite the line. If the correction was too big for the paper, start over on a new one. (When using flowcharts, programmers were reluctant to start over because of the time already put into the flowchart.)

Writing via pseudo-code was much easier than drawing via flowcharts. And because of this, writing code has dominated programming.

But now, I think it's time for a change.

Point-and-Click IDE

Currently, text editors and IDEs have syntax highlighting. But they do not highlight the syntax, just the tokens. It's time to add more.

By incorporating the grammar of the language into the IDE, syntax errors are immediately detected. No more edit-compile-correct-errors cycles. Problems are shown as the happen and corrections can be made immediately.

And if the IDE knows the syntax, it can store the AST rather than the text. This allows many benefits:

Point-and-Click

Since the syntax is known, code can be created by point-and-click. The programmer points to the syntax he wants to add and the IDE places it at the cursor. The only things the programmer have to type are the identifiers: variables names, files, etc.

Style Becomes Preferences

The style of programming can be stored a preferences since none are stored in the AST. Things like the indentation of if's and loops can be whatever the programmer wants: 2 spaces, 4 spaces, 1cm, ½ inch. If a different programmer opens the file, his preferences are used. No more arguments over coding style; each programmer can have their own.

Reserved Word Can Be in Any Language

Since the token is stored in the AST, not the text, keywords can be programmer preferences. They can change a keyword, like subroutine to function and it makes no difference. Other programmers when they look at the code, still see subroutine. Or not, if they changed their own.

And if the words can be changed, then they language can be too. A program written in English can be read in Arabic or Japanese. It only depends on the programmer's preference.

Finally if the IDE stores the ABT, semantic errors are detected immediately. The semantics of a program are what links the variables to the statements via the symbol table. This means a programmer cannot use a variable that's out of scope or the wrong type. Only valid choices are given, so errors are reduced.

Logical errors are still left for the programmers to make. ☺