I feel that the battle is already lost when we aren't arguing that the AI service must get a license from the copyright holder like everybody else, but instead just arguing how many crumbs is the AI service morally obliged to throw back.
Ridiculous. Next you're going to treat going to point A to B in a car the same way as walking. Why do you need a license to drive? You don't need a license to walk!
In fact, people had a reasonable expectation of privacy in public spaces before there were cameras everywhere.
I think it's delicious how nobody, absolutely nobody, wants _ to mean "emphasis," they want italics, and yet despite there being a markdown-to-HTML build step nobody has ever done what they were told they were supposed to do to circumvent the semantic issue and use <span class="italic"> instead of <em>.
It wouldn't even make sense for markdown if it were language-agnostic to output <em> when that's HTML-only.
I'm going to go to my grave repeating that <em> is just <i> version 2.
Totally fair. At least in part, I blame the choice of <em> and <strong>: it's really not clear what the hierarchy between them is, so I just think of them as the online versions of italic and bold.
<mild> and <strong>, or <em> and <emem> (or <double-em>, or <very-em>) might have been clearer, but at this point we'll never know.
<em> and <strong> were introduced as the supposedly semantic counterparts to the supposedly physical <i> and <b>. That never made a lot of sense, and then later <i> and <b> were redefined to be some subtly different semantic elements. Which also never really made sense. In the end, they both still mean italics and bold, unless you go out of your way to give them a different styling.
I would take these benchmarks with a pinch of salt. Within a single function, it's very easy to optimize JS because you know every way a single variable will be defined. When you have to call a function, the data type of the argument can be anything the caller passes to the function, which makes optimization far more complex.
In practice, WASM codebases won't be simply running a single pure function in WASM from JS but instead will have several data structures being passed around from one WASM function to another, and that's going to be faster than doing the same in JS.
By the way, if I remember correctly V8 can optimize function calls heuristically if every call always passes the same argument types, but because this is an implementation detail it's difficult to know what scenarios are actually optimized and which are not.
I'm not OP but I tried to ask it today to explain to me how proxies work, and it felt like it couldn't give me an answer that it couldn't attribute to a link. While that sounds good on paper, the problem is that no matter what you ask, you end up with very similar answers because it has less freedom to generate text. While on the other hand, even if attributes everything to a link, there is no guarantee that link actually says what the LLM is telling you it says, so it's just the worse of both worlds.
ChatGPT on the other hand was able to reformulate the explanation until I understood the part I was struggling with, namely what prevents a proxy from simply passing its own public key as the website's public key. It did so without citing anything.
Imagine if normal engineering did that. Engineers invent a "blobby" thing that glues things together. It has amazing properties that increase productivity but sometimes it just stops working for some reason and comes off. It's totally random and because of how blobby is produced there is no way to tell when it's going to work or not, contrary to the typical material. Anyway we're going to use blobby to build everything from schools, to bridges, to airplanes now.
