|
Thanks for the pingback ... I appreciate that. And thanks for acknowledging that I'm trying to help. It might also help to think of "scope" in the computing sense. Often you have a paragraph in a math paper using symbols one way, then somewhere else the same symbols crop up with a different meaning. But the scope has changed, and when you practise, you can recognise the change of scope. We reuse variable names in different scopes, and when something is introduced exactly here, only here, and only persists for a short time, sometimes it's not worth giving it a long, descriptive name. That's also similar to what happens in math. If I have a loop counting from 1 to 10, sometimes it's not worth doing more than: for x in [1..10] {
/* five lines of code */
}
If you want to know what "x" means then it's right there, and giving it a long descriptive name might very well hamper reading the code rather than making it clearer. That's a judgement call, but it brings the same issues to mind.I hope that helps. You may still not like math, or the notation, but maybe if gives you a handle on what's going on. PS: There are plenty of mathematicians who complain about some traditional notations too, but not generally the big stuff. |
This example works against you. Scope shadowing is nearly universally considered bad practice, to the point that essentially every linter is pre-configured to warn about it, as are many languages themselves (eg prolog, erlang, c#, etc)
To a programmer, you're saying "see, we do it just like the things you're taught to never ever do"
.
> You may still not like math, or the notation,
The notation is probably fine
What I personally don't like is mathematicians' refusal to provide easy reference material
Programmers want mathematicians to make one of these: https://matela.com.br/pub/cheat-sheets/haskell-cs-1.1.pdf
It doesn't have to be perfect. We don't need every possibility of what y-hat or vertical double bars means. An 85% job would be huge.