Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)B

BatmanAoD

@ BatmanAoD @programming.dev

Posts
2
Comments
273
Joined
3 yr. ago

  • After seeing people use the UI to commit to git I understand where all those - sorry: shitty - commit messages come from....

    Jump

  • They are hard to discover… and hard to use.

    Flippin' fantastic, that's exactly what I want out of my documentation tooling.

    I absolutely agree it would be better if forge data were part of the repo itself rather than separate. But for teams that are using a forge in the standard way, they should rely on the forge for this sort of thing, rather than hide important information in an obscure git feature.

  • OOP is not that bad

    Jump

  • But how does the alternative solutions compare with regards to maintainability?

    Which alternative solutions are you thinking of, and have you tried them?

    Rust has been mentioned several times in the thread already, but Go also prohibits "standard" OOP in the sense that structs don't have inheritance. So have you used either Rust or Go on a large project?

  • After seeing people use the UI to commit to git I understand where all those - sorry: shitty - commit messages come from....

    Jump

  • It's not documentation, though. That's my point. It's a byproduct of the development cycle, not a place to store important information.

    Commit messages are tied to a commit, sure, but why do you expect developers to have better discipline in writing commit messages than they have in updating code comments?

  • After seeing people use the UI to commit to git I understand where all those - sorry: shitty - commit messages come from....

    Jump

  • I mean, I've been doing this for over a decade too. If teams are losing data from their issue tracker or source forge, that's a deep problem and not something that can be ameliorated by writing better commit messages.

  • After seeing people use the UI to commit to git I understand where all those - sorry: shitty - commit messages come from....

    Jump

  • The gitlog is intended for contributors of the project whereas the chamgelog is intended for users of the project.

    That makes sense to me.

    I think I would still argue, however, that for projects using github, gitlab, or any similar forge with a built-in pull-request + code-review feature, there's very limited value in spending time crafting good commit messages in a feature branch. All information that you may be tempted to put there would be more visible and more useful either as code comments (which applies to all projects, not just GH) or as comments in the PR description or discussion. (I also think it's often better to just squash feature branches on merge than to try to maintain a clean branch history while the feature is in development.)

    I do think that the commit messages that actually end up on your trunk are important; but, with the exception of the final PR merge (or squash) commit, developers should minimize the time spent writing or thinking about these commit messages.

    The one context in which I find details in historical commit messages potentially useful is when using git log -p to figure out when and why something changed. But even then, once I've found the relevant commit, looking up the PR to see if there was any discussion about the change in question is generally the next step; so again, having substantial detail in the commit message itself is unlikely to be helpful.

  • After seeing people use the UI to commit to git I understand where all those - sorry: shitty - commit messages come from....

    Jump

  • Why should I put manual effort into separately maintaining a changelog and a semantically meaningful commit history? If I'm going to manually maintain atomic commits with useful commit messages, why would I want the contents of those messages to be substantially different from the content of the relevant bullets of the changelog?

  • Rust is rolling off the Volvo assembly line - Blog - Tweede golf

    Jump

  • The O'Reilly book Programming Rust is very much targeted at C++ users, even if it isn't explicitly marketed that way.

    I read the first edition, which predated async Rust, so I can't comment on how the second edition handles that topic. But the handling of everything else was, I think, excellent.

  • If I had to use win 11, I'd become a monk

    Jump

  • 🤷 That wasn't my experience, and I used it as my primary dev environment for four years.

    It doesn't go through a translation layer, though. WSL 2 has a whole separate kernel. You can even use GUI apps with Wayland.

  • If I had to use win 11, I'd become a monk

    Jump

  • For what it's worth, WSL 2 with VSCode is actually great. Almost all the benefits of Linux (I still miss true tiling window management), with fewer weird driver issues.

    That said, I generally just use whatever my company wants me to use, and I haven't worked somewhere that let us use native Linux boxes since 2014.

  • Zig vs Rust. Which one is going to be future?

    Jump

  • Modev says they've been using C for 25 years, and used Rust for several years as well! Their whole schtick baffles me.

  • Zig vs Rust. Which one is going to be future?

    Jump

  • I also hope that some of the people reading this realize that OP is also the person posting all of the "stop trying to suppress C" posts.

  • Still relevant, just substitute for win 11

    Jump

  • Every technology that gets used frequently enough facilitates maladaptation to its faults. 😑

  • .dev It's time to return to the roots, to the C programming language.

    Jump

  • Rust feels like entirely the wrong target for that sort of criticism, especially regarding "energy and resource intensity". Rust is well-known to be comparable to C in its efficiency.

  • .dev It's time to return to the roots, to the C programming language.

    Jump

  • I haven't told you to keep calm. I'm just confused about you repeating the same points, in the same words, over and over, even after being told that you don't have your facts correct.

    I'm not saying you can't learn or talk about other languages; I'm confused by the mismatch between your posts criticizing people for promoting newer tech stacks and the ones where you seem to be promoting newer tech stacks yourself.

    25 years of experience is certainly enough to have strong opinions, but until your last comment I had the impression that you had a year or less of experience in C, hence my question.

  • .dev It's time to return to the roots, to the C programming language.

    Jump
    • Why do you keep posting the same rant about "going back to the roots", especially after multiple people have pointed out that C is not "the roots" of programming?
    • Why do you have such strong opinions about a language that you're still learning?
    • If you're that passionate about C and believe that people should use it instead of newer languages, why do you care about Nim or Nelua?

  • .dev Why is C hidden gold?

    Jump

  • .dev Why is C hidden gold?

    Jump

  • That's not a confession, it's a condemnation. It's not your fault that universities generally don't teach this stuff. (I think I had one lab session wherein we used valgrind.)

  • .dev It's time to return to the roots, to the C programming language.

    Jump

  • Why don't you answer any of my questions instead of telling me to join your club?

  • .dev It's time to return to the roots, to the C programming language.

    Jump

  • Wat