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'.