rh@smds.UUCP (Richard Harter) (12/10/90)
Still at the drawing board, sigh. There have been a fair number of comments, albeit not as many as the Fortran-C wars have produced. (An argument over the respective merits of fortran and C strike me much like a contention between the merits of heiroglyphics vs cuneiform.) There have been a fair number of suggestions in print, and in the mail, that the solution is a module facility with nested dictionaries. Upon reflection I have concluded that the elegance of the concept blinds one to the reality that it doesn't really address the problem very well. Piercarlo makes the interesting suggestion that scoping should run the other way, i.e. outer levels should be able to see inner variables but not vice versa. He makes the cogent point that the traditional scheme militates against reusability. Dan Salomon pointed out, in a rather astute email message, that the draft proposal scheme is very similar to the way tree structured directories are usually implemented. I'm not sure that this is a plus or minus. :-) Arthur (artg) claims that globals are not needed (or are a bad solution) because they don't deal with inter-program and inter-process communication. He also recommends that interface definition should be primary. At this point my feeling is that I am not really happy with my own efforts or the suggestions of anyone else. The problem seems to be that everybody proposes answers without really analyzing what the problem is. (Where have we heard that before?) The following is just some notes on a stab at determining what the problem is. They are a random mixture of criteria, considerations, and babbling. 1. Language features should facilitate good software engineering practice. 2. It might be useful to think of analogies to large software systems. Some analogies that come to mind are -- the human body, the design of a large commercial aircraft, tree-structured file systems, and networks like usenet. 3. The normal way to design a large system is to decompose it into subsystems. Each subsystem is more or less self contained (it may have further subsystems) with interfaces to other subsystems going through well-defined relatively small subsystems. 4. Subsystems can share lower level subsystems. 5. Systems generally incorporate a suite of generic utilities which are (hopefully) reusable from one system to another. 6. What we are talking about here is commuciation and data access between subsystems (i.e. modules, programs, processes, etc.) One feature of this kind of communication is that there are various types of channels with different transfer rates and different bandwidths. 7. Piercarlo's discussion points up what I think should be a criterion: A local procedure should never have hard coded global names (addresses). In other words, I should be able to write a given proceedure in isolation without knowing what the global naming system is; my code should never be invalidated by changes in the global naming system. 8. Here is a formulation of the problem: Some variables (procedures) constitute a shared common environment for an entire system (subsystem). We wish the language features to make this possible and convenient. 9. A given procedure may be part of more than one subsystem. This can happen because (A) it is a generic, or (B) it is a coupling (interface portal) between the two. 10. As a rule of thumb a procedure or module should only "see" those data elements that it needs to see. The language should support this. 11. Declarations should not be replicated endlessly -- indeed it is highly preferable that declarations only occur once. 12. The lanugage features should be simple, elegant, and easy to grasp by people without a deep knowledge of computer science. They should also be efficient and economical. ----- These points are just a start. More later... -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.