Re; adverbs in parsers, I believe Infocom’s goal was to create puzzles that relied on adverbs to solve, such as >OPEN DOOR QUIETLY
to prevent the rusty hinge’s squeak from alerting the guard. (This paper lists five adverbs the parser recognized: CAREFULLY
, QUIETLY
, SLOWLY
, QUICKLY
, and BRIEFLY
.)
Right. And that’s aggravating, regardless of what’s running on the back end.
The point I’m trying to make is that people generally look at this problem and think the solution is to have a UI (parser, interpreter, whatever) that is bigger, wider, more complicated, more expressive, whatever. And that might work better for totally new users with absolutely no experience with the interface. But outside of that, and a couple of other corner cases, the opposite is usually true: people typically want terse, well-defined interfaces. In the sense that that’s actually how most users tend to behave, regardless of how they might respond to queries about their preferences.
Like at a fast food drive-thru window, you theoretically have at your disposal the entire power of whatever language(s) you happen to share with the person working the register. But what most people tend to actually use is a fairly sparse vocabulary, simplistic syntax, and so on. Because they’re actually prioritizing being understood and getting what they want over an abstract desire for expressiveness. Even when the other end of the communication is an actual literal human who is much more proficient at natural language processing than most UIs, even those featuring “AI”.
This seems like the worst of both worlds unless you’re really, really, really good at hinting which adverbs are usable, and where.
That’s probably why it didn’t take. But (in Infocom’s instance, at least), adverb support wasn’t added merely to permit florid input from the player.
This is completely anecdotal, and names have been redacted to protect the innocent and otherwise, but this recent conversation was oddly pertinent to this discussion:
The sentiment at the end is probably the best to remember; there is no wrong way to eat an interactive fiction.
Yeah, in general programming (and specifically network programming) there’s an idea called the Postel principle which is basically that you should be broad in what you accept and narrow in what you produce. So accept multiple variant input forms, but always produce the same output form consistently.
I think that’s a pretty good principle in general, although I think the Infocom adverbs thing is a pretty good counterexample: if adverbs only matter for one puzzle, then you’re probably going to end up with a lot of players getting stuck (because they got trained out of using adverbs by all the situations where they don’t matter), or you’re going have a lot of players wasting time experimenting with them to no effect.
I think Deadline, a game I quite like, is also guilty of this sort of thing, with >SEARCH NEAR (something)
being helpfully suggested in Appendix B of the manual. But since it’s important in, as I recall, exactly one puzzle, I imagine the length of time between when a player reads the manual and when they encounter the puzzle is a good predictor of how much trouble they’ll have with that puzzle.
Omg there’s a word for this idea.
IIRC, I tried searching near everything until I found the right spot, which isn’t ideal, either (I love Deadline).
Grim Fandango (another game I like) is the one that got me the worst that way. In most cases the interface semantics allow you to use the same key for almost all interactions, including, importantly, taking takeable objects. And then there’s one object where you can’t do this, and have to use the dedicated “pick up” key…which allows you to pick up but not put into your inventory the required object.
And then, having been burned by this, I spent the rest of the game wasting time always trying the “pick up” key on everything even though I think there’s only one other place where you have to use it.
Like at a fast food drive-thru window, you theoretically have at your disposal the entire power of whatever language(s) you happen to share with the person working the register. But what most people tend to actually use is a fairly sparse vocabulary, simplistic syntax, and so on.
I’ll take a Double Triple Bossy Deluxe, on a raft, four-by-four animal-style, extra shingles with a shimmy and a squeeze, light axle grease, make it cry, burn it, and let it swim.
Waffle House has a lot of unique lingo for ordering. I know a few terms, but I don’t know of a comprehensive reference.
AI could also be used for translating a game and commands to another spoken language directly while playing. Should be a lot better than Google Translate (unless it now includes AI so it may have improved). Chat GPT was pretty good at Danish when I tried communicating with it in Danish.
Hey, that’s interesting! Because it’s pretty widely acknowledged that the Postel principle is a very bad idea for network protocols in the long run (you end up vastly increasing the implementation effort because everybody has to deal with every horrible buggy implementation ever made, for not a lot of value), but I think it actually makes a lot of sense for computers communicating with humans instead of with other computers…
Pretty much all machine translation apps these days, including Google Translate, do use machine learning technologies that incorporate some of the statistical “how likely is this word to come after that word” stuff that large language models like ChatGPT run on. But for translation purposes, that’s not always actually a good thing, because if the text it’s translating contains statistically-unlikely combinations, it may or may not totally rewrite those into something that appears more often in its training data (here’s an example). And if it can’t make a chunk of text into something sufficiently plausible-sounding, it will just leave it out entirely. Either of those things would be pretty terrible for the IF-playing experience.
So basically, the ability to produce grammatically correct, plausible-sounding text in a given language is not the same as the ability to accurately translate from one language to the other, and machine learning technologies have made machine translators better at the former at the expense of making them slightly worse at the latter (or at least a different kind of bad than they used to be, and one that’s harder to notice if you don’t speak both languages yourself).
I think it’s more that the understanding of the bounds of acceptability have evolved. Circa January 1980, when RFC 761 was first presented, interoperability at all was a huge win, and so being aggressively permissive was not only not a vary bad idea, it was probably essential…it’s unlikely that TCP/IP would’ve become the dominant protocol, or the internet the dominant network, without it. Remember that the thing it was the alternative to was a bunch of wildly heterogeneous ad-hoc networks, not some other competing standard.
Much later, as the number of hosts grew (and as the number of competing architectures multiplied) the scope of the problem(s) also grew, and I think there was a period there where it was common to use the Postel principle as a kinda excuse for sloppiness. And then as network speeds and host counts increased by orders of magnitude again then a lot of the early decisions—made back when the internet was around a hundred hosts and like 90% of traffic was going through ucbvax—suddenly started looking non-optimal.
But I don’t think you get from the first situation to the second at all without something like the Postel principle.
I also think it’s an important thing to keep in mind in general, as we tend to make bad assumptions about data. Like there’s the famous essay about all the bad assumptions programmers make about what a person’s name (or address, or phone number, or postal code) looks like, but we tend to do that for all data.
It’s been interesting to watch this go down. Google Translate is generally accepted with an attitude of “It’s useful, even vital, but you can’t trust it”. That’s how I use it, certainly. Everyone knows that it can give bad translations, and you allow for that.
LLM-powered search tools are untrustworthy for exactly the same reason, but nobody’s cutting them any slack. I mean, except for the people extolling them as the new liberation of humanity – and those people come off as idiots. Microsoft’s and Google’s AI-powered search immediately got labelled as pathological liars. I don’t expect they’re going to shake that off.
What’s the difference? I think there is a genuine difference, but it’s hard to pin down.
I don’t know if we’ve got a term of art for it yet, but I think it’s because people appear to be imputing agency to LLMs in a way they don’t to, for example, “normal” google search or amazon giving you product recommendations.
I think the difference is at least partly that machine translators are giving you something you couldn’t easily get yourself—without them, you’d have to find someone who speaks the language and ask them to translate it, and that’s not always feasible, so there’s a sense that a not-quite-reliable translation is better than no translation.
LLM-powered search, on the other hand, is doing what a regular Google search would do, but worse. It only saves you effort if you decide to take what it says at face value; if you accept that it’s not reliable and check all the information it gives you to make sure it’s correct, you’re doing just as much work as you would be if you hadn’t used it.
I think part of it is probably just a reaction to the hype. Like if you keep hearing non-stop about how great some movie or game or whatever is and then you finally get around to checking it out for yourself and you end up thinking this is what everyone was so worked up about?
Like if you’d just stumbled into a LLM-powered search tool you might end up thinking “wow, this thing is pretty smart, it’s almost as good at searching for things as I am” instead of “what? this is supposed to be a big deal? it’s not even as good at searching for things as I am!”
There’s also an erasure-of-context problem. When you look at a document translated by machine translation, you nearly always have a link to the original. You may not know French, but the French document is right there and the right person could tell you exactly what it says.
LLM search hides its sources, by definition.