rerere can help, but OP probably has their own workflow

Why couldnt you flatten it?

You have three different value cases (main value, main Err case for `?` to consume, and whatever early-return case). And the `?` operator fully taking up the Err result case means your main-result+early-return values strictly must both be wrapped in an Ok.

swap with last element then truncate at the end

Yes, you can do this if you don't care about order, and avoid the performance degradation. But it's even more complex.

Or if you do care about order, you can emulate the C++ "erase-remove" idiom, by keeping track of separate "read" and "write" positions in the source, iterating until "read" reaches the end, and only incrementing "write" for elements that are kept; and then doing a single `del` of a slice at the end. But this, too, is complex to write, and very much the sort of thing one chooses Python in order to avoid. And you do all that work, in essence, just to emulate what the list comprehension does but in-place.

You can do the in place variant using generator comprehension and writing the result in place in the original vector. The generator should run ahead of the write and should work fine.

It will also probably be significantly slower than just copying the vector.

Well, it can make some chained function composition easier.

  Ick1 result1 = potentiallyNull1();
  Ick2 result2 = (result1 == null) ? null : potentiallyNull2(result1);
  Ick3 result3 = (result2 == null) ? null : potentiallyNull3(result2);

vs

  Ick3 result3 = potentiallyNone1()
    .flatMap(potentiallyNone2)
    .flatMap(potentiallyNone3);

You could maybe move the null check inside the method in the former and it cleans it up a bit, but in the latter you can have methods that are explicitly marked as taking NonNull in their type signature which is nice.

maybe it’s better now, but at last time I checked (~2 years ago) humans are still better in jargon heavy contexts - legal as you mentioned, tech/medical/etc. also accents, muffled audio, noise in general, humans are (were?) much better at accounting for that

Also: A STT algorithm can't be held accountable for any errors.

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