On the other hand there's something to be said for terseness. Ever read a math or CS paper that's full of equations and other graphical shorthand? To the uninitiated, it's gibberish. Once you learn the conventions, it's a way to communicate complex formal ideas with very concise notation.
I'm not saying this language does a good job at that, but to dismiss something interesting just because of syntax prejudice is shortsighted.
Pretty much every CS paper I've read that was full of equations could have easily done without them. There certainly are sub-fields of CS where complex equations in papers are justified, but far too often it is laziness, and hides assumptions or imprecise descriptions that makes implementing the described methods harder.
Mostly, when I come across complex equations in CS papers, I tend to skip over them and only go back to look at them if there are parts of the paper I can't make sense of without them - it is very rare to find that they are necessary at all.
The cases where I find I need them are usually a sign of trouble - it tends to mean there'll be a lot of guesswork to figure out parameters and parts of the algorithms that are not spelled out in the paper at all. But usually the same ideas will be expressed in English, code or pseudo-code in much simpler ways.
My research for my MSc involved a bunch of papers on error correction in OCR, including a ton of image processing and statistical analysis, and not one of the 50+ papers I reviewed actually depended on the equations present in them for understanding the ideas, but I quickly learned to appreciate the ones that were light of equations for the seemingly substantially higher odds that the algorithm descriptions would be pretty much complete and precise.
There certainly are sub-fields of CS where complex equations in papers are justified, but far too often it is laziness, and hides assumptions or imprecise descriptions that makes implementing the described methods harder.
But without such obfuscation, how would CS PhDs retain their competitive advantages?
I mean, if anyone could just read your paper and actually implement the algorithms that you talk about there without having access to your base code and the real details that you didn't publish, then they might scoop you on the next (quite obvious) iterative improvement to your algorithm without having to do two years of preliminary work. And then you'd only get one paper out of it, whereas by obfuscating the hell out of the thing, you can milk it for five or six.
>
Mostly, when I come across complex equations in CS papers, I tend to skip over them and only go back to look at them if there are parts of the paper I can't make sense of without them - it is very rare to find that they are necessary at all.
Obviously any equation can be expressed in words, but those who are familiar with the notation are able to read the equations and understand the ideas in a paper in a fraction of the time. This is important for those who read papers regularly.
Maths is not about conventions. It is a dynamic writing style. All operators get replaced by adjacency after a few lines as writing them is boring. Computer verifying proofs is very hard for notation reasons.
I'm not saying this language does a good job at that, but to dismiss something interesting just because of syntax prejudice is shortsighted.