alwaysbeconsing

เมื่อวานdiscuss

> Andrew's job isn't to make a JS runtime

Most likely too late for edit, but Jarred is who work for Anthropic, not Andrew.

alwaysbeconsing

เมื่อวานdiscuss

> You can be reckless even if everything ends up being perfect in the end.

This. Something I expect any person who think they are "engineer" to understand without thinking.

alwaysbeconsing

เดือนที่แล้วdiscuss

Quite right. I bemoan shortsightedness of managerial types often, but too many fellow techies had assume that gravy ride will last forever. In eyes of management we have not the same leverage now.

alwaysbeconsing

4 เดือนที่ผ่านมาdiscuss

Competition. Using my open source projects directly doesn't kill my employment. AI company explicitly say they want to put me out of work, using my code aginst me.

alwaysbeconsing

5 เดือนที่ผ่านมาdiscuss

Problem come when a third-party code do that swizzling, looking at you every iOS analytics framework to this day.

alwaysbeconsing

2 ปีที่แล้วdiscuss

+1 Can see from project homepage http://web.archive.org/web/20240329165859/https://xz.tukaani... they have some release responsibility from 5.2.12.

> Versions 5.2.12, 5.4.3 and later have been signed with Jia Tan's OpenPGP key . The older releases have been signed with Lasse Collin's OpenPGP key .

It must be assume that before acquiring that privilege, they also contributed code to project. Probably most was to establish respectable record. Still could be malicious code going back someways.

alwaysbeconsing

3 ปีที่แล้วdiscuss

They seem to be specifically referring to the compiler error (as in, prevents compilation) for unused local variables. See discussion here: https://github.com/ziglang/zig/issues/335#issuecomment-10011...

alwaysbeconsing

3 ปีที่แล้วdiscuss

That's not a very big hurdle to overcome, though:

    print("{")
    contents = ""
    for elem in list:
      contents += '"key":  "value",'
    print(contents[:-1])
    print("}")

alwaysbeconsing

3 ปีที่แล้วdiscuss

One way to look at it (and I am not sure if this is correct, but it may be what the essay author meant) is to not treat the `unreachable` as affecting the presence of the decision, but only the result of the decision. If `unreachable` was replaced by a normal statement, we'd have:

    if (argc <= 2)
        do_something();
    else
        return printf("%s: we see %s", argv[0], argv[1]);

So the `return printf` is executed when `argc` is greater than 2. If we remove just the body of the first branch:

    if (argc <= 2)
        ;
    else
        return printf("%s: we see %s", argv[0], argv[1]);

the same thing holds. And additionally when `argc <= 2`, control will move past the `if`.

Under this view, if the `unreachable` won't cause the entire removal of the `if`, the compiler will produce the equivalent of:

    if (argc > 2)
        return printf("%s: we see %s", argv[0], argv[1]);

    return puts("this should never be reached")

Again, I don't say this is the correct interpretation, but it is one possibility, that would have to be ruled out by other parts of the standard.

comments