bobr@zeus.TEK.COM (Robert Reed) (12/10/87)
In article <22244@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:
'seems to desired only rarely' is a red flag. Within a particular language
one very tends to do that which can be done easily within the language.
For example, FORTRAN has no natural mechanism for recursion. One can do
recursion in FORTRAN, albeit painfully. Is it any surprise that FORTRAN
programmers rarely find a need for recursion? The same holds true of
command languages as well -- if a particular approach cannot be
implemented readily in a command language, then it won't be used.
It seems that you've never tried writing a quicksort or any tree traversal
methods in FORTRAN. I've done both, and can attest to the inaccuracy of
your statement:
Is it any surprise that FORTRAN programmers rarely find a need for
recursion?
It has been my experience that certain programmers will be willing to fight
extreme levels of hair to accomplish a given task. They may not like it,
but given the available tools and the requirements of their task, what are
they to do?
You also seem to be confusing goals with methods. The Primos and "sh"
methods are alternatives for doing the pairwise matching of files from two
directories. The methods chosen for accomplishing the task will vary with
the facilities available (e.g. use an insertion sort rather than a
quicksort), but that doesn't discount the task. In my own experience,
pairwise matching of filenames is an occasional but a rare requirement,
regardless of the command processor I happen to be using.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKg-rh@cca.CCA.COM (Richard Harter) (12/11/87)
In article <2805@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: >In article <22244@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: > > 'seems to desired only rarely' is a red flag. Within a particular language > one very tends to do that which can be done easily within the language. > For example, FORTRAN has no natural mechanism for recursion. One can do > recursion in FORTRAN, albeit painfully. Is it any surprise that FORTRAN > programmers rarely find a need for recursion? The same holds true of > command languages as well -- if a particular approach cannot be > implemented readily in a command language, then it won't be used. > >It seems that you've never tried writing a quicksort or any tree traversal >methods in FORTRAN. I've done both, and can attest to the inaccuracy of >your statement: > > Is it any surprise that FORTRAN programmers rarely find a need for > recursion? > As a side note, it happens that I have implemented quicksort and tree traversal methods in FORTRAN. I have even done things in FORTRAN that are hard to do. (Simple recursion in FORTRAN is not hard -- it is merely tedious and prone to error.) More to the point is that I think you have missed the point of what I was saying. Let us return to the FORTRAN programmer for a moment. If you ask a typical FORTRAN programmer if recursion is important, the answer is very likely to be "no". (I acquit you of being a typical FORTRAN programmer.) And, for him, he is right -- recursion is an unimportant theorectical novelty with no real practical use. How can he say this, you ask? Very simple, he is wearing blinders induced by the language he uses. He doesn't use recursion, and he doesn't think of using recursion, because it is not part of his natural lexicon. Recursion becomes something that is done only if there is compelling need for it. You go on to say: >You also seem to be confusing goals with methods. No, what I am saying is that goals are conditioned by methods. More particularly, subgoals are conditioned by methods. If a particular methodology is difficult in a particular language, then one does not use it as a regular thing. If X is not easy to do, then one doesn't try to do X. If you never do X, then X can't be very important to do. Note that I am not saying that this line of reasoning is correct -- merely that this is the natural tendency. A statement that X can be done easily in Primos (clearly false, nothing can be done easily in Primos) and not easily in sh, but that it doesn't matter because X hardly ever needs to be done, is suspect if it comes from someone who only uses sh. The user of sh may never see a need for doing X, because he doesn't think of doing X. If one wants to evaluate X as a tool, one should talk to the people for whom it is easy. You may find that they don't use it much either. You may find that they use it all of the time but that it is a workaround for something that could be done more naturally in another language. Or you may find that they use it all of the time and that it is a useful concept that is missing from your lexicon of concepts and tools. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
raveling@vaxa.isi.edu (Paul Raveling) (12/12/87)
In article <2805@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: >In article <22244@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: > > For example, FORTRAN has no natural mechanism for recursion. One can do > recursion in FORTRAN, albeit painfully. ... HP FORTRAN, at least as supplied on 9000/320's and 350's, supports recursion by default, much as C does. If a program needs static data allocation, it's necessary to either type particular data as static or compile with a switch to force compatibility with older, nonrecursive FORTRAN implementations. --------------- Paul Raveling Raveling@vaxa.isi.edu