[Oberon] re. Literate Programming Light
easlab at absamail.co.za
easlab at absamail.co.za
Wed Dec 24 10:46:56 CET 2003
> 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'
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
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:
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 ?
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'.
More information about the Oberon