Subj : Re: Compiler and an interpreter
To   : comp.programming
From : Rob Thorpe
Date : Fri Aug 05 2005 10:24 am

CBFalconer wrote:
> Vesa Karvonen wrote:
> >
> ... snip ...
> >
> > Psychological studies have indicated that short-term memory has a
> > capacity of 5-9 "items" (http://www.well.com/user/smalin/miller.html).
> > Code in first-order languages typically has lots of little details,
> > particularly details related to control flow and resource management,
> > that can not easily be abstracted away in those languages. My own
> > experience and intuition says that those details quickly eat all the
> > available short-term memory and ruin productivity.
>
> It's not the language, but the coding breakdown.  By doing a
> suitable top-down design you remain at the higher level well into
> the design, and the lower levels are exactly what the design needs.
>
> At least that is the effect.  Top-down design and short
> functions/procedures will make the whole process semi-automatic.

This type of design certainly makes things much easy, but I not
perfect.
It would go a long way if programmers and their bosses were perfect.

* The first problem is the changes:
For example a C program I maintain has a set of arrays of floats that
represent data the program can gather, they are fixed size and
statically allocated.  Each of the data types are independent, the user
can view and store any of them.  The arrays sit together in a struct.
Each array is quite large.

Over time I've added more possible types of data that can be gathered.
So, I've added more arrays in keeping with the original design.  The
problem I have now is that the program uses a lot of memory even when
the user isn't doing anything hard.

The simple solution would be to allocate variable sized arrays.  But
there are no variable sized arrays in C90.  Had the program being
written in a higher level language the problem would have been much
simpler.

* You have to write a lot of the low level yourself

In any program in a medium level language like C you have to write the
low-level stuff eventually.  At the high-level of a top-down program
the manipulations can be very simple.  For example you call a function
to setup a device of some kind, it does everything you need, you close
it with another function.  Memory allocation may be involved lower
down, but you never see it at the high level.

But at some point you have to write the lower levels.  Doing this is
more involved than it would be in a higher level language.  Eventually
after hundreds of thousands of lines of code, working inside a large
top-down program becomes like having a more powerful language at hand
because it implements so many low-level functions.  But these functions
don't often have the robustness of a language library or runtime.

.