The real code would of course be accompanied with explanation of what the variables all are, the procedure used, how the matrix can be reduced, etc. Any things like this will inevitably, sans comments, be difficult to make head or tail of. That doesn't mean that they're bad techniques.
> Any things like this will inevitably, sans comments, be difficult to make head or tail of.
perhaps true (maybe). but if the variables were named properly we would at least have a decent idea of what the expressions actually are - even if we can't then infer what they are for from that information.
imo that is precisely what a comment is for - explaining an algorithm or things that look unusual, not merely explaining what a variable is - which imo is precisely what a variable name is for.
Sometimes what variables represent is too complicated to be expressed in a variable name. If you insist that all variables be semantically intelligible without reference to the part they play in the entire algorithm, you may be committing yourself to a less efficient algorithm that isn't any more flexible.
Is there something wrong with code that is too dense to be self-documenting, especially if you're willing to write and distribute a paper to explain it? Would you understand "pivot" in quicksort if you hadn't read a description of how quicksort works?
