[Oberon] re. Literate Programming Light

[easlab at absamail.co.za]

Edgar wrote:-

> a while ago we had the topic of literate programming which has the 
> aspect of mixing code and documentation.
> Now I have the task of working with a lot of C code. 
> I'm thinking about adding Oberon outlines, panels and perhaps other 
> objects as comments.OTOH I still need the pure C code.
> So I imagine a EditTools.StoreOx (OberonUnix) which stores a file 
> Work.ox which has Gadgets in it to a pure ascii file Work.c with e.g. '/*o*/' 
> for every Oberon object it contains and a Work.Lib.
> 'EditTools.LoadOx Work.ox' would merge these files again in a Text it opens.
> So my question is whether you think this would be simple ?
> Is it easy to store objects to a library or would it be even better to write
> them to a Texts file ?

Sorry that I don't know enough about the details of 'objects to a library',
but any contribution to the problem of 'commenting code' is a massive
contribution, with wide applications.

Here's what I was recently thinking about 'working with a lot of C code':
  ? linux has got p2c [pascal to C translator]; why not c2p !
  ? why not just have 'templates' for visual comparison, to help ?
  ? why not just have 'templates' to program in general, since there are 
basically few needed/valid constructs.

 Because of the disease of bloat and complication creep, which Wirth
fought for decades.
 ? why must I have a hundred keys and select an 'R' and select an 'E'
..P,E,A,T !
  In fact selecting a 'REPEAT' is also absurd, since only the unit:
  'REPEAT <stuff> UNTIL' is valid.

----
This thinking leads to what is apparently called 'visual programming'.
NB. a watershed in computing was spreadsheets: where each stage
of programming was the selection from the small set of possibilities.

? why pretend that there are a near infinite set of possibilities, when
there are only 6; which can be presented on a menu.

The reason is what I call 'the little man in the box syndrome':
in the beginning days of computing, the hackers liked to think
-pretend that there was a 'little man in the box, with whom you
could communicate'.  Since he couldn't yet speak [they are still
working on this] you typed a message to him and he typed one
back [to your TTY] in ENGLISH !

Programmers who have learned [invested effort] in 'their jargon',
protect their investment -  there is, often fierce, resistance to dumbing
down the act of coding.

The literature tells that there are problems with 'spreadsheet
style programming' [I'm still tying to find which] and we know that
what I advocate is old hat and never went anywhere.
----

OTOH analysing "what makes Sys 3 so productive" shows:-
* mouse cording moves routine cognition to sub-concious level
* the frames and their commands are well designed/evolved. 
* Watson and Columbus use the powerfull concepts of
  i) hyperlinking,
  ii) never force the user to CREATE when he can just SELECT.

----
The absurd persistence of 1950's notation for assembly programming
is remarkable, and shows the inertia to change.  Consider:-

1.  natural language: input from portA; invert the input; 
    and output to portB

2. 'symbolic' notation:
   W <- portA
   not W -> W
   W  -> portB

3. typical [copyrighted] mnemonics:
    movf  portA,W
    comp
    movw  portB

Every time you look at a new assembly language mnemonics
listing you/I have to translate the meaning via the 'symbolic' notation.

So why don't they just/ONLY use the symbolic-notation ?
Inertia !

Decades ago, I needed an assembler for an 8-bit chip, and built
one using the self-documenting symbolic style:
  A+B -> A   instead of eg.,  Add B,A

Now I'm investigating a menu-style assembler.
Why should you construct the 7 char string "A+B -> A", when
 you are conceptually selecting 3 steps ?
Perhaps a 'panel' with operator [about 10] buttons, and ListGadget
(or 2) for operands ?

[ My argument is less valid for complicated architectures].
-------------

 An application which I can't live without is Nortons commander:
 DOS >  WINxx and cloned to mc for linux, confirms the power of
just navigating a tree and selecting valid selections, instead of 
remembering archane syntax.

An yet there are many (the majority) who prefer to 'write messages to
the little man in the box'.
-------------

So yes, some revolutionary ideas are needed to break the inertia
against documenting/automating coding.

== Chris Glur.

PS. this is about software engineering, not oberon ?
The direction of oberon should be guided by principles of
software engineering, which is guided by 'human cognition'.