A possible concrete example I think a good class of concrete examples might be programmers working with ‘legacy code’. I’m currently working with some code that’s not a central or prototypical example of legacy code, but I’ve noticed that all of the same issues of working with legacy code seem to be coming up: ignorance or uncertainty about both how the code works and how it ‘should’ work. The former – how the code works (if it does!) – is at least possible to discover – eventually (and maybe just most of the time). The latter tho sometimes remains nebulous forever (to varying degrees)! Code is written for people – either ourselves as solo programmers or for some nebulous audience of current collaborators, possible future collaborators, or even other passive readers. And yet there is no fixed meaning inherent in any code! Beyond the nebulosity of human language generally, the meaning of code can be slippery for many other reasons. Consider a function named addSomething(x) but whose code instead is x * 5. Does the function name imply that its code is incorrect? Or ‘should’ the function’s name have been changed to calculateSomething instead (at some earlier point)? Maybe all the people that ‘matter’, e.g. all of the (other) people that work with that code, already understand that the function addSomething doesn’t ‘naively’ describe its behavior and its name is understood more as a proper name than a regular ‘phrase’. Interestingly, naming code elements such that the ‘naive’ interpretation (relatively) closely matches its behavior is considered good practice. Unfortunately, there’s no set of fixed ‘naive’ interpretations available for all possible readers of any code. Computer science recognizes all of this as ‘Naming is hard!’.