• 3 Posts
  • 57 Comments
Joined 2 years ago
cake
Cake day: July 10th, 2023

help-circle


  • doesn’t he weasel out of the responsibility to give clear, logical, verifyable reasons for his position?

    Absolutely, if I remember right he leans back on having experienced bad comments more often than helpful ones. John questions this. I think it is close to dogma with Bob on this.

    Can you explain that more?

    And doesn’t the example with the prime number generation algorithm show clearly that omitting context just does not work for code?

    Quote from https://en.wikipedia.org/wiki/High-context_and_low-context_cultures

    High-context cultures often exhibit less-direct verbal and nonverbal communication, utilizing small communication gestures and reading more meaning into these less-direct messages. Low-context cultures do the opposite; direct verbal communication is needed to properly understand a message being communicated…

    Now I’m not making a strong claim that Bob and John are from different ends of the context spectrum. However it seems to me that Bob believes there is enough ‘context’ available in code and in coders themselves to communicate all meaning without comments.

    Even Bob’s diagram, to help explain the primes algorithm, assumes high context in the reader. It’s lacking any labels or key - we are just supposed to see what he means if we stare hard enough at it. If we are already immersed in the problem space then this might work but its so inefficient for anyone else.

    And once we step away from our code for even a short time we are that someone else. We are going to waste a lot of time rediscovering how the algorithm works. A case John makes convincingly I think.

    Code cannot replace comments. The primes algorithm avoids division I believe but this is not clear from the code alone. A reader might work this out eventually but a comment saves so much time. Could the code be refactored to clearly express the avoidance of division? Yes there’s probably a way, but imagine how bad that code would read and what a waste of time just to avoid a comment.


  • Stow/chezmoi/your choice for dotfiles, config mgmt for system config. You don’t need to rebuild whole server to start with ansible tho, you can take over one file at a time and grow as you learn.

    As you’ve found I don’t know of a tool that will cover both usecases as config mgmt for dotfiles is too much and dotfile mgrs for system config is probably out of their scope.



  • Another thank you for posting this, made my day.

    I have read and followed a fair amount of Uncle Bob’s work but was not aware of Ousterhout till now. Bob says during the time the Clean Code book was written there was an anti-comment sentiment about and this matches my own experience. I agree with Ousterhout that it’s taken too far in his book though.

    I wonder if there is another factor at play - some people/cultures prefer high context communication and some less. Bob seems clearly to prefer low context i.e. the burden is on the (code) reader to educate themselves. Whereas John makes it a matter of professional behaviour that we make the next reader’s work as simple as possible by commenting code as appropriate.

    Surely it’s better to assume high context is needed and provide it (within reason) versus only catering for low context. As Bob discovered he became a low context person when he returned to his own code after some time had passed.







  • I know. The author suggests:

    Experiment with new-to-you version control systems like Fossil, Mercurial, and Pijul.

    The author is:

    learning about different version control systems. For example, the differences between Fossil and git revealed a lot of my biases towards git simply because it’s familiar (and Fossil seems really cool). Reading about the theory behind Pijul absolutely bends my brain into knots. I keep trying anyway because conflicts in git are frustrating and I’d like a better solution.

    The author says:

    It would be nice to move beyond git one day and have a better experience for managing complex codebases, and not on GitHub’s timeline.



  • From the zdnet article linked in another comment:

    tech is one thing; business is another. That’s where the RSL Collective comes in. Modeled on music’s ASCAP and BMI, the nonprofit is essentially a rights-management clearinghouse for publishers and creators. Join for free, pool your rights, and let the Collective negotiate with AI companies to ensure you’re compensated.

    I guess this is the body that will be leading the enforcement/bringing the consequences


  • Sorry re-reading my comments it’s not super clear what I meant: nowhere else in the table do they take account for the ‘hidden’ on-going maintenance of looking after a server/self-hosting. So this is the only row where they address ‘cost’ and I just thought it’s a bit optimistic to say replacing all of Spotify just costs a one time server setup and storage. I think you’re saying this row was only meant to indicate financial cost and I agree it’s basically accurate from that meaning. However this is only the ‘initial’ cost. For example a self-hosted server and storage will eventually have to be replaced whereas Spotify will just keep replacing their own servers and that’s already baked into the price of your subscription (caveat: that Spotify price will rise over time).

    It’s not a big point really, maybe I’m nitpicking.