Prototyping languages

It’s worth talking a bit about prototyping and program structure and languages and such. I like to think of a program as a five layer cake.

• The user interface layer
• The glue layer connecting the user interface and the application
• The application architecture layer
• The application-specific services layer
• The generic services layer

The glue layer wants to be in a language that can talk to other languages without getting in the way. [Using C for a glue language is like building a house will all nails and no boards.] It basically is transferring symbolic information from one layer to another.

The application architecture layer, in my view, is concerned with who does what to whom with what and when. Sort of like middle management. This varies a good deal with the application, of course. But the point is that the architecture doesn’t have to do a lot of the hard work — it delegates it to dedicated services. What it does have to do is adequately correspond to the application domain. Again, a natural for a prototyping language [see below].

The application-specific services layer might either be a prototyping language or a classic 3GL. It all depends on cases. My view is that the more you can break this layer up into self contained chunks, the better off you are. Resources in this layer should be shareable across similar applications.

Finally the generic services are things like the OS services, malloc and friends. These beasties are the natural home of the performance driven 3GL.

On this view, prototyping languages are good for 3 1/2 of the five layers. In fact, since the generic services should be already there, only one eighth of an application should be in a classic 3GL.

Incidentally, I am sort of using “prototyping language” fast and loose here. Basically I am talking about any type of language which is oriented towards power of expression, compactness of actual code, and swiftness of development, with ultimate efficiency taking a relative back seat.

There is an argument that runs like this: 80% of the code takes 1% of the CPU time; 10% takes 10% of the time; and the last 10% takes the rest. If you can replace that 80% by 10% at the price of that part of the code running five times slower, your cost in performance is negligible and you’ve cut out 70% of the code.

How do you get those kinds of savings in code? Some biggies — predefined powerful types. Get rid of all those type definitions and the associated fiddling; and use canned types. Simplify away complicated syntax [except for Perl — more is better :-)]. Get rid of the storage allocation blues. Use operators that do more for you. And so on — the language should help you solve the problem — not give you problems to solve.