What I do mourn is the reliability. We're in this weird limbo where it's like rolling a die for every piece of work. If it comes up 1-5, I would have been better off implementing it myself. If it comes up 6, it'll get it done orders of magnitude faster than doing it by hand. Since the overall speedup is worthwhile, I have to try it every time, even if most of the time it fails. And of course it's a moving target, so I have to keep trying the things that failed yesterday because today's models are more capable.

Doing the verification after the execution tends to lead to “yeah this is good” when it really isn’t. Stuff like copilot annoyingly loves to change the tests so it can pass, rather than changing the implementation to make the tests pass. I wonder if their platform prevents that kind of thing.

Some differing interpretations of the law distinguish between the lawmakers' intention vs the literal meaning (and keep in mind that language itself changes a lot in just a few centuries. The hard problem is that, in PL terms, the law is written in syntax without agreed upon semantics. So a decent step could be just using some agreed upon semantics, like we do in code! Then at least "interpreting" it would be unambiguous.

Maybe a decent analogy would be gcc vs clang might produce different programs for certain undefined behavior, and different combinations of pieces might lead to different behavior too (like race conditions), and somebody (the plaintiff/user) is asking you (the judge/compiler) to decide what's going to happen in this next loop/program/whatever.

Or maybe a decent analogy would be getting a ticket that the API is erroring in some rare user's case and having to look into the code and stacktrace to realize it's some weird unanticipated interaction between two different pieces of legacy code (150 year old law) that now interact due to a recent merge (a new law from last year), and now it's crashing, so we have to figure out how to interpret/compile/resolve this user's case.

If law was usable like code, we'd never have any of those issues, just like we never have those issues with actual literal programs. And when we do, it's just because we're using the wrong language/aren't encoding enough things in the types and semantics/shouldn't have used this niche compiler so now let's get a new interpretation from another Supreme Compiler/etc. Life would be easier \s

So it's maybe more optimistic than you, in that the run/read time power (judicial) doesn't get diminished, but more pessimistic in that I believe it because I believe that changing the language from english law jargon to some formal language doesn't actually eliminate the issues it might be intended to eliminate.

The example I gave had a few pieces:

- x is defined prior to the if/else, and overwritten in just one branch - y is defined in both branches

So in the rest of the function, we have both x and y available, regardless of which branch is taken.

I just took a quick read of the context page and the context basics page, but it's still unclear to me whether you can program how scopes/contexts interact in rye.

In my example, we I'd say we have a few different scopes worth mentioning, and I'm curious how programmably we can make them interact in rye:

Scope 1. Right below the first x = ...: we have names available form and have x available as the ... stuff. Presumably the `foo` in `if foo` lives in this scope.

Scope 2T. Right after the true branch's y, we have scope 1 plus y introduced

Scope 2F. Right after the false branch's x and y, we have scope 1 plus x "pointing to" something new and y introduced.

Scope 3. Below the if/else, where lives. This is either scope 2T or scope 2F. x is either scope 1's x or scope 2F's x, and y is either scope 2T's y or 2F's y.

In the original articles language,

So the scope relationships in an if/else are a diamond DAG taking the names from before it, making them available in each branch's scopes, and then making a sorta disjoint union of the branch's names available afterwards. Could that be programmed in rye, to allow the kinds of naming ergonomics in my previous example, but with the if/else being programmable in the sense of the original article? I'm especially interested in whether we could overload it in the traditional autodiff sense.

Responding to a different part of your comment about using names rarely in rye, I've found that I benefit a ton from handing out names more than most people do in functional languages, just for clarity and more self-documenting code. Like, the ide can say "`apples` is broken" instead of "error in location xyz" and I can rebuild my mental state better too when revisiting code.

Consider this example

    
    x = ...
    if foo:
       y = ...
    else:
       x = ...
       y = ...
    

a) in each branch, we have everything in scope that comes from

b) in , we have everything in scope that was assigned or reassigned in the executed branch

I'd love a language that supports programmable stuff like if, since I'm tired of python autodiff not handling `if` and `for`. But it would really need programmable scope stuff to still allow the ergonomic "scope effects" that make `if` and `for` blocks ergonomic.

It's one of those languages where I'd love to see the mainstreamification of some of its ideas, but as is, it just seems too clunky.

What happened to "if you want it, then you have to pay for the privilege?" If you want to be sure you aren't next to a kid, just pay for a first class ticket, instead of making other people pay extra for your comfort. You knew your preferences when you bought the ticket, after all. Select the seat you find necessary. /s

The point being that the status quo rolls dice that make everyone unhappy, and there are options for everyone to avoid it by paying extra. Those options are priced by the people creating the situation in order to make a maximally profitable 'pay to avoid this' scenario. I always pay for my family to get together, but blame the airline for making you uncomfortable, not the family.

    p(both are girls | you're told at least one is a girl)
     = p(you're told at least one is a girl | both are girls) * p(both are girls) / (
            p(you're told at least one is a girl | both are girls) * p(both are girls)
            +
            p(you're told at least one is a girl | they aren't both girls) * p(they aren't both girls)
        )

This is the crux of the thing. Different readings of the setup imply different answers to p(what you're told | the unknowns).

It's also a great case of where bayes rule shorthands can be slippery. You'll usually abbreviate it out (hell, it was tedious to write this way even with copy-paste). But if you abbreviate "you're told there's at least one girl" to "there's at least one girl", then you've stopped modeling a crucial part of the setup. p(there's at least one girl | they aren't both girls) has an unambiguous answer.

[0] https://anggtwu.net/tmp/nederpelt_geuvers__type_theory_and_f...

[0] https://emilien.ca/Notes/Notes/notes/1904.02990v4.pdf

It seems like if you think AI could have moral status in the future, are trying to build general AI, and have no idea how to tell when it has moral status, you ought to start thinking about it and learning how to navigate it. This whole post is couched in so much language of uncertainty and experimentation, it seems clear that they're just trying to start wrapping their heads around it and getting some practice thinking and acting on it, which seems reasonable?

Personally, I wouldn't be all that surprised if we start seeing AI that's person-ey enough to reasonable people question moral status in the next decade, and if so, that Anthropic might still be around to have to navigate it as an org.

But I can't imagine companies going for that. Everyone seems to want to scale the profits but not accept the consequences of the scaled risks, and increased risks is basically what working a third as well amounts to.