• 0 Posts
  • 49 Comments
Joined 3 years ago
cake
Cake day: July 1st, 2023

help-circle

  • fruitcantflytoCoding Cafepre-commit hooks are fundamentally broken
    link
    fedilink
    English
    arrow-up
    8
    ·
    edit-2
    15 days ago

    Most or all of these problems, and several more, are solved by using pre-commit. The author vaguely alludes to having had troubles with tools like this, but that has not been my experience.

    The problem with somebody bypassing the hooks (intentionally or unintentionally) is solved by running the hooks as part of your CI; if you don’t allow merges that fail these checks, then people can’t skip them. If you also squash merges as a rule, then every commit on your target branch will pass the checks

    EDIT: I’ll add that, IMO, hooks should never modify files. They should simply check that your code meets whatever requirements you want your code-base to meet


  • Well, maybe you’d better wait 10min instead of one, to make sure the led lightbulb heats enough, but still…

    I tested this with a 5W IKEA LED light-bulb, since I was just doom scrolling, anyway:

    • After 1 minute of being on, the bulb was still room temperature.
    • After 10 minutes of being on, the bulb was lukewarm.
    • After 10 minutes of being off, the bulb was room temperature, though the fitting maybe felt slightly warmer. That latter will probably depend on your installation, and how well it is able to disperse the heat.

    This means that the solution either breaks down entirely, or is unreliable, since you are not (reliably) able to tell the first two buttons apart




  • The problem is not the conclusion*. The problem is that the method used to reach it is terrible.

    As you say, you could look at license popularity on GitHub, and the author should have done something like that, but even those statistics have to be interpreted carefully:

    Each data point corresponds to the rank of a license based on the count of unique developers who uploaded code to a repository subject to the terms of that license during a given quarter.

    In other words, this measures how many developers are commiting code under each license, and thus is more of a reflection of the popularity of software under each license, rather than the licenses themselves.

    Perhaps a more meaningful measure would be how many (unique) repositories are created with each license, since a developer commiting code to a repo does not mean that they favor the license of that repo. I couldn’t find numbers for 2025, but amusingly these totals from 2020 suggest that no license is the most popular license, followed by MIT and then Apache

    * The majority of my own code is MIT, by a large margin-


  • The way to really optimize Python code, is by reducing the amount of Python code in your program, since Python itself is dog slow. Instead, you want to offload as much of the work as possible to modules written in compiled languages. So completely switching to Rust, or another compiled language, is simply taking that strategy to its logical conclusion



  • Loop labels are rare, but they lead to much simpler/clearer code when you need them. Consider how you would implement this kind of loop in a language without loop variables:

    'outer: while (...) {
        'inner: while (...) {
            if (...) {
                // this breaks out of the outer loop, not just the inner loop
                break 'outer;
            }
        }
    
        // some code here
    }
    

    In C/C++ you’d need to do something like

    bool condition = false;
    while (...) {
        while (...) {
            if (...) {
                condition = true;
                break;
            }
        }
        if (condition) {
            break;
        }
    
        // some code here
    }
    

    Personally, I wouldn’t call it ugly, either, but that’s mostly a matter of taste



  • In practice, type inference in Rust is not a problem since the language is so strongly typed. In fact, it is more strongly typed than both C and C++, and will force you to cast values explicitly in cases where C and C++ will happily mess up your variables without warning. The absence of type inference would also be a major pain, since nested types such as iterators can get quite complex and very verbose. If you’ve programmed using older C++ standards, then you know this pain


  • I believe that it is useful in a few places. cppreference.com mentions templates as one case:

    Trailing return type, useful if the return type depends on argument names, such as template<class T, class U> auto add(T t, U u) -> decltype(t + u); or is complicated, such as in auto fpif(int)->int(*)(int)

    The syntax also matches that of lambdas, though I’m not sure that adding another way of specifying regular functions actually makes the language more consistent, since most code still uses the old style.

    Additionally, the scope of the return type matches the function meaning that you can do

    auto my_class::my_function() -> iterator { /* code */ }
    

    instead of

    my_class::iterator my_class::my_function() { /* code */ }
    

    which is kinda nice


  • With Rust you safe 1 char, and gain needing to skip a whole line to see what type something is.

    Honestly, the Rust way of doing things feels much more natural to me.

    You can read it as

    1. Define a function,
    2. with the name getoffmylawn,
    3. that takes a Lawn argument named lawn,
    4. and returns a bool

    Whereas the C function is read as

    1. Do something with a bool? Could be a variable, could be a function, could be a forward declaration of a function,
    2. whatever it is, it has the name getoffmylawn,
    3. there’s a (, so all options are still on the table,
    4. ok, that’ a function, since it takes a Lawn argument named lawn, that returns a bool




  • The article is about an internal kernel API: They can easily rename those, since they are not exposed to user-space.

    But you seem to be talking about the kill command and/or the kill function, that are part of the POSIX and C standards, respectively. Renaming either would break a shit-ton of code, unless you merely aliased them. And while I agree that kill is a poor name, adding non-standard aliases doesn’t really offer much benefit