I personally factorize as soon as there are two copies, but do not hesitate to inline the code and redo the abstraction when there is a 3rd use if it doesn’t fit. I find it much easier to inline and re-abstact a bad abstraction, than check if two copies are indeed identical.

The exception is business logic. Usually I want all of them to be dupplicates because there is a very high chance that it’s just accidental that part of the logic is similar. I take great care to have good primitives but the actual business logic that glue those primitives together is written as many time as needed.

First experience with #jj #jujitsu

I tried the equivalent of git add -p (jj squash -i).

• I realize that it’s closer to git add --interactive (which I find much more complicated and less productive)
• I wasn’t able to edit a hunk (like the e key in git add -p) which I use a lot to split debug statements from real work

I generated a conflict (as I expected)

• I found no way to show the original diff
• jj undo did not worked (I have not been able to undo the jj squash that introduced the conflict

Very not impressed so far. Fortunately it was a test repo.

I never realised it was that simple to do. Thanks a lot to answer the OP question. I had the same for longer than I wish to admit given how easy the answer was!

I think you have a hard time understanding the différence between “not possible” and “much harder”.

In Rust, the code does not compile.

In C++ the code compile, but

• if you have a test case
• this test case triggers the bug (it is not guarateed to properly reproduce you production environment since it depends on the parameters of the allocator of your vector)
• you use ubsan

… then the bug will be caught.

Yes it is possible, noone says the opposite. But you can’t deny it’s harder. And because its harder, more bugs get past review, most notably security bugs as demonstrated again and again in many studies. The

That’s why I did not said it was impossible, just order of magnitude harder to catch in C++ compared to Rust.

To have asan finding the bug, you need to have a valid unit test, that has a similar enough workload. Otherwise you may not see the bug with asan if the vector doesn’t grow (and thus ref would still be valid, not triggering UB), leading to a production-only bug.

Asan is a wonderfull tool, but you can’t deny it’s much harder to use and much less reliable than just running your compiler.

void foo() {
    std::vector v = {0, 1, 2, 4};
    const auto& ref = v[1];
    add_missing_values(v);
    std::cout << ref << "\n";
}

void add_missing_values(std::vector<int>& v) {
    // ...
    v.push_back(3);
}

Neither foo(), nor add_missing_values() looks suspicious. Nonetheless, if v.push_back(3) requires v to grow, then ref becomes an invalid reference and std::cout << ref becomes UB (use after free). In Rust this would not compiles.

It is order of magnitudes easier to have lifetime errors in C++ than in Rust (use after free, double free, data races, use before initialisation, …)

Is it possible to do in Rust?

Yes

Is possible to do in Rust, by mistake, and not easily caught by a review?

Definitively not.

DRY and YAGNI are awesome iif you also practice YNIRN (You Need It Right Now)! Otherwise you just get boilerplate of spaghetti

You got me in the first 3 quarters, not gonna lie!

There are cases where instead of origin/master..HEAD you may want to use @{upstream}..HEAD instead to compare with the upstream of your current branch. It’s unfortunately quite unknown.

I absolutely agree that method extraction can be abused. One should not forget that locality is important. Functionnal idioms do help to minimise the layer of intermediate functions. Lamda/closure helps too by having the function much closer to its use site. And local variables can sometime be a better choice than having a function that return just an expression.

Good advice, clear, simple and to the point.

Stated otherwise: “whenever you need to add comments to an expression, try to use named intermediate variables, method or free function”.

I never understood why python won agaist ruby. I find ruby an even better executable pseudo code language than python.

Read your own code that you wrote a month ago. For every wtf moment, try to rewrite it in a clearer way. With time you will internalize what is or is not a good idea. Usually this means naming your constants, moving code inside function to have a friendly name that explain what this code does, or moving code out of a function because the abstraction you choose was not a good one. Since you have 10 years of experience it’s highly possible that you already do that, so just continue :)

If you are motivated I would advice to take a look to Rust. The goal is not really to be able to use it (even if it’s nice to be able able to write fast code to speed up your python), but the Rust compiler is like a very exigeant teacher that will not forgive any mistakes while explaining why it’s not a good idea to do that and what you should do instead. The quality of the errors are crutial, this is what will help you to undertand and improve over time. So consider Rust as an exercice to become a better python programmer. So whatever you try to do in Rust, try to understand how it applies to python. There are many tutorials online. The official book is a good start. And in general learning new languages with a very different paradigm is the best way to improve since it will help you to see stuff from a new angle.

I would have liked a link to the LKLM thread. Usually they are quite informative

I use a 42 key layout modified from bépo (french dvorak inspired layout) with the altgr layer of ergol. Go check this altgr layer it’s awesome for programming, and there is a version compatible for qwerty and lafayette.

╭╌╌╌╌╌┰─────┬─────┬─────┬─────┬─────┰─────┬─────┬─────┬─────┬─────┰╌╌╌╌╌┬╌╌╌╌╌╮
┆     ┃   ¹ │   ² │   ³ │   ⁴ │   ⁵ ┃   ⁶ │   ⁷ │   ⁸ │   ⁹ │   ⁰ ┃     ┆     ┆
┆     ┃   ₁ │   ₂ │   ₃ │   ₄ │   ₅ ┃   ₆ │   ₇ │   ₈ │   ₉ │   ₀ ┃     ┆     ┆
╰╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
·     ┃     │   ≤ │   ≥ │  *¤ │   ‰ ┃  *^ │     │   × │  *´ │  *` ┃     ┆     ┆
·     ┃   @ │   < │   > │   $ │   % ┃   ^ │   & │   * │   ' │   ` ┃     ┆     ┆
·     ┠─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
·     ┃     │   ⁽ │   ⁾ │     │   ≠ ┃  */ │   ± │   — │   ÷ │  *¨ ┃     ┆     ┆
·     ┃   { │   ( │   ) │   } │   = ┃   \ │   + │   - │   / │   " ┃     ┆     ┆
╭╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┴╌╌╌╌╌╯
┆     ┃  *~ │     │     │   – │     ┃   ¦ │   ¬ │  *¸ │     │     ┃           ·
┆     ┃   ~ │   [ │   ] │   _ │   # ┃   | │   ! │   ; │   : │   ? ┃           ·
╰╌╌╌╌╌┸─────┴─────┴─────┴─────┴─────┸─────┴─────┴─────┴─────┴─────┚ · · · · · ·

vim can have IDE-like capabilities thanks to lsp and tree-sitter. That’s a real game changer and is quite easy to set-up with something like kickstart.nvim.

If you have references explain why and how that it’s easier to port C to a new architecture by creating a new compiler from scratch than to either create a backend for llvm (and soon gcc) or to create a minimal wasm executor (like what zig is doing) to this new architecture I’m interested. And of course I talking about new architectures because it’s much easier to recreate something that as already be done before.

I’m not familiar with C tooling, but I have done multiple projects in C++ (in a professionnel environnement) and AFAIK the tooling is the same. Tooling to C++ is a nightmare, and that’s and understatement. Most of the difficulty is self inflicted like not using cmake/meson but a custom build system, relying on system library instead of using Conan or vcpkg, not using smart-pointers,… but adding basically anything (LSP, code coverage, a new dependency, clang-format, clang-tidy, …) is horrible in those environments. And if you compare the quality of those tools to the one of other language, they are not even close. For exemple the lint given by clang-tidy to the one of Rust clippy.

If it took no more than an hour to add any of those tools to a legacy C project, then yes it would be disingenuous to not compare C + tooling with Rust, but unfortunately it’s not.

With Bram Moolenaar death, I sincerely think that vim will no longer be able to play catch-up with nvim. Bram Moolenaar did an amazing job with nvim, but with its death I think that vim is going to be an editor of the past, just like vi is an editor of the past. And nvim is its successor since its where the developers have moved.