A human given the instruction “write a program that finds prime numbers” must use their background knowledge of prime numbers and algorithms to derive the sieve of Eratosthenes or an equivalent algorithm.
You can study a piece of code, discern that it is an algorithm for finding primes, and label it as such. However, to glance at a new piece of code and recognize it as prime-finding code, rather than defective prime-finding code, requires close inspection and not compression. This does not lend itself to the kind of optimizations suggested by the expression “sensory modality”, i.e. analogy to human sensory processing which compresses away lots of details — even relevant details, which is why we have optical illusions, etc.
That sort of thing is quickly checkable, though—the trouble is if looks like it finds primes, does something else, and that something else isn’t one of the hypotheses generated. Which could definitely make this much less useful if it was common.
I dunno, maybe you’re right and a holistic approach is necessary. But I feel like I understand code modularly rather than holistically, and though I sometimes lose track of details I’m usually pretty good at knowing which ones will be important later.
It’s easy to understand code modularly when it was written straightforwardly. It’s a lot harder when it’s spaghetti code … or when it’s actually intentionally tricky. Past a certain point there’s no choice but to actually step through each possible branch of the code — which can be done, but it’s hardly the sort of automatic layers of approximation and pattern-matching that our senses use.
Someone linked me to the 2008 contest once. I’m more familiar with the Obfuscated C Contest, which would also be a problem. But I think it’s fine to only be able to “intuit” about straightfoward-ish code. The main use, after all, would be to understand code written by your own programmers in order to self-improve.
A human given the instruction “write a program that finds prime numbers” must use their background knowledge of prime numbers and algorithms to derive the sieve of Eratosthenes or an equivalent algorithm.
You can study a piece of code, discern that it is an algorithm for finding primes, and label it as such. However, to glance at a new piece of code and recognize it as prime-finding code, rather than defective prime-finding code, requires close inspection and not compression. This does not lend itself to the kind of optimizations suggested by the expression “sensory modality”, i.e. analogy to human sensory processing which compresses away lots of details — even relevant details, which is why we have optical illusions, etc.
That sort of thing is quickly checkable, though—the trouble is if looks like it finds primes, does something else, and that something else isn’t one of the hypotheses generated. Which could definitely make this much less useful if it was common.
I dunno, maybe you’re right and a holistic approach is necessary. But I feel like I understand code modularly rather than holistically, and though I sometimes lose track of details I’m usually pretty good at knowing which ones will be important later.
Ever hear of the Underhanded C Contest?
It’s easy to understand code modularly when it was written straightforwardly. It’s a lot harder when it’s spaghetti code … or when it’s actually intentionally tricky. Past a certain point there’s no choice but to actually step through each possible branch of the code — which can be done, but it’s hardly the sort of automatic layers of approximation and pattern-matching that our senses use.
Someone linked me to the 2008 contest once. I’m more familiar with the Obfuscated C Contest, which would also be a problem. But I think it’s fine to only be able to “intuit” about straightfoward-ish code. The main use, after all, would be to understand code written by your own programmers in order to self-improve.