Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
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).

Re^4: An Introduction to Literate Programming with perlWEB
by Anonymous Monk on Jan 13, 2009 at 16:21 UTC
    dude, why are all your replies a long ranting screed? Do you really expect people will read all that? Keep your posts much shorter and concise. I find it odd when you accuse someone of being obtuse but your reply is twice as long as the original and full of contrived and nonsensical examples. If you don't understand music or architecture why do you think you can use them as examples? wtf?

      "obtuse" ne "length".

Re^4: An Introduction to Literate Programming with perlWEB
by Anonymous Monk on Jan 13, 2009 at 18:22 UTC
    BowserUK, have you sought treatment for your Aspberger's yet? Your tiresome lengthy screeds fail to ever have much merit and reek of a manic compulsive disorder. I suggest you try and raise your signal to noise ratio!

      Nobody is forcing you to read them!

      and its Asperger's

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://735964]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2018-01-19 11:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How did you see in the new year?










    Results (217 votes). Check out past polls.

    Notices?