🚀 go-pugleaf

In article <1990Nov30.191454.29030@newcastle.ac.uk> Chris.Holt@newcastle.ac.uk (Chris Holt) writes:
>In article <PCG.90Nov27153408@odin.cs.aber.ac.uk>
> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>[lots of interesting reasons why scoping should be changed from
>the standard way]
>
>Purists have long maintained that anything in one part of a
>program should be explicitly imported or exported if it is to
>be visible in another (remember Dijkstra's glovar declarations?).
>This has never taken off because in real life the number of things
>that need to be redeclared over and over again is enormous; and
>really important things can be remembered anyway (at least when
>writing the code :-).
>
>Well, I tend to view objects as 3D structures, e.g. spheres, that
>have windows in them.  

Many good, practical reasons argue against global variables.
Modules (objects or processes) sharing variables are constrained to
run on the same machine unless the distributed system running
under them implements shared memory.    So sharing variables
can prevent a distributed program from being reconfigured, and
can make it impossible to do process migration.  Sharing, and unconstrained
module interface design, explains why computer software functionality
and construction has progressed so slowly.

My favorite analogy that suggests how software should be decomposed
is electronic hardware.   Electronics could not have made great strides 
without the clearly defined INTERFACES between components.  Anyone
who builds a memory chip that satisfies the interface specs -- physical
dimensions (ie pinout positions), voltage levels, and logical
behavior -- and improves on PERFORMANCE characteristics of the chip --
power consumption, failure rate, cost and response time -- will get 
others to use the chip.  This lets loads of people and organizations
specialize in memory chips and improve their quality.  Digital
logic's full of widespread and sensible interface requirements, from
binary logic levels to addressing that uses a power of two bits.

Software, meanwhile, seems to be ruled by the law "First interface
to get market share wins", independent of quality.  See MS-DOS, 
OS/360, kermit, Lotus-123, dBase, Unixes, etc.  (If I haven't picked
on you please dont feel left out.  :-) )  

My belief is that if programmers and system designers spent more
time defining and PROGRAMMING the interfaces between separate modules,
(and only shared data specified in the interfaces), then programs would
plug together much more easily than they do today and programmers
would benefit much more from each other's work.

Languages therefore should be able to specify, independently of any
program, the data that modules pass between themselves - its type,
its degree of initialization, and other representation independent
characteristics.  Then modules should be composed, much in the way
that chips are combined into ALUs, ALUs into
boards, and boards into machines, etc., so that each composition can
be defined by its set of interfaces with the outside, and the outside
doesn't care about the implementation of a given composition.

Arthur

artg@ibm.com
IBM Research
Yorktown Heights