David J Prokopetz

I think one of my favourite domain-specific programming quirks is how, in Inform, code for rideable vehicles is non-portable to rideable animals (and vice versa) because the former are implemented via the "supporting" relation, and the latter, the "carrying" relation, meaning when you're riding a horse you're technically in the horse's inventory.

You'd think that would count as being equipped.

Owing to the way Inform's default equipment system works, having the horse equip the player would require the player to be defined as wearable, which has several implications.

For instance: If the horse attempted to eat the player, it would first need to remove them.

I'm always up for clowning on Inform's world model, but in this particular case the implications of the "can't eat worn items" rule with respect to horse ridership are less interesting to me than trying to work out what concrete game design objective could possibly be served by defining the player character as both wearable and edible in the first place.

@moddeydhoo replied:

Inform is apparently used pretty heavily in certain segments of the mainstream gaming industry as a rapid prototyping tool; much of its recent development has been aimed at serving that audience, rather than traditional interactive fiction, though the latter obviously benefits from the fact that it's still in development at all.

(Like, why do you think Inform has this big fancy IDE with all these enterprise-level features while every other IF platform barely has a manual? It's certainly not for the benefit of your average hobbyist!)

I think one of my favourite domain-specific programming quirks is how, in Inform, code for rideable vehicles is non-portable to rideable animals (and vice versa) because the former are implemented via the "supporting" relation, and the latter, the "carrying" relation, meaning when you're riding a horse you're technically in the horse's inventory.

You'd think that would count as being equipped.

Owing to the way Inform's default equipment system works, having the horse equip the player would require the player to be defined as wearable, which has several implications.

For instance: If the horse attempted to eat the player, it would first need to remove them.

I'm always up for clowning on Inform's world model, but in this particular case the implications of the "can't eat worn items" rule with respect to horse ridership are less interesting to me than trying to work out what concrete game design objective could possibly be served by defining the player character as both wearable and edible in the first place.

I think one of my favourite domain-specific programming quirks is how, in Inform, code for rideable vehicles is non-portable to rideable animals (and vice versa) because the former are implemented via the "supporting" relation, and the latter, the "carrying" relation, meaning when you're riding a horse you're technically in the horse's inventory.

You'd think that would count as being equipped.

Owing to the way Inform's default equipment system works, having the horse equip the player would require the player to be defined as wearable, which has several implications.

I 100% agree with the criticism that the central problem with "AI"/LLM evangelism is that people pushing it fundamentally do not value labour, but I often see it phrased with a caveat that they don't value labour except for writing code, and... like, no, they don't value the labour that goes into writing code, either. Tech grifter CEOs have been trying to get rid of programmers within their organisations for years – long before LLMs were a thing – whether it's through algorithmic approaches, "zero coding" development platforms, or just outsourcing it all to overseas sweatshops. The only reason they haven't succeeded thus far is because every time they try, all of their toys break. They pretend to value programming as labour because it's the one area where they can't feasibly ignore the fact that the outcomes of their "disruption" are uniformly shit, but they'd drop the pretence in a heartbeat if they could.

Like, you need to understand that regardless of their educational background, the vast majority of these jokers have not written a line of code in decades. They pose as genius hackers, but they're as much computer programmers as Elon Musk is an aerospace engineer.

I think there's nothing so revealing that a person is either a. a hobbyist programmer play-acting at being a web developer, or b. so deep in the Enterprise Ecosystem™ that they can no longer see daylight as "nobody develops websites in PHP anymore".

I can only hope that nobody intentionally starts a project in PHP any more, but I know that’s not the case. I’ve spent enough time dealing with White Pages of Doom and finding new ways PHP allows arbitrary code injection to swear off it for life.

There’s plenty of existing stuff in PHP that needs to stay that way, but you need to have a full time team plugging holes or you’ll never keep it secure. I’ve lost track of how many Wordpress sites gave up and moved their sites to Wordpress.com so the WP developers can do that maintenance instead.

I rather strongly suspect that if we ever reach the point where over fifty percent of all public-facing websites are written in something other than PHP, we'd very rapidly discover that, much like the putative superiority of the Linux security model over Windows, the apparently universally tighter security of all non-PHP scripting languages was just an artefact of the fact that nobody was looking especially hard.

I love logging into a website for a major financial institution and visibly being yanked through five different pages before finally landing on the current version of the user dashboard because all of the redirect logic is implemented in client-side Javascript for some fucking reason.

Nobody ever believes me when I say this, but I swear developers these days increasingly do not understand the difference between server-side and client-side programming. I recently did tech support for a fairly significant organisation (which will not be named here) whose web applications were sanitising database inputs on the client side.

I think the real reason most websites are janky as hell to use these days is because web developers have become so specialised that nobody really understands how anything works anymore. The other day I had to explain why hosting critical Javascript libraries on a third-party CDN is a bad idea to a "lead developer" who genuinely didn't know the difference between server-side versus client-side scripting.

PLUS the fact that nobody fucking hires actual trained UX professionals - user researchers and designers - anymore.

NO your developers DO NOT know how to create software that is actually easy to use by users. They (hopefully) know how to CODE.

It's not like UX developers are immune. I've frequently worked with allegedly trained UX developers who will proceed to produce a UI that looks slick, but is a bloated mass of tinker-toy code with several hundred baffling external dependencies under the hood. Half of them will hear something that ought to be a basic requirement for someone with their claimed credentials, like "for accessibility reasons we need a UI that's fully functional if the user overrides all the vendor styles and has Javascript turned off", and immediately bail. I once worked with a guy who claimed to be a certified accessibility expert and straight up did not know what the ARIA standard is.

—Proposals for the evolution of Inform E-0015: World model enforcement, subsection "Implicit taking"

While a discussion of the particulars and motivations of this proposed set of bug fixes is beyond the scope of a Tumblr post, I thought this blog's followership might appreciate the fact that, in Inform's present implementation, attempting to stick the Moon up your butt fails solely because the "inserting it into" action generates an implicit "take" action during its setup, and scenery objects are not valid targets for "take".

I noticed that according to the text, eating only "may" generate an implicit take action. Is it possible, under this interpretation, to eat the moon?

Eating is a bit of a special case in that it only generates an implicit "take" action if the subject is indeed a valid target for taking. It's possible – albeit weird – to define a scenery or backdrop object as edible, in which case no implicit "take" would occur and the game would permit it to be eaten without complaint. (This would, however, require the Moon to have explicitly been defined as edible!)

@jajarra replied:

Inform's standard world model actually has a lot of weird edge cases involving eating. There's a specific rule for attempting to eat an edible article of clothing which the acting character is currently wearing, for example – and yes, this will be blocked if the implicit "remove" action thereby generated fails for whatever reason.

(Under what narrative circumstances the removal of an article of one's own clothing preparatory to eating it could conceivably fail is left as an exercise for the reader!)

This is candy necklace and ring pop erasure!

Inform's world model tends to err on the side of caution; wearable items don't inherently specify what part of the body they're worn on – that's something the author needs to implement themselves, if they decide it's relevant – and in the absence of such elaboration, Inform typically favours the rule with the smallest potential for broken immersion.

For example, being unable to eat one's own pair of gloves without first removing them suggests only that the player character is fastidious; on the other hand, being able to eat one's own hat without first removing it raises several questions.

It clearly just had a long plume that let you slurp it up like spaghetti (or a rabbit eating a sprig of parsley) and it went unremarked on because that's the normal way for hats to be.

—Proposals for the evolution of Inform E-0015: World model enforcement, subsection "Implicit taking"

While a discussion of the particulars and motivations of this proposed set of bug fixes is beyond the scope of a Tumblr post, I thought this blog's followership might appreciate the fact that, in Inform's present implementation, attempting to stick the Moon up your butt fails solely because the "inserting it into" action generates an implicit "take" action during its setup, and scenery objects are not valid targets for "take".

I noticed that according to the text, eating only "may" generate an implicit take action. Is it possible, under this interpretation, to eat the moon?

Eating is a bit of a special case in that it only generates an implicit "take" action if the subject is indeed a valid target for taking. It's possible – albeit weird – to define a scenery or backdrop object as edible, in which case no implicit "take" would occur and the game would permit it to be eaten without complaint. (This would, however, require the Moon to have explicitly been defined as edible!)

@jajarra replied:

Inform's standard world model actually has a lot of weird edge cases involving eating. There's a specific rule for attempting to eat an edible article of clothing which the acting character is currently wearing, for example – and yes, this will be blocked if the implicit "remove" action thereby generated fails for whatever reason.

(Under what narrative circumstances the removal of an article of one's own clothing preparatory to eating it could conceivably fail is left as an exercise for the reader!)

This is candy necklace and ring pop erasure!

Inform's world model tends to err on the side of caution; wearable items don't inherently specify what part of the body they're worn on – that's something the author needs to implement themselves, if they decide it's relevant – and in the absence of such elaboration, Inform typically favours the rule with the smallest potential for broken immersion.

For example, being unable to eat one's own pair of gloves without first removing them suggests only that the player character is fastidious; on the other hand, being able to eat one's own hat without first removing it raises several questions.

—Proposals for the evolution of Inform E-0015: World model enforcement, subsection "Implicit taking"

While a discussion of the particulars and motivations of this proposed set of bug fixes is beyond the scope of a Tumblr post, I thought this blog's followership might appreciate the fact that, in Inform's present implementation, attempting to stick the Moon up your butt fails solely because the "inserting it into" action generates an implicit "take" action during its setup, and scenery objects are not valid targets for "take".

I noticed that according to the text, eating only "may" generate an implicit take action. Is it possible, under this interpretation, to eat the moon?

Eating is a bit of a special case in that it only generates an implicit "take" action if the subject is indeed a valid target for taking. It's possible – albeit weird – to define a scenery or backdrop object as edible, in which case no implicit "take" would occur and the game would permit it to be eaten without complaint. (This would, however, require the Moon to have explicitly been defined as edible!)

@jajarra replied:

Inform's standard world model actually has a lot of weird edge cases involving eating. There's a specific rule for attempting to eat an edible article of clothing which the acting character is currently wearing, for example – and yes, this will be blocked if the implicit "remove" action thereby generated fails for whatever reason.

(Under what narrative circumstances the removal of an article of one's own clothing preparatory to eating it could conceivably fail is left as an exercise for the reader!)