[h2o-discuss] Shaky education from "square wheel" representations

[Ed Lowry <ESLOWRY/0005387775@MCIMAIL.COM>]

In response to Charles Nesson's posting, I would like to offer
the following reasons for Harvard to encourage more open
development of information technology.

A school that teaches how to make buildings by putting bricks
together would fail badly if no one involved had any idea of what
was a reasonable structure for a brick. Technical education today
is in a broadly similar situation! Schools mainly teach people
how to work carefully with different kinds of information. To be
productive, students put pieces of information together in
understandable forms. But at present the people involved have
only foggy ideas about what is a reasonable structure for basic
pieces of information (or data objects). The result is that large
parts of the learning process (with or without computers) are
much more complicated than they need to be. See "Formal Language
as a Medium for Technical Education" on my website.

University faculty members who do not understand the structure of
data objects may be reasonably compared to architects who are
unaware of the shape of bricks. Part of the reason the
understanding is hard to find is that for decades so many people
have seen their profits or prestige threatened by it. Another
part of the reason has been closed institutional frameworks where
obstructionists could prevail. In contrast, almost every other
technology has given meticulous attention to its basic
structures. For further discussion see "Misdirections in
Information Technology" on my website.

The main problem with software has always been excessive
complexity. Eliminating excess complexity from software, or from
any textual representation of technical knowledge sharply
constrains the structure of data objects. This is similar to
eliminating vibration in a car by making the wheels round, or
eliminating distortion in a personal mirror by making it flat.
However, the incentives in software business and research produce
vested interests which resist large scale simplifications.
Complexity is favored to keep clientele of many kinds in a state
of dependency. Scientifically, the effect is like that of
chemists who will not purify their ingredients. It blinds them to
opportunities for progress. Educators who seek clarification of
data object structure may be thwarted by the same incentives.

Evidence that information technology has been stifled under a
closed style of decision making could be found by examining the
reasons behind the following fact. There are only a few dozen
people anywhere who have working experience with technology which
provides for simplicity of expression in software as advanced as
what IBM designed over 25 years ago. They worked at DEC (now part
of Compaq) during the 1980s. The appended test could be used to
help identify people who are less than 25 years behind. I would
like to hear from anyone who can come close to passing.

Over the years the effects of opposition to simplification in
software have grown massively. Symptoms include: 
 - inadequate educational performance in math and science.
 - a flood of needless complexity burdening the schools as  
     educational technology.
 - users entangled in proprietary complexity for decades.
 - pervasive degradation of the quality of technical information:
     accessibility, usability, clarity, interoperability.
 - mismatch between employment skills needed and those available.
 - leaders dependent on technical advisors who are over 25 years
     behind the leading edge on simplicity issues.
 - technological instability and illusions of progress.
 - large learning loads for skills of ephemeral value.
 - failure to apply traditional engineering methods.
 - ignorance of fundamental structures.
 - dogmatic rejection of the possibility of language generality. 
 - monopolization in the software industry.
 - widening the economic "digital divide".
 - failure of the FAA to upgrade its air traffic safety systems.
 - multi $G information system fiascos. Eg IRS.
 - the scale of the Y2K problem.
If decisions shaping software technology had been made in open
forums with the accountability which that implies, the picture
would be very different. A lot of historical detail could be
provided to justify the view that the scale these problems are
substantially the result of deliberate opposition to
simplification.

Those working in intellectual property may recognize me as the
perpetrator in the 1994 appeals court case "In Re Edward S.
Lowry" which extended the patentability of data structures. I
regret that result, but my employment agreement with DEC gave me
few options.

My perception of DEC's reason for litigating the patent so
vigorously is that they wanted to control and suppress the
underlying concept of optimizing data object structure. Optimum
data objects can be perceived as threatening multi-billion dollar
revenue streams by exposing essentially all current software as
"square wheel" unreasonable. The effect of the patent could be
interpreted as imposing a kind of dementia on humanity as a
whole, where the only technical thinking which is allowed to have
technical support uses square-wheel unreasonable representations.
I have a 5 page memo from a former manager at DEC forbidding me
from discussing my theory on the issue. For the past five months
I have posted a more developed form of the theory on my website
along with an offer of $20K for refutations. The response so far
has been supportive (as far as it goes) and has added
confirmation that the technical community is pervasively unaware
of issues or answers about what is a reasonable structure for a
data object. The offer remains open to all.

If the Berkman Center wants to evaluate "creative process" as a
major product in the university business model, then I recommend
evaluating simplification and improved general purpose
representation of technical knowledge as an aid to creativity. It
is discussed in the "Formal Language .." paper.

Ed Lowry
Acton Mass 
   978 263-3508
   eslowry@alum.mit.edu
   http://www.ultranet.com/~eslowry/

          ************************************

Appendix:   SHANNON Examples Compared with SEQUEL 2 

The following list of 10 example expressions are provided
indicating what degree of simplicity and clarity is achievable in
a multi-purpose language and roughly what was known to be
achievable in 1974. A person who cannot translate these
expressions into a multi-purpose programming language with
simplicity which is close to that given by the Shannon versions
is probably over 25 years behind the leading edge. Evidence that
roughly this level of capability was available in 1974 can be
obtained from "Prose Specification" by E. S. Lowry, IBM
Poughkeepsie Technical Report TR 00.2902. It was dated November
1977 but it was distributed within IBM in December 1974.
  
These examples are translated from the first 10 examples given
for Sequel 2 (now SQL) in the IBM Journal of R&D, Nov 1976. For
the first 10 expressions Sequel 2 (a specialized data base
language)  uses 130 tokens. Shannon (a multi-purpose language)
uses 99 tokens. The original Sequel 2 code is omitted as
irrelevant. The significant comparisons would be with commonly
used general programming languages like C++, Ada, or Cobol. 

     Expression 1.
 
English:       Names of employees in Dept. 50 
 
Shannon:       name of employee of dept(50)                


     Expression 2.  

Eng:   All the different department numbers in the Employee
          table. 
 
Shan:       dept_no of employee condense                        


     Expression 3.  

Eng:    Names of employees in Depts. 25, 47 and 53. 
 
Shan:      name of employee of every dept where 25 or 47 or 53 


     Expression 4.

Eng:   Names of employees who work for departments in Evanston. 
 
Shan:       name of employee of dept of Evanston          
 

     Expression 5.

Eng:   List the employee number, name and salary of 
            employees in Dept. 50, in order of employee number. 
 
Shan:       for employee of dept(50) minfirst empno 
               show(empno, name, salary)                       

     Expression 6.

Eng:   Average salary of clerks. 
 
Shan:       average (salary of clerk)                         
 

     Expression 7.

Eng:   Number of different jobs are held by employees in Dept. 50

 
Shan:       count job of employee of dept(50) condense     
 

     Expression 8.

Eng:   List all the departments and the average salary of each. 
 
Shan:       for dept show(it, average(salary of its employee)) 


     Expression 9.

Eng: Those departments in which the average employee salary is
          less than 10,000. 
  
Shan:     dept where average(salary of its employee) < 10000   


     Expression 10.

Eng: The departments that employ more than ten clerks. 
  
Shan:      dept where count(its clerk) > 10