My interpretation is that as engineers, we attempt to justify all of our choices through purely rational means. However, as humans, we cannot really make said choices without also being at least somewhat influenced by our subjective affections.

Perhaps I'm stretching the author's message, but at least I believe that the argument extends to all engineering conclusions. The author's call is that we acknowledge this subjective side.

Essentially, true engineering is about tradeoffs, there is no X that is objectively better than Y in all circumstances and contexts.

> The author's call is that we acknowledge this subjective side.

I think that acknowledging the subjective side is a necessary step to making more rational choices. If you don't know your motivations, you will be a motivated reasoner.

When you can add "I like this tech because it helps me build an identity I aspire to" as an item in the pros column, you realize you no longer have to.

> When you can add "I like this tech because it helps me build an identity I aspire to" as an item in the pros column, you realize you no longer have to.

But, for many of the cases of using-obscure-thing-instead-of-popular-thing, that's not a factor.

Not everything divergent is hipster impulse. Nor is everything about slotting yourself into a clique category in high school.

Which is why I asked for clarification on what was being said.

FWIW, I use a vintage ThinkPad mainly because I can type all day on it without problem. The serviceability is also nice. I also own a sleek high-end last-year's P1 and an X1, both of which I think would look more attractive in cafes and in some ways fit my ideal self-image better than the T520 that I choose to use instead. Currently, due to the inferior keyboards, I might use the P1 or X1 only if I need to do a startup meeting with a 20-something who doesn't already know I'm good despite being over-30. That choice would be the image one, and it's not about validation or aspirational identity, but pragmatic gaining of acceptance despite prejudice.

Well, recursion is well-structured and can be reasoned about through induction. Goto is unstructured…

I don’t think I follow, do you mind giving a concrete example?

Basically, instead of faffing around with undefing values and including different files, you define your list like this:

    #define AN_X_LIST(X) \
        X(foo, bar) \
        X(bar, baz)

And then you use it like so:

    #define AN_ASSIGNMENT_STATEMENT(a,b) a = STRINGIFY(b);

And so

    AN_X_LIST(AN_ASSIGNMENT_STATEMENT)

Will expand to

    foo = "bar";
    bar = "baz";

The nice thing about this approach is you can define multiple lists and macros, and make higher order macros which use them. I have a system like this which allows me to define reflective structs in C++ easily, i.e. I define a struct like:

    #define STRUCT_FOO_LIST(X) \
       X(int, bar, 0), \
       X(float, baz, 4.0),
    DECLARE_REFLECTIVE_STRUCT(Foo, STRUCT_FOO_LIST);

(where DECLARE_REFLECTIVE_STRUCT basically just does the same dance as above with passing different per-element structs into the list that it is passed for the struct definition, and other utility functions associated with it)

which then makes a struct Foo with members bar and baz with the right types and default values, but also I can do 'foo_instance.fetch_variant("baz")' and other such operations.

The biggest pain with this approach is it's basically dealing with a bunch of multi-line macros, so it can get messy if there's a typo somewhere (and I strongly recommend an auto-formatter if you don't like having a ragged line of backslashes to the right of all the code that uses it).

_This_ is the best pattern for X macros, without any of that noise of undef'ing anything.

My approach is to wrap the list elements with two macros: an inner transformation one and an outer delimiter, like so:

    #define AN_X_LIST(X, DELIM)   \
       DELIM(X(int,         foo)) \
       DELIM(X(int,         bar)) \
             X(std::string, baz)

Then you can compose different pieces of code for different contexts by just swapping out the delimiter. A very contrived example:

    #define SEMICOLON(x) x;
    #define COMMA(x) x,
    
    #define DECLARE(type, var) type var
    #define INIT(type, var) var{}

    struct s {
      AN_X_LIST(DECLARE, SEMICOLON);
      
      s() AN_X_LIST(INIT, COMMA) {}
    };

Well the main point is that there are changes that for most languages would need a change in the compiler/interpreter itself. However in lisp those kinds of things can be done in userspace

I believe int[6] can still be passed to static 5 but I would have to double check

Looks fine to me

I like to wrap it in a venv (pure python project) or nix flake (mixed languages)

That seems to be about isolation, not about dependency management, right? I use Docker containers for that.

But my question was about dependency management.

Left leaning red black trees enforce extra constraints, which remove symmetries. This actually adds an edge case when instead you can just treat left/right rotations and comparisons as symmetric operations.

Left Leaning Red Black Trees Considerer Harmful: https://www.read.seas.harvard.edu/~kohler/notes/llrb.html

A follow up from the same author

https://blog.codinghorror.com/web-discussions-flat-by-design...

Interesting side note: the blog is generated with the C preprocessor

https://aartaka.me/this-post-is-cpp