I wonder if the first one was meant to be

    a -= a * a;

which evolved from

    a *= a;

after the author thought "I need to subtract its square from itself, not just square it". I can see how this could occur in numerical code.

I've noticed there are two opposing schools of thought on issues of "insane code" like this; on one side there's "use the language to the fullest if it makes sense to", and on the other is "avoid anything that might be the slightest bit confusing". I think that taking either of those to their logical conclusion is not a good idea --- in the former case, you'll end up with extremely dense and (initially) difficult-to-understand code, but the latter case will cause a gradual degradation of code into something approaching the verbosity of Asm, but with none of the benefits (e.g. "ternary operators are confusing, don't use them; multiple levels of precedence are confusing, so always fully parenthesise expressions; nested parentheses are hard to read, so don't use them either and only do one operation per statement; boolean expressions are confusing, so always use if/else; nested if/else are confusing, so don't nest and always refactor to use a function call, etc. etc.)

It does seem that different languages vary in where they are on this scale, with more "exotic" ones like APL tending highly towards the former (interesting related discussion: https://news.ycombinator.com/item?id=13565743 ) and C#/Java towards the latter. The ideal is probably somewhere in the middle.