• 16 Posts
  • 232 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle
  • I strongly and broadly disagree, both with the premise and the argumentation they do.

    But first off, and because it’s significant to the argumentation; Why is their entire argumentation in line-based diffs, but when I go to their homepage I see screenshots of inline diffs?

    Inline-marking of differences are incredibly powerful. Programming language aware diffing should make use of understanding to support the highlighting, with the option to ignore different levels of irrelevance at the users choice.

    I don’t want anything hidden. I want to default to every difference shown, but put side by side as much as possible, with different levels of highlighting of the differences according to their relevance and significance.

    I want to default to every difference shown, but have alternative options to ignore things. I want to have the option to ignore whitespace changes, and potentially additional options to ignore more (this is the opportunity semantic understanding could bring, in addition to the line and change matching).


    TortoiseGitMerge allows me to choose between

    • Compare whitespace
    • Ignore whitespace changes
    • Ignore all whitespace changes

    I default to the first, but regularly switch to the second and third, when indents change. They are irrelevant when assessing the logical changes. But whitespace is still significant in laying out code. It’s both significant, but for different reasons, and as different layers and layers of assessment.

    All that being said, we don’t use an enforced automatic formatter.

    But also, we use whitespace, line breaks, and other syntax consciously. Readability takes precedence over consistency. I hate hard character limits on lines. Sometimes the vertical structure is much more significant to readability than an arbitrary (and often narrow) line character limit.


    One example:

    Do you write

    if (error != null) return error;
    

    or do you write

    if (error != null)
        return error;
    

    or do you write

    if (error != null)
    {
        return error;
    }
    

    I dislike the second because its semantic structure not very obvious and somewhat error prone. For simple early returns like this, I prefer the first. But in cases where it’s not a simple and short return, the third can be preferable despite being only one statement.

    Automated formatters often can’t do one or the other alternatively, and sometimes don’t allow ignoring one rule.



  • How did it change how I think about version control? Not much? The goals are still the same. It only does many things better than previous centralized tools.

    When DVCS came up and became popular, I used Git and Bzr.

    At work, we used subversion. In one project, we had one SVN repository in our office and the customer had one in their office. A colleage had created a sync util. We regularly synced all history into an external hard drive, drove to the customer, and merged it there. Required a thorough and checklist process, potentially conflict resolution, and changelog generating for the big merge commit. Then drive back to the office, and merge back there.

    Of course sometimes you used remote desktop to hotfix changes in their code base. Meaning you’d now have the change in two places as different commits.

    Anyway, I’ve never found Git difficult. I used it, learned and understood it, and it’s consistent. I know enough “internals”/technical details to understand and use it well and without confusion.




  • Can’t or don’t want to?

    I got into a project starting out with translations. Then community support. Then wrote a web interface to the desktop/server application. Then got into the project itself.

    Many projects have a contributing document or page with pointers. In general, being part of the community, providing information or support, improving documentation, or the bug tracker (reproduction, labeling, discussing/guiding), translating.

    What can be done and what makes sense varies a lot depending on project size and popularity too.


  • I was tempted to disagree, but the Patreon subscription paywalls is a very good point. Are we doing less free work for the public good (or at least accessible to the public), or is it a prevalent niche that’s very visible, without influence on those that volunteer work like before?

    The thought I had before that was that maybe the creative output changed. People build in Minecraft and VRChat, in hosted platforms. This may be different to before, where mods were separate things and communities.

    I still see a lot of voluntary open work. But I’m not confident in assessing it’s prevalence or shift.














  • It makes sense to include so it’s obvious in the readable HTTP request response. We use readable URLs and header names for the same purpose: So it is inspectable and understandable from that text format. You may leave deprecation information out, but then you’re missing part of the resource description that you’re addressing with the URL/URI.

    Given a defined header it also allows you to add tooling and automation. There’s no need for manual reading.