Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^3: An Introduction to Literate Programming with perlWEB

by BrowserUk (Pope)
on Jan 13, 2009 at 15:21 UTC ( #735964=note: print w/replies, xml ) Need Help??


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.

  • One in a specifically designed, targetted, concise and precise language with clearly defined syntax and semantics.
  • The other, a never designed, always changing, variably written, spoken and interpeted, verbose, imprecise language with capricious syntax and multiple semantics.

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?

  • If you do both, and then the code fix fails, you have to undo both.
  • If you fix the code first, where's the incentive to go back and fix the prose?
  • And if you fix the prose first--there;s no way to verify it.

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.
  • 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.

      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/
        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 / @_; }
        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).

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://735964]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (2)
As of 2018-08-18 02:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Asked to put a square peg in a round hole, I would:









    Results (184 votes). Check out past polls.

    Notices?