5 ms·
I really, really appreciate your reply and its tone. Thank you for that. You've given me some things to think about. I often wish people were more like compute
by throwaway31338 5y ago
I really, really appreciate your reply and its tone. Thank you for that. You've given me some things to think about.
I often wish people were more like computers. It probably wouldn't make the world better but it would make it more comprehensible.
- ColinWright 5y agoThanks 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.
- JohnHaugeland 5y ago> We reuse variable names in different scopes 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 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.
- Jensson 5y ago> This example works against you. Scope shadowing is nearly universally considered bad practice So you never used the same variable name in two different scopes ever? Like, if a function takes argument "name", no other function you ever write again in any program can have a variable named "name" unless it is the same exact usage? Or, as is commonly complained about in math, every programmer in the world then use the variable "name" only for that usecase and otherwise comes up with a new name for it? Having different scopes doesn't imply shadowing, it just means that you define it and then use it and then scope goes out and it no longer exists. No mathematician knows even close to every domain, so different domains of math uses notation differently. It is like how different programmers programs in different programming languages. It is such a waste to have so many programming languages, but people still do it for legacy reasons.
- JohnHaugeland 5y ago> So you never used the same variable name in two different scopes ever? That's not what shadowing is. . > Having different scopes doesn't imply shadowing I didn't say that it did. . > No mathematician knows even close to every domain this is irrelevant to a lightweight two page cheat sheet for simple mathematial symbols part of the problem is that if we ask you for a simple thing that isn't perfect or exhaustive, you lecture us on how no document could contain every concept that's very clearly not what's being requested of you. the same is true of haskell. that sheet doesn't contain all of haskell. i doubt anybody knows all of haskell, which of course is far smaller than mathematics. i'd like to stay in the practical world. it was clearly stated that an exhaustive solution was a non-goal. let's try to do one thing that doesn't have a limit at infinity. (i'm sorry, i'm a programmer, math jokes are hard) surely you've made food, right? did you learn the recipe from a cookbook? did it contain every ingredient and recipe that any cook ever knew? did it go over the chemistry of the protein denaturing, the physics of the water boiling, the ethics of importing the burner fuel, allergy responses, cultural backgrounds, molecular weights, how to make things in a duck press? no? was that because the cookbook was just good enough? it was just like "use this much chicken and this much onion, two tortillas, some cilantro and lime?" nobody wants exhaustive anything. if you managed somehow to produce that (ie by just giving the manual page to the wolfram language) it would be rejected as the exact opposite of what was being requested. the thing you're protesting is the i'm saying is the wrong job. cool beans. the thing i'm actually asking for is straightforward. someone already gave me one, but the difficulty level was aimed at children, instead of professional programmers, the space requested, while also calling me ignorant. it's a shame; that one was almost it. but it should be things like `ŷ` and `||x||` and whatever. it should include sum, integral, and product for the juniors. For `|x|` it should say "Absolute value, magnitude, length, or cardinality." it doesn't need `||x||` because we need someone to teach us what absolute value and cardinality and so on mean. it needs `||x||` because we forgot what double-bar says, and if we have that list of four things, we can figure out which one it is just like you can. we know what magnitude is. we just don't know what `||foo||` says. we just need our cracker jack decoder rings. we get the ideas. we don't get your letters. It's not explaining anything. It's just a cheat sheet. You aren't solving education. C'mon. This isn't too far off: https://en.wikipedia.org/wiki/Glossary_of_mathematical_symbols https://en.wikipedia.org/wiki/Glossary_of_mathematical_symbo... . > It is such a waste to have so many programming languages if you say so. i rather like the several that i created. things aren't a waste just because you don't know what they're for. you might as well assert that it's a waste that there are so many tools in the shop. The statisticians can do it: http://web.mit.edu/~csvoss/Public/usabo/stats_handout.pdf http://web.mit.edu/~csvoss/Public/usabo/stats_handout.pdf . > every programmer in the world then use the variable "name" only for that usecase and otherwise comes up with a new name for it? this isn't terribly uncommon, primarily because our culture is to use long descriptive names, which have a far lower natural collision rate i do get that symbols can overlap. that's okay! nobody's complaining about that. it's fine for `||x||` to mean four things. we're just as bad as you are about that. there's half a dozen meanings for stack, another five for heap, seven for map, five for vector, i don't even want to get into what a mess "array" is, et cetera. but if i was writing a cheat sheet for you, I could write `< > generally means a generic type, a tuple, greater than less than, an HTML/XML/SGML tag, an email inclusion, or an IRC handle` Is that exhaustive? Naw. I can name another dozen off the top of my head. But that's generally going to be good enough. All I want is generally good enough. just please write down what they are?