What a Programmer Does (1967) [pdf](archive.computerhistory.org)
100 pointsby nza month ago6 comments
  • svata month ago
    What does Knuth mean by

    > I particularly like his definitinon of a bad programmer. (My personal record is about 12 years.)

    here?

    • tjra month ago
      The article describes a bad programmer as one whose programs “die young”. I would guess that Knuth is saying is that the longest one of his programs lived (was used?) for 12 years?

      If that is what he meant, I presume this remark was written well in the past, as TeX has lasted way more than 12 years.

      • bdunks23 days ago
        That makes sense. His cover letter is dated 1974, and TeX was released 1978.
    • syncsynchalt22 days ago
      The note is actually from Chuck Baker, the editor of that issue of Datamation.

      You're not alone in assuming DEK wrote the note, a lot of people seem to attribute it to Knuth.

      • svat22 days ago
        I see. I was talking about not the article itself, but this handwritten note on the front page:

        > This article from Datamation is by someone from ADR - the name might be Moore. (It wasn't meant to be anonymous; that was accidental). A lot of people who knew me thought I wrote it. I wish I had!

        > I particularly like his definition of a bad programmer. (My personal record is about 12 years.)

        The scan comes from Knuth's personal collection scanned by the Computer History Museum. Many of the documents have similar notes by Knuth, so I assumed this was by him too. Though on closer look, I'm not so sure the handwriting is the same. (It would be ironic if a note about misattribution gets misattributed.) How do you know the note is by Chuck Baker?

  • aaronblohowiak22 days ago
    If you liked this, you may like my favorite paper https://pages.cs.wisc.edu/~remzi/Naur.pdf
    • perrygeo22 days ago
      It's remarkable how these papers show a deep understanding of programming 50 years ago. Even with anemic hardware, the limit is always in the programmers brain - as uncomfortable as that is to admit. Half a century of new tech and AI and the cloud etc, we still hit "terminal trauma" fairly quickly in the development cycle, almost like clockwork. All the tools and technical tricks don't seem to matter vs. our ability to hold the application in our heads.
  • whntheduvscry22 days ago
    > The terminal trauma of a program occurs when it is challenged by entropy beyond its capacity to adjust.

    This seems true.

    In my experience, these things that happened to kill programs could be considered entropy:

    - New (e.g. hardware / software / code / people / focus)

    - Money (e.g. actual or perceived infusion of it / actual or perceived lack of it / focus changed)

    - Loss (e.g. someone or something left / was injured / died / was destroyed / was deleted / was corrupted)

    And I think that if you have a system that contains risk due to entropy, then even a planned event resulting in success is entropic, e.g.:

    - I plan a sunset for X software.

    - There is risk of an asteroid or sudden epidemic that would thwart that plan.

    - The “dice are rolled”, and the sunset happens because the asteroid and epidemic didn’t happen.

    - Therefore, the planned sunset occurred due to less than 100% chance. This is still entropic.

  • dang22 days ago
    One past discussion:

    What a Programmer Does (1967) [pdf] - https://news.ycombinator.com/item?id=12568863 - Sept 2016 (45 comments)

    (Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)

  • A_Duck22 days ago
    The 'Aerospace Corporation' job ad!

    "These are excellent opportunities for men ... An equal opportunity employer"

  • devhouse22 days ago
    Will it now instead of “write code for humans”, become “write Prompts for humans” with AI?