What is it all about?
Explain what you are programming in a humanly way or to a human rather than to a calculating maching. For example, we would've come across code with comments distributed/disturbed over the subroutines. Instead of making the comments as a part of sources, the sources are made as parts of comments. It makes the reader easier to follow up with what code is doing and all that stuff.
The Short History:
But there are still many pros/cons about this philosophy. Primary credits to Donald Knuth and Silvio Levy for their work in evolving the CWEB structured programming architecture. One striking thought as explained above has evolved the art of literate programming. Explain stuffs to the human, through a nice chain of linked chapters that explains the flow of the code.
Components:
All that is packed up with the CWEB is a couple of programs, known as ctangle and cweave. The former does the work of converting the _coded_ document into the _code_ and the later weaves the _coded_ document as a _document_ or in short to a '.tex' file. The interesting fact is that CWEB package is in itself CWEBized.
So, Pros/Cons?
There could be lot of statements made for or against the above system of programming. Just a small analysis would reveal that, at the end of our mind, what we finally do is a small discussion with ourself in the virtual spherical of our imagination. It is only a matter of "_typing_ that would distract the thought" feeling and laziness that would prevent most of us from becoming a literate programmer. Moreover, actually looking from a positive aspect of documentation and maintainability point of sources, this would be the better or rather the best way! But at the end the truth is that not all programs could be written this way. I could assure it would quite possibly take some years to convert the whole of GCC or Linux Kernel to make it compatible the CWEB way. But some apps or utilities/tools could be written this way.
Pointers/Where next?/Some more?
CWEB is easily reacheable. Googling it would reveal most connected one at Stanford. There are some more extensions done by people. Particularly a 'noweb' extension to any language by Norman Ramsey:
Future Generations
Bored of coding? (Ofcourse it would never be the case if we really wanted to code :) If so, here are some interesting extensions and analysis on how things were and how things might become. Initially it all started with some freaky machine language code of symbols, which dusted off to assembly to save the minds of yelling coders of the so called mechanical gadgets. Invention of assemblers and compilers relieved them of their burden. High level languages were highly evolved with analysis of what languages are all about and stuffs like that.
After crazy coders who prefer just 26 variables for any code, the maintainability, extensibility and all other xyz-bility were under question. To do a justice to all of the above and to increase our own ability, the coding standards and _good_ practices of software engineering were called up. Even then the place where the beasty processor rests and the place from where we command always required a bridging highway that was costlier in terms of explainability. Documents were always remote to exactly the stuff which they are suppose to _explain_ with _ _!
To remove this defect, the literate programming way has come up to create a document that is nothing but an explanation of what you speak to yourself or your toy if you might have nearby when coding! So, it calls for managing an internal reference in the mind so as to keep intact what we wanted to say and what we wanted to implement. A close observation would reveal, generally what we wanted to say is little than what needs to be implemented. We should learn to compromise between these factors before CWEBbing the code.
The above method is still ineffective when considered as a final limitation of coding. Last but not the least it is the exact replica of the logical web of patterns that gets wired/wound up in ones thought space. An optimal as well as a clean/neater way to just represent those logical patterns. People might argue, it is all a language (higher) for. May be they would come up with a VHLL, or a Very-High level language or some form of that. But nothing could replace the formless form of logical connections that happens to enumerate the problem at hand in mind. The ultimate aim of reducing the system of program would be to just draw a sketch, represent systems in an abstract way, represent interactions in an abstract way, and all that has already existing! Yes, it is more closer to UML diagrams. Represent the states of the code, how they work and things like that. We could extract reasonable documentation provided we have a grammer/theasaurus verifier that could do a reasonable construct of sentences and stuffs. We could also extract the code from the sketch representation of the above.
Obfuscated Code ----> Documented code ----> Coded Document ----> Generalized document/State charts.
The Threat: Software engineers, behold! We might be left with no jobs! But quantum is still there at our disposal and so, let us welcome our invisible yet inevitable quantum.
No comments:
Post a Comment