mr_luc

Yes that feels like a good characterization.

Which, I would say, does seem a lot less black-and-white than the cell phone example, and anyone who thinks it's all settled now might be in for a surprise.

Above was a quote from Carpenter, and the Court seems to have called out that the completeness of the record meant it recorded them, 'not only in public thoroughfares', but also private homes and doctor's office and so forth.

It does seem like that's an element, then -- this is not to say that it's sufficient for anything, since obviously a sufficiently good record of where one goes on public thoroughfares would fail the same test ('reliably reveals that so-and-so went to visit a specialist doctor, divorce attorney, and brothel all on the same day')

I feel like you’re right, for instance depending on how you define the extra in extraterrestrial.

The space station, the Artemis capsule, microbes on interplanetary probes, etc.

It could technically be said in a sentence and be true, but it would be misleading to most people.

I'd be cautious for the same reason: thyroid cancers are also positively associated with obesity, and people who take GLP-1s are often obese.

Below a table, it says "adjusted for social deprivation index, hypo- and hyperthyroidism, and use of other antidiabetic drugs..." -- but nothing about obesity.

What if the GLP-1-prescribed patients tended to be more obese?

He’s 20, right?

Wait you have an API now??? Is it open, is there a waitlist? I’m on a plane but going to try to find that on the site. Absolutely loved your demo, been showing it around for a few months.

I’m surprised to find this on the 3rd or 4th page of Hacker News! It seems pretty impressive —- of course, the lack of code on GitHub might be partly responsible for that; there’s so much interesting AI stuff happening that an impressive page of results without either a detailed explanation, or an executable one, could easily fall through the cracks.

Me too! I came looking for this sort of meta-comment. I've re-read the paper book a few times now.

What makes it my favorite is how clear Norvig's writing is. It's easy to follow (both when reading it in English, and when following its execution if you're a programmer), and it introduces important ideas so effortlessly that, years later, it will give you a chuckle.

Anyone interested in clearly communicating about technical topics, and with a knowledge of Lisp's nature and some idea of what programming in 1991 looked like, might be tickled to read Chapter 1; even its first few paragraphs are refreshing.

I think RocketLab qualifies.

Cool -- not to pry, but I'd be interested in looking at that if it's public somewhere! Could update my intuition.

Oh, hey that's great! So in your case, you're re-using the Phoenix client, and thus the Phoenix protocol lives on so as not to break that. Makes sense.

Thanks for the answer -- the current SDUI renaissance is a beautiful thing. Cheers :)

Didn't mean to distract from the main discussion either -- pre-emption is something that more people should want, I think, so y'all making it the default for WASM stuff feels super valuable. And surely the sandboxing is really valuable to some people too. (But day-to-day I probably won't use Lunatic, whereas LiveView-based SDUI is my current shop-time project).

Ooh, LiveView pattern implementors! I have a question -- I've been tinkering with a custom Phoenix LV client in my 'shop time', so I wanted to ask: are you doing your diffs on a string-based representation, like they do in the internal Phoenix LV protocol? Or are you sending the DOM patches?

In the phx protocol, their diffs depend on having split the render into a tree of 'statics', 'dynamics', 'components', and on each change, that structure is patched, and needs to be recursively zipped to a string, parsed into a DOM, and patches computed against the previous DOM.

I've been playing with a new client as a way of understanding it, and it's definitely a certain amount of work! Fortunately computing 'what needs to change to reconcile 2 html-like DOMs' is a project that's been wrapped into libraries a few times in a few languages (phoenix relies on other people having done that too, via the 'morphdom' library in JS, and Dockyard recently open-sourced an ergonomic Rust library I'm using in my client).

So -- it's a lot of client work, but it optimizes for bandwidth. Cool.

But I've wondered if there could be any benefit to optimizing for granularity of patches, and simpler clients -- by sending 'just the patches', ie the list of DOM operations that cause the desired end state. My intuition is that the bandwidth 'cost' would be prohibitive, because the list of patches required to perform the morph could be quite large for a change that appears small in 'what string has changed' terms. (maybe harder to debug, too? lots of trade-offs)

I just don't have the energy to try it that way too, hehe, on the off chance that my intuition is off base and it'd actually help improve things (simpler clients, and maybe the bandwidth hit wouldn't be too bad?); it'd require deep server changes as well, when up until now I've only been writing a client. So I was curious what approach y'all are taking.

Prior/related art in the Rust space: I know there's a non-Phoenix liveview project, 'dioxus', with a generic DOM liveview implementation that several clients have been created for, by making a state machine that operates on that list of generated Patches; however I don't know what that one sends, whether DOM patches directly, or Phx-style diffs that need to go phxDiff -> zippedUpString -> dom -> morphPatches -> applyToDom.

I have a physical copy of this! My parents got it for me at a garage sale in the 80s when I was a little nipper.

It has a great programming language “tower of babel” illustration.

It wasn’t until years later that I realized it was a Soviet science ecosystem book. Some of the content should have been a giveaway …

from his twitter, he mentioned

    a special thanks to @whatyouhide for leading
    the release process while my arms are not 100%

so I don't think so!