There are two diametrically opposed schools of thought in programming language design. One is that programmers write better code with fewer restrictions, and the other is that they write better code with more restrictions. In my opinion, the reality is that good experienced programmers flourish with fewer restrictions, but that restrictions can benefit the code quality of beginners.
User-defined operators can make for very elegant code in experienced hands, and utterly awful code by a beginner. So whether your language includes them or not depends on your language designer's school of thought.
Sometimes, the specification of an algorithm is based on bit operations. This is especially true in crypto work.
Crypto has another attribute to it that is important - that the operation takes exactly the same amount of time no matter what the parameters are. This is to try to avoid leaking any data with timing attacks (there are even attacks based on the sounds the computer makes while doing cryptography).
Thus, for cryptography, it is of paramount importance that the code takes exactly the same amount of time and does the same things. Bitwise operations can play a significant role in that area in that they are not often or easily optimized by the compiler. With things were you can short circuit the expression or decide to follow one branch or another that has a different timing these are avenues of timing attacks.
The code
if(x < y) {
r = x;
} else {
r = y;
}
Can take different amounts of time based on the branch prediction and branching itself. While
r = y ^ ((x ^ y) & -(x < y));
takes exactly the same amount of time each time through the code. Branch prediction doesn't play a role because there are no branches in there.
With graphics work, there are similar areas of concern. Some systems (especially older ones) had the CRT refresh tied with the clock cycle (for example the Amiga had 4 clock cycles per refresh line). This meant that when you wrote code that was specifically tailored to the graphics of the system you knew exactly where the screen refresh was and could improve the appearance of the system. This isn't quite as much of an issue now (the GForce GTX 780 can do 40,0000 operations per pixel per frame refresh), but it is something to be considered.
Secondly, there's also deep magic within fitting things into various caches on various systems. Doing as much as possible with the cache can improve that. This often means doing bitwise work rather than trying to load and store things or send them off to the ALU.
In Java, this can be difficult to know for certain, but again, maintaining a consistent frame rate based on the scene is something that is often very important with graphics.
Best Answer
The ternary operator is well used, especially for short null-checks / defaults:
Some people consider this not as readable as an if/else, but that was not the question.
The XOR bitwise operator is only used in bit-processing. If you need a bitwise XOR, then there is no way around it.
The XOR logical operator is indeed so rare, that I did not see it in the last ten year in Java in valid cases. This is also due to the fact, that the boolean XOR "does not scale" like
||or&&. What I mean:In the last case I would guess, the coder meant "only one should be true". But XOR is a beast. The coder got the beast and not what (s)he wanted.
That would be an interesting interview question: What is the result of the last
if?