- UkvAutonomous vehicles should be on the road iff they reduce overall incidents/deaths. Failure to deal with an out-of-distribution scenario would count against this, but may be rare enough to not significantly affect the average.
- I don't feel NFTs ever really had much interest among the general public - average reaction just being "I don't get it, that sounds pointless".
Whereas AI seemed to have a pretty good run for around a decade, with lots of positive press around breakthroughs and genuine interest if you showed someone AI Dungeon, DALL-E 2, etc. before it split into polarized topic.
- > [...] Finally, most important of all, did you have fun? The answer to all of these questions is "no".
Exploring the possibilities and limitations of a new technology is fun.
Obviously this is just a quick experiment lacking a whole lot you'd expect from a regular game, but there's also a lot to be curious about and different directions it could be taken in. With a harness could it generate a background, sprites, and collision mask so the player/NPCs can walk around in real-time? Could you limit commands from the player to reasonable actions ("I attempt to kick down the door") without the full god-mode world control? Or alternatively, could you allow a player to act as god of the world dictating changes, with NPCs or other players living within it (like as a tool for DnD)?
> why not just play an actual Legend of Zelda game? They exist. They are good.
One of their posts under "Latest" at the bottom is "Things I appreciate about Ocarina of Time", so presumably they have. Playing a game doesn't mean you can't also play around with experiments like this.
- Given the chain was:
> > Using a random UUID as primary key does not mean users have to memorize that UUID. [...]
> So what is such an identifier for? [...] Why bother with UUID at all then for internal identifiers?
The context, that you're questioning what they're useful for if not for use by the user, suggests that "internal" means the complement. That is, IDs used by your company and software, and maybe even API calls the website makes, but not anything the user has to know.
Otherwise, if "internal" was intended to mean something stricter (only used by a single non-distributed database, not accessed by any applications using the database, and never will be in the future), then my response is just that many IDs are neither internal in this sense nor intended to be memorized/saved by the user.
- UUIDs are good for creating entries concurrently where coordinating between distributed systems may be difficult.
May also be that you don't want to leak information like how many orders are being made, as could be inferred from a `/fetch_order?id=123` API with sequential IDs.
Sequential primary keys are still commonly used though - it's a scenario-dependant trade-off.
- > Stripping information from an identifier disconnects a piece of data from the real world which means we no longer can match them. But such connection is the sole purpose of keeping the data in the first place.
The identifier is still connected to the user's data, just through the appropriate other fields in the table as opposed to embedded into the identifier itself.
> So, what happens next is that the real world tries to adjust and the "data-less" identifier becomes a real world artifact. The situation becomes the same but worse (eg. you don't exist if you don't remember your social security id). In extreme cases people are tattooed with their numbers.
Using a random UUID as primary key does not mean users have to memorize that UUID. In fact in most cases I don't think there's much reason for it to even be exposed to the user at all.
You can still look up their data from their current email or phone number, for instance. Indexes are not limited to the primary key.
> The solution is not to come up with yet another artificial identifier but to come up with better means of identification taking into account the fact that things change.
A fully random primary key takes into account that things change - since it's not embedding any real-world information. That said I also don't think there's much issue with embedding creation time in the UUID for performance reasons, as the article is suggesting.
- I feel lying implies intent, and that the "appears to be accurate or plausible" only means on a superficial level.
- > By design, this is all it is capable of doing. Assuming a finite, inanimate computer can produce AGI is [...]
Humans are also made up of a finite number of tiny particles moving around that would, on their own, not be considered living or intelligent.
> [...] we have yet to produce a logical definition of "intelligence". Of all people, programmers should understand that you can't program something that is not defined.
There are multiple definitions of intelligence, some mathematically formalized, usually centered around reasoning and adapting to new challenges.
There are also a variety of definitions for what makes an application "accessible", most not super precise, but that doesn't prevent me improving the application in ways such that it gradually meets more and more people's definitions of accessible.
- The article doesn't say anything along those lines as far as I can tell - it focuses on scaling laws and diminishing returns ("If you want to get linear improvements, you need exponential resources").
I generally agree with the article's point, though I think "Will Never Happen" is too strong of a conclusion, whereas I don't think the idea that simple components ("a box of inanimate binary switches") fundamentally cannot combine to produce complex behaviour is well-founded.
- The index_tiled.html version correctly positions the original assets, and to me looks as close as you can get to the screenshot while using the original assets (except for the red text).
The version with the screenshot as a background is where it was asked to create an exact match for screenshot that had been scaled/compressed, which isn't really possible any other way. The article acknowledges this one as cheating.
Better I think would've been to retake the screenshot without the scaling/compression, to see if it can create a site that is both an exact match and using the original assets.
- > I'm really struggling to believe that anyone would consider this a "coding success".
The index_tiled.html version later in the article is what justifies the success claim IMO, and is the version I think it would've made more sense to host.
The currently hosted index.html just feels like a consequence of the author taking a scaled/compressed screenshot and asking Claude to produce an exact match.
- From the article, Claude asked:
> The screenshot shows viewport-specific positioning - should we match at a specific viewport size or make it responsive?
And the author responded:
> exact screenshot dimensions
So it's only intended to replicate the screenshot, but I do agree that making it center/zoom properly would've been more interesting.
- index_tiled.html is what justifies the title IMO - it's not using a screenshot as the background like index.html, and is as close as you can get using the original assets given the screenshot's scaling and compression artifacts (minus the red text being off).
But I feel it'd make more sense to just retake the screenshot properly and see if it can create a pixel-perfect replica.
- Agree that's a better intuition, with pretraining pushing the model towards saying "I don't know" in the kinds of situations where people write that as opposed to by introspection of its own confidence.
- > can you confidently classify all mental activity that you experience as "predicting the next thing"? [...] On what do you base your confidence in their equivalence?
To my understanding, bloaf's claim was only that the ability to predict seems a requirement of acting intentionally and thus that LLMs may "end up being a component in a system which actually does think" - not necessarily that all thought is prediction or that an LLM would be the entire system.
I'd personally go further and claim that correctly generating the next token is already a sufficiently general task to embed pretty much any intellectual capability. To complete `2360 + 8352 * 4 = ` for unseen problems is to be capable of arithmetic, for instance.
- > Spoken Query Language? Just like SQL, but for unstructured blobs of text as a database and unstructured language as a query?
I feel that's more a description of a search engine. Doesn't really give an intuition of why LLMs can do the things they do (beyond retrieval), or where/why they'll fail.
- I'm not convinced that "It's just a bag of words" would do much to sway someone who is overestimating an LLM's abilities. Feels too abstract/disconnected from what their experience using the LLM will be that it'll just sound obviously mistaken.
- It's not clear to me that it "changed things in important ways" in this case if a call alleging serious damage to the rail would've similarly triggered a pause for inspection.
- > Build failures from this change will typically look like "some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified"
Given this breaking change is known and understood in advance, and 1.5% of Rust projects still sounds like quite a lot to be affected, I feel the error could be specialized into something more useful/correct - suggesting to update their dependency on libc, or temporarily downgrade to Rust 1.92 (since upgrading may be out of their hands if it's a transitive dependency).
Though I guess most will search the error message and find the same advice either way.
- I don't think those performance concerns are really much of an issue with any sensible implementation. You'd do line of sight checks against simplified geometry first to handle the vast majority of cases, and you'd load character models/textures in advance (game/match startup) rather than only when they first appear on screen.
One non-trivial part seems to me that if you walk around a corner you don't want to wait 50ms (your ping) for the server to send enemy locations you can now see. Ideally every tick the server would be sending all enemies that you could potentially see before the next tick depending on what your movement packets that it hasn't yet received turn out to be. Wouldn't entirely eliminate advantage from cheating (e.g: a cheater walking around a corner could still see enemies up to a tick/~15ms in advance) but would hopefully make this form of cheating significantly less worthwhile.