4 ms·

My very strong suspicion is that a program written in the “literate” style and then maintained a long time is very likely to end up with its comments and implem

My very strong suspicion is that a program written in the “literate” style and then maintained a long time is very likely to end up with its comments and implementations disagreeing, making it worse, in this respect, than one without comments. I say this because this has been my observation even with much more modest amounts of comments. Keeping them in sync with the code is always a struggle.

akkartik 5y ago
That is, for me, the genius of LP. It's not just a "style" you garnish on top of your code. When you do LP you become more likely to reread the documentation as you maintain the program. Which makes it easier to keep it up to date. On the other hand, all the LP programs I've seen were built by people who care about documentation. Perhaps we would have managed to keep things up to date even without LP. There may be a selection bias here. Either way, I'd say you don't know what you're talking about when it comes to daly's Axiom (http://axiom-developer.org http://axiom-developer.org). It doesn't just end up with outdated comments, that's a serious charge to level without concrete evidence. Similarly, I'd be extremely interested in outdated comments in https://github.com/akkartik/mu/tree/main/linux/bootstrap https://github.com/akkartik/mu/tree/main/linux/bootstrap which is written in the LP style I described in OP. I consider outdated comments to be bugs.
- Someone 5y ago
  The main problem with maintenance of programs is that, when changing an assumption ‘deep down’ in the code, about nobody is going to check the chain of logic from there throughout the code. IMO, LP-style programming doesn’t change that. If the problem happens less with programs written in LP-style, I agree with you chances are it’s because people who write in that style tend to be more careful. What would change it is to require programmers to supply proofs about their code. Unit tests don’t guarantee that, but have the benefit of being easier to write.
  - akkartik 5y ago
    But you're expanding the scope now. Yes, LP isn't going to guarantee you always preserve semantics in any change. But hopefully we can agree that it's not going to make it more difficult. Unit tests or proofs are extremely useful. You should still have them in Literate programs! They're complementary tools. My Literate system does explicitly assume tests unlike earlier systems I was dissatisfied with. Check out all the tests in https://github.com/akkartik/mu/tree/main/linux/bootstrap https://github.com/akkartik/mu/tree/main/linux/bootstrap. For example, https://github.com/akkartik/mu/blob/main/linux/bootstrap/013direct_addressing.cc#L7 https://github.com/akkartik/mu/blob/main/linux/bootstrap/013...
strictfp 5y ago
I have to object here and say that out-of-date comments are better than no comments. I've worked in organizations with "no comments" policies and having no clue what people ever planned to achieve with a piece of code is worse than some old misguided explanation for sure.
- emodendroket 5y ago
  I wouldn’t support a no-comment policy, but I’ve wasted a lot of time thanks to misleading comments.
  - hiptobecubic 5y ago
    You have to assume that comments are out of date, then it's easier to make use of them.
    - emodendroket 5y ago
      But out of date in which way? It could be anything from some extra cases to literally the opposite of what the comment says to the code has changed so much it’s not even clear what the comment refers to anymore.
  - jimmyvalmer 5y ago
    Notices a kindred spirit You get it. I get it. Unfortunately every intro class inculcates generous commenting, a "best practice" further promoted by corporate proceduralists and mediocre programmers who inexorably become managers. A comment longer than 160 characters is always weak-sauce justification for logic written awkwardly.
    - emodendroket 5y ago
      For the most part comments I appreciate are something like "the obvious thing here is xyz, but we can't do that because of this goofy limitation of software we're integrating with."
User23 5y ago
This is mainly a problem for “how” comments and less so for “why” ones. “How” comments are almost always worthless at best, but “why” comments are vital for large code bases. Literate programming should consist of “why” comments and if the why changes and thus the implementation does, the commentary ought to as well.
yissp 5y ago
There are a few of these longer, explanatory comments in the code-base I currently work on, and while we do generally try to keep them up-to-date, personally I find they've become difficult to read. As the code evolves you have people trying to splice sentences into the middle of a paragraph, different people have different writing styles, some aren't native English speakers. Unless you're willing to rewrite the whole thing every time you make a non-trivial change it seems to end up a bit of a mess. As one co-worker put it "you need to read the code in order to understand the comments".

akkartik 5y ago

That is, for me, the genius of LP. It's not just a "style" you garnish on top of your code. When you do LP you become more likely to reread the documentation as you maintain the program. Which makes it easier to keep it up to date. On the other hand, all the LP programs I've seen were built by people who care about documentation. Perhaps we would have managed to keep things up to date even without LP. There may be a selection bias here. Either way, I'd say you don't know what you're talking about when it comes to daly's Axiom (http://axiom-developer.org http://axiom-developer.org). It doesn't just end up with outdated comments, that's a serious charge to level without concrete evidence. Similarly, I'd be extremely interested in outdated comments in https://github.com/akkartik/mu/tree/main/linux/bootstrap https://github.com/akkartik/mu/tree/main/linux/bootstrap which is written in the LP style I described in OP. I consider outdated comments to be bugs.

Someone 5y ago
The main problem with maintenance of programs is that, when changing an assumption ‘deep down’ in the code, about nobody is going to check the chain of logic from there throughout the code. IMO, LP-style programming doesn’t change that. If the problem happens less with programs written in LP-style, I agree with you chances are it’s because people who write in that style tend to be more careful. What would change it is to require programmers to supply proofs about their code. Unit tests don’t guarantee that, but have the benefit of being easier to write.
- akkartik 5y ago
  But you're expanding the scope now. Yes, LP isn't going to guarantee you always preserve semantics in any change. But hopefully we can agree that it's not going to make it more difficult. Unit tests or proofs are extremely useful. You should still have them in Literate programs! They're complementary tools. My Literate system does explicitly assume tests unlike earlier systems I was dissatisfied with. Check out all the tests in https://github.com/akkartik/mu/tree/main/linux/bootstrap https://github.com/akkartik/mu/tree/main/linux/bootstrap. For example, https://github.com/akkartik/mu/blob/main/linux/bootstrap/013direct_addressing.cc#L7 https://github.com/akkartik/mu/blob/main/linux/bootstrap/013...

strictfp 5y ago

I have to object here and say that out-of-date comments are better than no comments. I've worked in organizations with "no comments" policies and having no clue what people ever planned to achieve with a piece of code is worse than some old misguided explanation for sure.

emodendroket 5y ago
I wouldn’t support a no-comment policy, but I’ve wasted a lot of time thanks to misleading comments.
- hiptobecubic 5y ago
  You have to assume that comments are out of date, then it's easier to make use of them.
  - emodendroket 5y ago
    But out of date in which way? It could be anything from some extra cases to literally the opposite of what the comment says to the code has changed so much it’s not even clear what the comment refers to anymore.
- jimmyvalmer 5y ago
  Notices a kindred spirit You get it. I get it. Unfortunately every intro class inculcates generous commenting, a "best practice" further promoted by corporate proceduralists and mediocre programmers who inexorably become managers. A comment longer than 160 characters is always weak-sauce justification for logic written awkwardly.
  - emodendroket 5y ago
    For the most part comments I appreciate are something like "the obvious thing here is xyz, but we can't do that because of this goofy limitation of software we're integrating with."

User23 5y ago

This is mainly a problem for “how” comments and less so for “why” ones. “How” comments are almost always worthless at best, but “why” comments are vital for large code bases. Literate programming should consist of “why” comments and if the why changes and thus the implementation does, the commentary ought to as well.

yissp 5y ago

There are a few of these longer, explanatory comments in the code-base I currently work on, and while we do generally try to keep them up-to-date, personally I find they've become difficult to read. As the code evolves you have people trying to splice sentences into the middle of a paragraph, different people have different writing styles, some aren't native English speakers. Unless you're willing to rewrite the whole thing every time you make a non-trivial change it seems to end up a bit of a mess. As one co-worker put it "you need to read the code in order to understand the comments".