https://www.orwellfoundation.com/the-orwell-foundation/orwel...

(I'm guessing Zinsser's comments are from "On Writing Well", which you can also find online even though it is still under copyright.)

It's a bit of a pet peeve when people include quotes on a blog post without linking or otherwise references their source.

atproto.com contains a succinct discription:

> Atproto is a big-world open social protocol. Users publish JSON records into repositories. The changestreams of those records then sync across the network to drive applications.

Still a bit abstract, but OK. Personally I would include that AT protocol stands for Authenticated Transfer Protocol and that it is the protocol powering Bluesky.

> We unknowingly gave particularly high rewards for metaphors with creatures

It was the human feedback that caused the bias, not a change in training data.

I never made that claim. I just said it's way too early to rule it out: there is no logical reason why AIs will (always) need to have a human in the loop, and we don't have enough experience with LLMs to know what their true limits are.

I referenced AlphaGo not because the game of Go is exactly like every other task AI might perform in the future, but because the evolution from AlphaGo (which was trained on human games) to AlphaGo Zero (which was not) shows that at least in certain domains, it's not only possible to take the human out of the loop, it can actually make AI perform better.

I'm not claiming this will definitely be possible in every other domain, but people who state it definitely won't be, are jumping the gun.

> We find that _indiscriminate_ use of model-generated content in training causes irreversible defects in the resulting models

If you view AI training as lossy compression of their training data, then lossily compressing the same data repeatedly will result in data degredation; this is well known from other domains (try repeatedly compressing a JPEG image, for example).

That means it's extremely important that there is some content curation in the loop. But there is no reason to believe this content curation must be done by humans, or that it must exclude all AI-generated content by default.

For example, the recent LLM-generated disproof of the Jacobian conjecture would probably be beneficial to include in the training data, despite being the result of an LLM.

This is asserted without evidence. There is absolutely no proof that AI requires humans in the loop to function or improve itself.

Compare it with Deepmind's go-playing program, AlphaGo, which mainly involved training a neural network on a large database of high-level human games. It defeated one of the top-ranked players in the world, Lee Sedol, but arguably it was drawing from human experience just like you described.

But it didn't stop there. After that, Deepmind developed AlphaGo Zero, a version that was trained exclusively through self-play, with no human feedback in the loop. That's what you would call "AI inputs coming from AI outputs" but it didn't have the result of “resulting in delirium”: instead, it became orders of magnitudes stronger than the original version (which it defeated in a 100 to 0 competition after 3 days of training).

This shows that AI can improve itself without having access to any human knowledge, and indeed transcend human performance by orders of magnitudes. There is absolutely nothing to suggest that general AI cannot improve itself the same way.

People who claim otherwise are engaging in wishful thinking; they just assert their conclusion, but have no rational arguments to back it up.

For example, here is a typical use of a lambda expression to filter a vector of values:

    #include 
    #include 

    int main() {
        std::vector v = {3, 1, 4, 1, 5, 9, 2, 6, 5};

        int threshold = 5;
        std::erase_if(v, [&](int i) { return i < threshold; });

        // prints 5 9 6 5
        for (int i : v) std::cout << i << '\n';
    }

        ...
        int threshold = 5;
        struct lambda_t {
            int &threshold;
            bool operator()(int i) {
                return i < threshold;
            }
        };
        std::erase_if(v, lambda_t{threshold});
        ...

The important takeaway is that every lambda expression corresponds with a unique type that is _not_ a function type, but a class type. Consequently, lambda expressions can only be passed to template functions like std::erase_if, which are parameterized with the callback type.

You cannot pass a lambda expression to a function that expects a function pointer (e.g. bool(*)(int) in this example), and that's where they differ from GCC-style nested functions, which actually behave like functions. It also explains why lambda expressions don't need a trampoline.

As an aside, you _can_ pass lambdas to non-generic functions using a type-erasing wrapper like std::function, but std::function is itself a class type too, so that still doesn't allow you to convert it to a plain function pointer.

Finally, you can of course assign a name to a lambda expression value, using this common pattern:

    auto greet = [](const char *name) { std::cout << "Hello " << name << "!\n"; }
    greet("Alice");
    greet("Bob");

This is the closest you can get to a local function definition in C++. Admittedly the syntax is a little odd. You might wonder why there wasn't some additional syntactic sugar to make the definition look more normal. I suspect that wasn't a random decision, but rather intentionally avoiding conflicts with existing language extensions like GCC's local function syntax.

For the capturing case: to access context that is not available through global variables or function arguments, i.e., the same reason why closures are useful in other languages.

Here's an example, where I have a list of points that I want to sort based on distance to a chosen target point. I can use qsort() which takes an arbitrary comparison function, but has no way to provide context to that function beyond the input arguments:

    #include 
    #include 

    int main() {
        struct Point {
            int x, y;
        } points[3] = {
            { 3, 1 },
            { 2, 2 },
            { 5, 7 } };

        struct Point target = { 4, 5 };

        long dsq(const struct Point *p) {
            long dx = p->x - target.x, dy = p->y - target.y;
            return dx*dx + dy*dy;
        }

        int compare(const void *p, const void *q) {
            long a = dsq(p), b = dsq(q);
            return (a > b) - (a < b);
        }

        qsort(points, 3, sizeof(struct Point), compare);

        for (int i = 0; i < 3; ++i) {
            printf("%d,%d\n", points[i].x, points[i].y);
        }
    }

The usual workaround in standard C is to pass the necessary context as a function argument. That's why qsort_r() exists, which takes a context argument to be passed to compare(), but that's a non-standard GNU extension.

This practice of passing context pointers around is ubiquitous in C code, and it works, but it can get messy especially if you need access to multiple variables or variables from more than one nested scope. There is also a type safety issue: these context pointers are necessarily passed as void* which means they have to be cast back to the real type before use, which is where bugs can be introduced if the caller and receiver disagree on the actual type.

That being said, SDL isn't actually that bad either. A minimal example is about 40 lines of code [1], not counting comments and blank lines, but including lines with just a curly brace which you could easily remove if you were concerned about size. A slightly more serious implementation of Snake runs about 345 lines of code [2].

And to be fair, DONKEY.BAS is also cheating slightly on the line metric by stuffing lines full of statements, like for example:

    A$=INKEY$:IF A$=CHR$(27) THEN 1298 ELSE POKE 106,0:IF LEN(A$)>0 THEN LINE (CX,CY)-(CX+28,CY+44),0,BF:CX=252-CX:PUT (CX,CY),CAR%,PRESET:SOUND 200,1

I agree with you though, it's obnoxious to share paywalled articles on Hacker News.

Note that there is an intrinsic trade-off between minimizing file sizes and making access efficient. Something like delta-encoding is highly efficient but makes efficient access impossible.

Most file formats are designed with the assumption that line number information will only be needed rarely (e.g. when explicitly breaking into a debugger, or annotating a backtrace in case of a crash) so they prioritize simplicity and compactness over efficient access.

Gee whiz what an interesting way of thinking.

https://www.smbc-comics.com/comic/aaaah

If the price is expected to fall over time, then the negotiated price is below market at the beginning and above market at the end. From the suppliers view, they take a loss in the early years that they recover later.

Apple probably pays a premium to shift this risk to the supplier. Besides that they don't take a loss just because prices tend to fall. They only lose if market prices fall more steeply than expected.

Since LLM are inherently token predictors, that makes using them for losless compression almost trivial. For something close to the state of the art see e.g. Fabrice Bellard (of course) ts_zip: https://bellard.org/ts_zip/

I think some of the confusion comes from the fact that there is a pretty big difference between the techniques employed by compressors that optimize compression ratio at the cost of nearly everything else, like ts_zip above, and practical tools that intend to balance compression ratio with limitation on CPU speed / memory, like zstd.

When optimizing for compression ratio, the prediction + entropy coding paradigm dominates. Practical tools, even modern ones like zstd, are mostly based around sliding window compression à la LZ77 (unzip/deflate), with the main selling point of more modern tools being that they scale up to larger window sizes and run really really fast. Some of these (like LZO) don't even have an entropy coding step to save time. zstd has both Huffman coding and FSE: Huffman coding is suboptimal but presumably it's an option because it's faster, and on lower compression levels it's preferable to be fast.

Anyway, the bottom line is: don't get confused between the state of the art in terms of compression ratio, and practical tools. Those are quite different things.

> the 3-30-300 test — a standard that has become the go-to for solving a universal urban problem

> 3-30-300 is a catchy, straightforward test that sets a clear benchmark for measuring equal access to nature.

> I found that my closest park isn't 300 metres away, it's 400 metres. That's close, but a fail.

It's a standard. It's a benchmark. And a park at 400 metres is no good; it must be 300 metres or else it may as well be 4 kilometers away. This isn't treating the test as a useful guidance, but as a hard target. As Goodheart's law states: when a measure becomes a target, it ceases to be a good measure.

When you focus exclusively on satisfying such metrics, you can end up with ineffective policy. Missing the forest for the trees, if you will.

But unfortunately I'm not a professional footballer _or_ a fictional character in a Henry James novel (though I looked up the reference and it's close!)