Re: CoBOL moved to OO

From: RKRayhawk (rkrayhawk_at_aol.com)
Date: 01/01/04 

Date: 01 Jan 2004 01:37:08 GMT

Waxing into the utter ether of computer science

"Judson McClendon" judmc@sunvaley0.com
Date: 12/29/03 12:45 PM EST
Message-id: <7258afb54b163acc96b1cc53a5e0e3a5@news.teranews.com>

entertains that

<<...
All recursive algorithms can be coded iteratively,
...>

Yeah.? Well maybe, but not by all persons. The issue is the labor force. Are
there algorithms that can be coded more easily as recursive expressions versus
iterative expressions? Is it the case that some folks can indeed see the
algorithm at long last when they are thinking in recursive paradigms, whereas
they is utterly blind to it in flatlanderese?

Dijkstra asserted that bubble sort became 'visible' to the author (who was not
Dijkstra by the way) because of the recursive aspect of the programming surface
available in ALGOL, and that it was particularly recursion which made that
happen.

I would assert, in opposition to your thought, that some folks can think the
algorithm in recursion and not think it in iteration and that is why the
availability of the tools of that genre matter. We need to make those workers
productive, and rip down the walls that would exclude them from business data
processing work. And that will begin to happen now in COBOL, and it is likely
to count since folks have money in front of them when they have the COBOL
compiler in front of them.

Although the RECURSIVE program ID has been around, there is not much literature
promoting it. There is a great deal of literature, and academic activity,
prompting use and study of all of the OO stuff, which happens to include
recursivity intrinsically.

Tools that can do recursion, and help the programmer think recursion are money
makers.

But most application requirements are not recursive in the problem domain. Some
that are, .... and easily admitted ... can be and have been implemented by
iteration. On the other side of the coin, and it is a money thing, there are
requirements that are better implemented as recursion.

Apps with deep interst rate and return on investment challenges are really
recursive. We would be doing harm to businesses if we in anyway discouraged
recursion in these application areas, ... financial harm. Recursion is a
significant construct. Valuable! A money maker. Use it! Cathect it whenever
possible.

Recurse!

Best Wishes
Bob Rayhawk
RKRayhawk@aol.com

Relevant Pages

  • Short koan-like code snippets (was: coerce for arbitrary types)
    ... (defun bfs6 (test children pending) ... The algorithm seems to be a tail-recursive expression of what ... I don't like using tail recursion to emulate iteration, ...
    (comp.lang.lisp)
  • Re: CoBOL moved to OO
    ... > there algorithms that can be coded more easily as recursive expressions versus ... > algorithm in recursion and not think it in iteration and that is why the ...
    (comp.lang.cobol)
  • Re: newbie question: recursion algorithm and iterative algorithm
    ... Prolog doesn't have iteration. ... recursion in Prolog, and the implementation may implement it by iteration. ... recursive algorithms can always ...
    (comp.lang.prolog)
  • Re: Simple recursive functions in Lisp
    ... (labels ((rev (lst acc) ... becomes a loop variable. ... to the naive car/cdr recursion). ... Another way to express Graham's algorithm is iteration. ...
    (comp.lang.lisp)
  • Re: Software bugs arent inevitable
    ... I suggested that for a given algorithm implemented ... iteration should always be faster by a small factor. ... > recursive function can run out of stack space while the heap still has ... Which is why, in the part you snipped, I said that recursion (unlike ...
    (comp.lang.python)
Loading