nitnelave's comments

On: Use the Mikado Method to do safe changes in a complex codebase

[nitnelave]

Also known as "Make the change easy, then make the change"

Something to realize is that every codebase is legacy. My best new feature implementations are always several commits that do no-op refactorings, with no changes to tests even with good coverage (or adding tests before the refactoring for better coverage), then one short and sweet commit with just the behavior change.

[collingreen → nitnelave]

I also do this and try to teach it to others. One thing I add is trying to go even further and making it so the new feature can essentially be a configuration change (because you built the system already in the first steps). It doesn't fit every situation so it's by no means a hard rule but "prefer declaration functionality over imperative".

[hinkley → nitnelave]

That’s just mostly refactoring in general.

Mikado is more of a get out of jail card for getting trapped in a “top down refactor” which is an oxymoron.

On: Using go fix to modernize Go code

[nitnelave]

Rust has clippy nagging you with a bunch of modernity fixes, and sometimes it can autofix them. I learned about a lot of small new features that make the code cleaner through clippy.

On: Clean Coder: The Dark Path (2017)

[nitnelave]

Isn't that the classic argument "Real C programmers don't write defaults!" ?

The one that companies have spent billions of dollars fixing, including creating new restrictive languages?

I mean, I get the point of tests, but if your language obviates the need for some tests, it's a win for everyone. And as for the "how much code will I need to change to propagate this null?", the type system will tell you all the places where it might have an impact; once it compiles again, you can be fairly sure that you handled it in every place.

On: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

[nitnelave]

Client-side pre-commit hooks are there to help you in the same way that type checking (or a powerful compiler) is there to help you avoid bugs. In particular with git, you can skip the hooks when committing.

Now, if the server enforces checks on push, that's a project policy that should be respected.

[sa46 → nitnelave]

The problem is that pre-commit hooks are much slower with a much higher false-positive rate than type checking.

Pre-commit checks should be opt-in with CI as the gate. It's useful to be able to commit code in a failing state.

[chippiewill → sa46]

No one forces you to install the pre-commit hook on your local checkout so what you're suggesting is universally the case. You're perfectly free to just run it manually or let it fail in CI or use `--no-verify` when committing to skip the hook if you install it.

On: Tomo: A statically typed, imperative language that cross-compiles to C [video]

[nitnelave]

For CLI arguments, have you checked out clap? It's declarative (you create and annotate a struct, it generates the parser), and can be agremented with man page generation or shell completion generation.

And as a result of the parsing step, you get a fully typed struct

On: List animals until failure

[nitnelave]

I added "kudu", a type of antilope, and it replaced it with "turtle". I don't know the relationship between the 2, but it doesn't pass a toddler's sniff test!

[yorwba → nitnelave]

It's a bug with the way this disambiguation page is interpreted: https://en.wikipedia.org/wiki/Kudu_(disambiguation)

On: LaTeX Coffee Stains (2021) [pdf]

[nitnelave]

You need to go all-in on tea and make your own mark. Get a fancy Chinese teapot with holes in the spout to use loose leaf tea, and start getting snobby about traditional vs modern techniques of Pu'er tea, and you'll get your own brand of respect!

On: My favourite small hash table

[nitnelave]

The alignment constraint is different, which they use to be able to load both as a 64-bit integer and compare to 0 (the empty slot).

You could work around that with a union or casts with explicit alignment constraints, but this is the shortest way to express that.

[Asooka → nitnelave]

In that case you can use bit fields in a union:

    union slot {
        uint64_t keyvalue;
        struct {
            uint64_t key: 32;
            uint64_t value: 32;
        };
    };

Since both members of the union are effectively the exact same type, there is no issue. C99: "If the member used to access the contents of a union is not the same as the member last used to store a value, the object representation of the value that was stored is reinterpreted as an object representation of the new type". Meaning, you can initialise keyvalue and that will initialise both key and value, so writing "union slot s{0}" initialises everything to 0. One issue is that the exact layout for bit fields is implementation defined, so if you absolutely need to know where key and value are in memory, you will have to read GCC's manual (or just experiment). Another is that you cannot take the address of key or value individually, but if your code was already using uint64_t, you probably don't need to.

Edit: Note also that you can cast a pointer to slot to a pointer to uint64_t and that does not break strict aliasing rules.

[nitnelave → Asooka]

You can probably get away with just a union between a 64 bit and 2 32 bit integers.

[crest → nitnelave]

C has finally gained `alignas` so you can avoid the union hack or you could just rely on malloc to alway return the maximum alignment anyway.

On: The fate of "small" open source

[nitnelave]

I think it's a reference to the Google interview problem that the author of Homebrew (IIRC) failed. They were quite upset about it since they have proved their worth through their famous open-source contributions, but got rejected in a LeetCode-like interview.

On: Free software scares normal people

[nitnelave]

That's broadly the same reason I created LLDAP. It's the 20% of features of an LDAP server that 80% of users need.

It's been hard pushing back and saying no to all the new features. We've started work on a plugin API so that people can add features and opt in to the complexity.