I'll take a stab at it. (That is to say, "I think I understand how the phrase is being used, at least to a degree that it makes perfect sense to me. I may, of course, be wrong. But I'll try to translate my understanding.")
At any level above the trivial, the code we write (or work with) is very often not a direct set of instructions for the machine to carry out. Here, I don't simply mean a high-level language is not machine code or assembly. I think it's safe to assume that we all get that much at least.
Rather, it's a lot like everyday conversation, but with Lewis Carrol's Humpty Dumpty character. There will be common (and less-than-common) cultural references, along with a whole bunch of private definitions for things. Actually understanding the conversation means not only having those cultural references in common[1], but also having access to the private definitions[2] (such as "glory" meaning "a nice knock-down argument").
So the text on the screen (or in the file) is not the actual code, or even a complete description of the code, that the machine will run. It's only a sort of short-hand representation, a language we created along the way to talk about the instructions (even if, at the basic level of the language facilities, the operators and keywords are directly translatable). Simply working with the text content, then, as one would do with a simple parser, or as a human programmer would do with a single text file in isolation, is insufficient; the person or tool would have to have a much deeper understanding of the implications of the text in order to make any real sense of it.[3] For a tool to offer useful help (beyond the simple matter of altering text), it has to be able to "understand" what the text means, and that , in turn, means looking beyond the simple arrangement of text characters.
[1] It might help to think about the Darmok episode of Start Trek TNG. Library calls are very much like the metaphorical language of the Tamarians, in that they make perfect sense if we know the "story" being referenced, but not knowing means either the reference is meaningless or can even be misleading.
[2] That applies as much to preprocessing directives like constant definitions as it does to things like function/method calls.
[3] We do this is natural languages as well. Every time you've run across a cant, an argot or a jargon specific to one field of endeavor, you either understand it because you are familiar with the displaced vocabulary, or you're left in that uncomfortable state of knowing (or thinking you know) what most of the words mean, but failing entirely to understand what's being said.
At any level above the trivial, the code we write (or work with) is very often not a direct set of instructions for the machine to carry out. Here, I don't simply mean a high-level language is not machine code or assembly. I think it's safe to assume that we all get that much at least.
Rather, it's a lot like everyday conversation, but with Lewis Carrol's Humpty Dumpty character. There will be common (and less-than-common) cultural references, along with a whole bunch of private definitions for things. Actually understanding the conversation means not only having those cultural references in common[1], but also having access to the private definitions[2] (such as "glory" meaning "a nice knock-down argument").
So the text on the screen (or in the file) is not the actual code, or even a complete description of the code, that the machine will run. It's only a sort of short-hand representation, a language we created along the way to talk about the instructions (even if, at the basic level of the language facilities, the operators and keywords are directly translatable). Simply working with the text content, then, as one would do with a simple parser, or as a human programmer would do with a single text file in isolation, is insufficient; the person or tool would have to have a much deeper understanding of the implications of the text in order to make any real sense of it.[3] For a tool to offer useful help (beyond the simple matter of altering text), it has to be able to "understand" what the text means, and that , in turn, means looking beyond the simple arrangement of text characters.
[1] It might help to think about the Darmok episode of Start Trek TNG. Library calls are very much like the metaphorical language of the Tamarians, in that they make perfect sense if we know the "story" being referenced, but not knowing means either the reference is meaningless or can even be misleading.
[2] That applies as much to preprocessing directives like constant definitions as it does to things like function/method calls.
[3] We do this is natural languages as well. Every time you've run across a cant, an argot or a jargon specific to one field of endeavor, you either understand it because you are familiar with the displaced vocabulary, or you're left in that uncomfortable state of knowing (or thinking you know) what most of the words mean, but failing entirely to understand what's being said.