If each transmitter picks up the rebroadcasts if its own signals, then with some assumptions about the rebroadcast lag (or measurements of it added to the signal!), that's enough to know the range to each other transmitter, right? So maybe they do that and then just broadcast the ranges (tagged on to their main signal), then any remote receiver can work it all out from there.

Turns out, it's fine! The photos aren't perfect, but no amount of editing could make them perfect anyway. They look like the thing they're a picture of. That does the job. And with the time i save by not doing any editing, i have time to take more photos! Or read a book! Or sleep!

The flip side of your example is that people see a function signature like getClosest, and think it's fine to call it many times with a set and a point, and now you're building a fresh quadtree on each call. Making the staging explicit steers them away from this.

1. Looking at a function call, you can't tell if it's returning data, or a function from some unknown number of arguments to data, without carefully examining both its declaration and its call site

2. Writing a function call, you can accidentally get a function rather than data if you leave off an argument; coupled with pervasive type inference, this can lead to some really tiresome compiler errors

3. Functions which return functions look just like functions which take more arguments and return data (card-carrying functional programmers might argue these are really the same thing, but semantically, they aren't at all - in what sense is make_string_comparator_for_locale "really" a function which takes a locale and a string and returns a function from string to ordering?)

3a. Because of point 3, our codebase has a trivial wrapper to put round functions when your function actually returns a function (so make_string_comparator_for_locale has type like Locale -> Function string -> order>), so now if you actually want to return a function, there's boilerplate at the return and call sites that wouldn't be there in a less 'concise' language!

I think programming languages have a tendency to pick up cute features that give you a little dopamine kick when you use them, but that aren't actually good for the health of a substantial codebase. I think academic and hobby languages, and so functional languages, are particularly prone to this. I think implicit currying is one of these features.

  let warn_user ~message = ... (* the ~ makes this a named parameter *)

  let error = "fatal error!!" in
  warn_user ~message:error; (* different names, have to specify both *)

  let message = "fatal error!!" in
  warn_user ~message; (* same names, elided *)

  let result = input
    |> add_prefix_and_suffix("They said '", $, "'!")

    {"GreaterOf": [
        {"Value": [0, "Dollar"]},
        {"Subtract": [
            {"Dependency": ["/totalTentativeTax"]},
            {"Dependency": ["/totalNonRefundableCredits"]}
        ]}
    ]}

    {"GreaterOf": [
        {"Value": {"value": 0, "kind": "Dollar"}},
        {"Subtract": {
            "minuend": {"Dependency": "/totalTentativeTax"},
            "subtrahend": {"Dependency": "/totalNonRefundableCredits"}
        }}
    ]}

https://zikman.audio/blog/cable-microphonics-what-it-is-and-...

Also sometimes called the stethoscope effect.

I think strictly speaking, this isn't actually microphonics, because that means that mechanical noise causes electrical noise, which then results in audible noise, whereas what is happening is just transmission of vibrations up the cable into the ear.

Anyway, it can be fixed with better cables. They don't have to be fancy (they don't have to be the 349 euro cables that site is selling!) - i have a pair of KZ ZS10 Pro X earphones, and using the stock cables, i don't get rustling through those.

(more generally, i have an embarrassing number of Chi-Fi earphones, and don't get rustling with any of them)

Now do breadth-first traversal. With the iterative approach, you just replace the stack with a queue. With the recursive approach, you have to make radical changes. You can make either approach look natural and elegant if you pick the right example.

Huh. Where i work, the main problem is that everyone is hell-bent on transforming every iterative function into a recursive function. If i had a pound for every recursive function called "loop" in the codebase, i could retire.

I'm using the past tense here, but VoltDB is still going. I don't think it's as well-known as it deserves to be.