[Coco] The art of programming?

[Stephen H. Fischer]

Hi,

I do not know when it happened, it was so long ago but all the programming
tasks I do now are first thought of in what is called "pseudo language".

That is, I look for what is to be done and work on approaches that may work
and then iterate and refine the ideas on how to approach the problem.

Most often I am only concerned about sub parts of the problem and when a
workable idea has appeared the next sub part is examined.

When several parts have been examined I think about how the parts can be
combined to do a larger task or function and the entire project.

During this period there is NO programming language involved. NONE! I am
doing a "thought exercise" only.

Only when the design has reached a point that it may well work is a trial
implementation in some language thought about. Still at that point that no
code will be written except for exploring uncertain ideas and attempts to
improve the design. The code may never actually be run, I am just trying to
confirm that something can be done in *some* language.

I draw on ideas that I have used in the past and how others have done
similar tasks.

I look at running examples and try and extract the basic algorithm that is
being used for sub tasks.

If you can look at some code in any language and understand what it is doing
and how it does it you are starting to build up your personal knowledge
base.

When all the parts appear to have workable algorithms then you can choose a
programming language and start writing code.

-------------------------------------

While the process was totally informal when I was designing "Urbane", some
of the basic parts were:

 Reading lines of text from a file.
 Separating those lines into tokens.
 Checking each token to see if it is a "Keyword"
and if not, checking if it is a "Line Number",
and if not, checking if it is a known "Variable",
and if not then it must be a "New Variable".

During the first reading of the file, just the first tokens which must start
in column one are collected as "Line Labels". This is a common practice when
there are forward references which must be determined first.

The second pass starts each output line off with a line number, adds
keywords unchanged to the output line, inserting actual line numbers for
line labels and replacing variables with their assigned 2 character variable
names.

The parser is very different from the one that I initially planned to use. I
realized that a much simpler one would do the job so I did not write a more
traditional syntax driven one like DECB uses. This is at the cost of much
less error checking and poor reporting. As the number of users may be small
this is a good trade off and is based on the requirement that only
syntactically correct DECB statements are allowed.

Central to the processing is the concept of asking the question:

Given the last character, what are the legal possibilities for the next
character and then checking for each possibility. In parsing the input line,
a unexpected character is just copied to the output and any series of blanks
are reduced to just one blank. I was very happy as so much code was
eliminated by just moving the unexpected character unchanged to the output
stream.

One section of the code was giving me problems. I just could not see how to
make it work. I realized that it was a function that could be given a
meaningful name and after creating the function and defining the input and
output parameters the code would work. The key was adding an additional
parameter to be returned with a useful name. Now with a defined interface
the special cases could be separated out and it was clear how to use the
function and what to so with each special case upon return.

There are several functions that remain as in line code, should I do further
work they will be defined as naming then makes the program operation easier
to understand.

Now, Urbane does not follow exactly the above words. DECB programs for the
most part are intertwined jumping to places to handle special cases.

With a different language with better constructs, the program flow would be
easier to understand. Trying to use these constructs in a language that does
not have the underling support may produce even less understood programs.

Reading the code is somewhat like reading the English like "pseudo language"
I design in. I found the "Urbane Basic" language to be just great and I am
very happy I am doing the project.

I hope these thoughts help. Just don't get bogged down writing code when you
do not understand what the pieces of the project are and how the program
will operate.

Stephen H. Fischer

Jim Cox wrote:
> As I dive into C programming, one of the major issues I
> have to overcome is learning create a program in the most
> direct and simplest way possible.  I shouldn't say it's an
> issue as it is more of a skill I need to develop.
>
> I understand this takes time and practice, but I'd like to
> know if anyone out there has any recommendation for a good
> book on just software design?
>
> I'm starting to read Code Complete, but if possible I'd
> like to get more than one point of view.  Thanks.
>
> -Jim