in reply to Re^2: An Introduction to Literate Programming with perlWEB
in thread An Introduction to Literate Programming with perlWEB

You've either failed to read the post, or are just being deliberately obtuse in order to dismiss it.

The only one I'l come back at you on is 7: If the interleaved prose is not a secondary attempt to explain the algorithms and operations of the code it interleaves, why it is interleaved?

If it isn't an attempt to re-describe the code--and both your example and those in Knuth's original paper show otherwise--then there is no logic at all in keeping with the code, let alone interleaving it.

And the answer of course is that it is an attempt to describe the code. And syntax, used to describe algorithms, is programming by any other name. So now you have two descriptions of the same thing.

And both need to be maintained and synchronised.

Maybe if you are writing a book or academic paper, there is some merit, but for production code...it simply does not make sense. To me at least, but whatever floats your boat.

I will say that having been there and done that--and in a much less intrucive form; no reordering or pre-processing--it was a nightmare to both write and maintain. And that was with the benefit of a folding editor that would hide the verbiage at a keystroke.

By way of example, you're in there fixing a bug. Do you fix the prose or the code first?

Any way you look at it, it's simply extra work for little or no gain.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^3: An Introduction to Literate Programming with perlWEB

Replies are listed 'Best First'.
Re^4: An Introduction to Literate Programming with perlWEB
by JavaFan (Canon) on Jan 13, 2009 at 16:32 UTC
    By way of example, you're in there fixing a bug. Do you fix the prose or the code first?
    If that's an argument to literate programming, then that's an argument to write any form of documentation or comments.

    Note, I'm not making any argument against or in favour of literate programming.

[reply]
      I disagree. A bug is bug because it creates an unexpected behaviour which differs from the documentation. Once fixed there should be no reason to touch the docs. Of course it can also be the other way round, the documentation is outdated because of a "urgent feature" got implemented.


      holli, /regexed monk/
[reply]
[d/l]
        A bug is bug because it creates an unexpected behaviour which differs from the documentation.
        Sillyness.

        Suppose you have a routine like this in your company's application. 

        # Calculate the average by adding the parameters and
# dividing them by the number of elements.
sub avg {
    my $sum = 0;
    $sum += $_ for @_;
    return $sum / @_;
}

        [download]
        Now someone files a bug report, the application dies with a divide by zero error, and the line number the bug happens is in this subroutine.

        Now, you think you get high marks on your end-of-the-year review if you close this report with "Not a bug, the behaviour of the routine matches its documentation"?

        Of course, there are many bugs because the code differs from the documentation. But bugs don't disappear just because the documentation matches the code.

        Now, if you had said "you cannot have a bug if the code matches the specification", you may have something to argue (but even that is something I don't agree with).

[reply]
[d/l]
A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Meditations