freeman@spar.UUCP (Jay Freeman) (07/26/85)
[]
>General question: does anybody "write code" on paper first any more?
Not since line-editors saved me from using Hollerith cards to input source.
I still use pencil and paper ("woodware"?) for algorithm/program design,
though, mostly with psuedocode. I do not have a written design for all code
when I sit down at the terminal, however; and when I do it is generally
nowhere near as detailed as the code that implements it will be.
--
Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer)
bobd@zaphod.UUCP (Bob Dalgleish) (07/30/85)
Most of the programs that I write are "old" - I have written them or something like them many times. Normally, only about 10% of a program is new to an application. Thus, as Marty suggests, I can block out most of the program at the terminal in "memory dump mode". Also, I can test the parts that I have written because my file is on the computer (even old programs need testing :-). The part of the program that is new does need to be designed, but I usually have the design blocked out in my head before starting. Even if I don't, clearing the "standard" part of the program out of my head leaves room to concentrate on the new part. I think the process is similar to designing a mammal - the skeleton and internal organs don't change very much, but you have to do a little extra work to get the skin, muscalature and brains done correctly. My most satisfying programs are written with paper and pencil. I don't do a lot of erasing either - a line through the offending code means that I can go back and reuse the code if I backtrack. Also, when too much stuff changes or the code is just wrong, I recopy the entire block of code by hand, implementing all of the fixes that I had been logging mentally as I was writing. I also keep the old pieces of paper for a time for backtracking. The program eventually evolves to the point were running it is feasible and I am satisfied with it. When I try this approach on the computer, I have too much investment in what I have written to change it. This is really an odd thought - computers should make it easier to change, not harder. Maybe the problem is backtracking - "undo" is chronological, I backtrack in "thought order". -- [Forgive me, Father, for I have signed ...] Bob Dalgleish ...!alberta!sask!zaphod!bobd ihnp4! (My company has disclaimed any knowledge of me and whatever I might say)
oz@yetti.UUCP (Ozan Yigit) (07/31/85)
I do not "write" the program on paper, but I also do not believe in pure terminal (?) programming. I use large amounts of desk space for reference material, relevant program listings, highlighters, several coffee cups and other miscellania. I found that the following works best for me: Context files: typically contains notes on implementation details, visual abstractions of complex data structures, photocopies of relevant articles from IEEE and ACM journals, listings of programs that are somehow relevant to the problem at hand. (As an example, my context file on regular expressions contains the photocopies of the original article by Ken Thompson (CACM 11, #6 1968), another very interesting implementation by Martin Richards (Software- Practice & Experience, Vol. 9 1979), listings of public-domain implementations of grep (DECUS C distn.), ratfor implementation of makpat, amatch etc.) and a page of references, including coffee stains..) Blackboard: Scribbles and flow control / interaction diagrams for interesting parts of the program at hand. Note pad: I use pseude-code for complex algorithms only. One cannot always go to C directly from a theoretical description of the algorithm, say the description of "patricia trees" in JACM. (A Space- Economical Suffix Tree Construction Algorithm, J. ACM 23, April 1976). Obviously, these notes are kept in the context file. Graphic abstractions of certain parts of an algorithm or a program help a great deal in discovering shortcomings and/or new implementation strategies. (I draw well :-) Consider a simple routine such as translit in m4. (translit(dest,from, to)) Although it is very straightforward to implement this routine directly on the terminal, the critical part of translit is its *side effect* part: a call such as translit(str,"abcde","bd-?-") will map character "a" to "b". But notice that "b" is mapped to "d" which is mapped to "?". Thus, a is ultimately mapped to "?". In one sitting, one is tempted to make multiple passes over str to resolve all side effect mappings such as this. I had such an implementation about a year ago. This time, I did a small graphic representation of what was going on in terms of this *side effect* mapping, and this visual representation revealed an implementation that is about 5 times faster than the previous one, and resolved all *side effect* mappings in one pass. (routine is included at the end of this article..) Pseudo-code: I have my own pseudo-code, which is a cross between C and English. Although certain design methodologies (such as Jackson's) look interesting, I do not yet use them, since I am not yet convinced that they offer any great advantages, undoubtedly an arguable case. What is the use of all this: It turns out that all this preperation pays off very handomely if one has to prepare a "walk through the implementation of X" type document, or one has to make a presentation about X. Of course, the context file is saved for future use on similar projects, now including the listings of X. One can use the context file to follow the thought process of the original implementor, find all the algorithms, references, similar implementations as one coherent whole. So far, I have resisted the temptation of saving the photos of my blackboard. :-) I am sure many others have similar techniques in software development. I would be interested in hearing about them. To finish off, a quote from Knuth: "That is my new hobbyhorse, to say that people should think about the communication of the program while writing it. This makes it easier to write. The suprising thing is, that even though I'm writing programs that are better documented, it's taking me less time to write the program." Computer Language, Vol. 2, May 1985 Oz ----------- map routine ------------ /* * map(dest, source, from, to) * * map every character of source that is specified in "from" * into "to" and replace in dest. (source remains unmodified) * * This is a semi-standard implementation of translit(s,from,to) * routine of M4. Within mapvec (an identity vector), we replace every * character of from with the corresponding character in to. If to is * shorter than from, than the corresponding entries are null, which * means that those characters dissapear altogether. Furthermore, * imagine map(sourcestring, "srtin", "rn..*") type call. In * this case, `s' maps to `r', `r' maps to `n' and `n' maps to `*'. * Thus, `s' ultimately maps to `*'. In order to achieve this effect * in an efficient manner (i.e. without multiple passes over the * destination string), we loop over mapvec, starting with the initial * source character. if the character value (dch) in this location is * different than the source character (sch), sch becomes dch, once * again to index into mapvec, until the character value stabilizes * (i.e. sch = dch, in other words mapvec[n] == n). Even if the entry * in the mapvec is null for an ordinary character, it will stabilize, * since mapvec[0] == 0 at all times. At the end, we restore mapvec * back to normal where mapvec[n] == n for 0 <= n <= 127. This strategy, * along with the restoration of mapvec, is about 5 times faster than * any algorithm that makes multiple passes over destination string. * * Ozan S. Yigit (oz) * July 15 1985 * */ map(dest,src,from,to) register char *dest; register char *src; register char *from; register char *to; { register char *t0; register char sch, dch; static char mapvec[128] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127 }; if (*src) { t0 = from; while (*from) /* initialise mapvec... */ mapvec[*from++] = (*to) ? *to++ : (char) 0; while (*src) { /* map and follow chains */ sch = *src++; dch = mapvec[sch]; while (dch != sch) { sch = dch; dch = mapvec[sch]; } if (*dest = dch) dest++; } while (*t0) /* restore mapvec back..*/ mapvec[*t0] = *t0++; } *dest = (char) 0; } -- __ O Usenet: [decvax|allegra|linus|ihnp4]!utzoo!yetti!oz / /\___ Bitnet: oz@[yuleo|yuyetti] . ------------------------- / \ Support GNU. Consider the 3-musketeers' motto: / --+ ONE FOR ALL - ALL FOR ONE /
bc@cyb-eng.UUCP (Bill Crews) (08/05/85)
> My most satisfying programs are written with paper and pencil. I don't > do a lot of erasing either - a line through the offending code means > that I can go back and reuse the code if I backtrack. Also, when too > much stuff changes or the code is just wrong, I recopy the entire block > of code by hand, implementing all of the fixes that I had been logging > mentally as I was writing. I also keep the old pieces of paper for a > time for backtracking. The program eventually evolves to the point > were running it is feasible and I am satisfied with it. When I try > this approach on the computer, I have too much investment in what I > have written to change it. This is really an odd thought - computers > should make it easier to change, not harder. Maybe the problem is > backtracking - "undo" is chronological, I backtrack in "thought > order". I find the conclusion drawn here to be suitable for net.bizarre. Copying code over by hand with pencil is easier than editing it with an editor? Too much is invested in code in a text file to change it, whereas with it on paper, the investment and the ability to change it is less?? Maybe I missed an intended ":-)" here. -- / \ Bill Crews ( bc ) Cyb Systems, Inc \__/ Austin, Texas [ gatech | ihnp4 | nbires | seismo | ucb-vax ] ! ut-sally ! cyb-eng ! bc