farren@hoptoad.UUCP (07/05/86)
In article <142@cci632.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: [article excerpted for later comment] [1] > ... pull out the old "recursive decompiler" >and "descriptive text cross reference tool" and expand those deep nested >routines into a pretty "structured listing", which includes the whole >system. > >An even better trick is to draw a roadmap before, during or after coding, >and include it in the functional spec. [2] >Unfortunately, many people are afraid of new tools that require changes in >the way one thinks. [3] >The weakness of forth is not documentation or structure, but the lack >of axiomatic organization. It requires a good associative data base, >either human or computer. If this is understood and planned, it can >be quite a simple matter to sell this type of system. [3] - It is precisely the lack of axiomatic organization which makes Forth nearly unusable in an environment where code must be generated quickly, in concert with other programmers, and in a fashion which must be maintained by programmers other than the original programmers. I have watched many Forth programmers at work, and found *NONE* who went about the job of prog- ramming in an organized fashion. Much more likely was the "hack" method - develop a routine which does a specific, fairly low-level, job, and then cut, bash and squeeze to fit it into the larger structure. It takes a very organized person to be able to keep the entire organization of a large soft- ware project in his/her head, from top to bottom, and although Forth does not force this type of conceptualization, the majority of Forth programmers I have worked with seem to work this way. [2] - ALL new tools require changes in the way one thinks. It is simply a matter of deciding whether a major change in one's thought is valuable, or will create more difficulty than it will solve. My feeling is that there isn't enough benefit to "thinking Forth" to justify relearning 15 years worth of lessons. Show me that there is, and I may change my mind... [1] - One of the problems I have with Forth is that it requires external guides before complex programs become comprehensible to someone unfamiliar with those programs. It shares with assembly language the drawback that the low-level modules are extremely primitive, and, in turn, are often used in extremely labyrinthian ways to accomplish a higher-level goal. This does nothing to help understanding. When you add in the very peculiar structure, syntax, and notation, you have a software system that, in every complex example I have seen, is cryptic to the point of illegibility. I have been able to take quite complex C programs, and in a matter of a week or two, with no help from the original authors, been able to port them to entirely different systems with minimal problems. The only time I tried this trick with a Forth program (and a small one at that, originally programmed by someone I was assured was a very good Forth programmer) I worked for a month before finally deciding to scrap the whole project. (BTW - this involved porting to a machine with an order from management - "No Forth!". We finally decided to do a functional equivalent to the program - management decided to hell with the whole idea.) ---------------- Mike Farren hoptoad!farren
rb@cci632.UUCP (07/14/86)
In article <893@hoptoad.uucp> farren@hoptoad.UUCP (Mike Farren) writes: >In article <142@cci632.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >[article excerpted for later comment] >[1] >> ... pull out the old "recursive decompiler" >>and "descriptive text cross reference tool" and expand those deep nested >>routines into a pretty "structured listing", which includes the whole >>system. >> >>An even better trick is to draw a roadmap before, during or after coding, >>and include it in the functional spec. >[2] >>Unfortunately, many people are afraid of new tools that require changes in >>the way one thinks. >[3] >>The weakness of forth is not documentation or structure, but the lack >>of axiomatic organization. It requires a good associative data base, >>either human or computer. If this is understood and planned, it can >>be quite a simple matter to sell this type of system. > >[3] - It is precisely the lack of axiomatic organization which makes Forth >nearly unusable in an environment where code must be generated quickly, >in concert with other programmers, and in a fashion which must be maintained >by programmers other than the original programmers. This is one I will gladly concede, in fact the most touted advantage of Forth is that one programmer can build a complex system in a few weeks or months (this is more a function of coding style and environment than language syntax), there is no guarentee however that anyone else will understand the quirks of the original programmer :-). >[2] - ALL new tools require changes in the way one thinks. It is simply a >matter of deciding whether a major change in one's thought is valuable, >or will create more difficulty than it will solve. My feeling is that there >isn't enough benefit to "thinking Forth" to justify relearning 15 years >worth of lessons. Show me that there is, and I may change my mind... The reason this came up in net.arch in the first place is because most programmers spend 5-15 years thinking in terms of large, flat routines. When these routines are broken into their smallest componant parts, they end up being useful "extensions" or "primitives. Anyone can benefit from habits learned by using forth, reguardless of the actual language they use. The other feature of "screen sized subroutines" is that in RISC archetectures with good fast caches, these primitives become self-optimizing micro-code. >[1] - One of the problems I have with Forth is that it requires external >guides before complex programs become comprehensible to someone unfamiliar >with those programs. It shares with assembly language the drawback that the >low-level modules are extremely primitive, and, in turn, are often used in >extremely labyrinthian ways to accomplish a higher-level goal. There are two issues here. If the primitives are "axiomatic" (you intuitively know what they do, and what results to expect), they can be more useful than a "compiled language" in which all primitives are limited to a specific syntax. Unfortunately, Forth primitives are not as axiomatic as they could be. Here, Smalltalk has shown to be a definite improvement over Forth. >This does >nothing to help understanding. When you add in the very peculiar structure, >syntax, and notation, you have a software system that, in every complex >example I have seen, is cryptic to the point of illegibility. In Forth, as in C, coding styles can vary from well structured to "totally obfuscated". Look at some of the winners of the "obfuscated C contest" :-). Many forth packages are deliberately obfuscated just before release. The most common technique is the "white space squisher". Seeing forth with no block structuring can be quite distressing. This is not the "normal" form or style. >I have been >able to take quite complex C programs, and in a matter of a week or two, with >no help from the original authors, been able to port them to entirely different >systems with minimal problems. The only time I tried this trick with a Forth >program (and a small one at that, originally programmed by someone I was >assured was a very good Forth programmer) I worked for a month before finally >deciding to scrap the whole project. (BTW - this involved porting to a >machine with an order from management - "No Forth!". We finally decided to >do a functional equivalent to the program - management decided to hell with >the whole idea.) Ironically, I had just the reverse experience. My first introduction to C was Ron Cain's compiler, followed immediately by V6 Unix. My previous experience was in Forth, and these 20 page definitions, pointers to functions returning pointers to ints, and some of the other "finesse" tricks of C made my first impressions of C less than great. Fortunately, I got over this initial shock and C has been a very useful language ever since. However, I still try to stick with "screen sized" functions, build libraries and a main-line, rather than programs with a few subroutines. I won't even try to convince anyone they should convert all of their production code to Forth. There are too many advantages to the C/Unix environment such as lint, indent, cb, cflow, ..... that make C easier to document and analyse. What I do reccomend, is examining general style of programming. Do you use an in-line copy rather than a macro or a subroutine. If you could use a subroutine at little or no cost, would you rather use a macro or a subroutine? If the answer to the last question is yes, then it is actually possible to build an archetecture that makes subroutines containing loops run FASTER than an in-line expanded loop. To be honest, if there were a GOOD C interpreter or incremental compiler/ editor that supported FULL C, available in source form for 4.2 BSD, I would really like to know! It is the only part of Forth that I actually miss :-). >Mike Farren >hoptoad!farren Rex Ballard.