4 ms·
Math proofs only need to convince other people. Programs need to convince a compiler. If compilers were people and you talked to them for the first time, the on
by _05hb 2y ago
Math proofs only need to convince other people. Programs need to convince a compiler. If compilers were people and you talked to them for the first time, the only reasonable response would be to call them assholes and find new friends. The field of mathematics doesn’t have an equivalent of the “Norway Problem.”
Here’s my theory. Learning how to write code causes damage to the mind, particularly in the area of how you relate to other people. When we’re learning to code, men and women both notice this happening, but men care less. Women, on the other hand, tend to think, “this is bad and I should stop.”
It’s hard to become a programmer without becoming a weirdo in the process, and women have a lot more to lose by becoming weirdos. If we knew how to learn programming without the mind damage -- if we could figure out how to allow learners to skip the “coal face” of spending long hours into the night talking to a compiler -- then that would solve the gender imbalance.
Just my theory. For a good long stretch I thought the explanation was that tech compensation wasn't actually all that great compared to what women could earn in other fields, and then the explosive comp growth of the mid-late 2010s happened and I've been wondering about what is the problem ever since.
- cauch 2y ago> Math proofs only need to convince other people Wait, what? A math proof does not need to convince anyone: the proof exists or does not exist. If I prove X, then I don't need to convince other people that X is proven, they just have to read the proof. So, in practice, math is even worst than computer science. In computer science, you have to convince the compiler. In math, you need to convince math. You need to build an algorithm that compiles under the tons of math logic rules. > if we could figure out how to allow learners to skip the “coal face” of spending long hours into the night talking to a compiler But learning math and trying to build math proofs is even more "coal face-y". There is no pre-build debugger and you need to check things yourself, by hand, and when it fails it may be because you mess up the algorithm part or the compiler part. > Learning how to write code causes damage to the mind, particularly in the area of how you relate to other people. When we’re learning to code, men and women both notice this happening, but men care less. All of that is cultural. The developer mentality cultivates this idea that being burnout and being socially rude is a sign of success and is a manly thing to do. There is no reason why writing code causes damage, because it does not happen to plenty of other activities that are as grinding. Again, developers are not special, what they do and what they live is similar to a lot of other things. It feels more like a rationalization: the reason men get worse at relating to other people and become weirdos is because these men are failing at social life because of their mentality.
- _05hb 2y agoThanks for responding. Here’s what I mean about proofs. I learned how to do them in college, and in the early classes we got a lot of leeway on grading, and then as we moved up they expected more and more rigor. But it was still a conversation, like if I got dinged a few points on an exam question, I could take it to my professor and make my argument that my proof was valid, and I might get a point or two back. The proof-as-mathematical-object either exists or does not, but deciding whether my answer pointed to that proof was a social exercise. Professional mathematicians also cut either other some slack. Most proofs published today have small errors — typographical, skipped steps, etc — and those bugs are never fixed. Despite the bugs, we’re confident in the results, and that confidence is a product of social consensus. On the other hand, also in college, I had my programming classes, where I would turn in my code and they ran it through a test harness, and my grade was the number of tests that passed. So, if there was a syntax error, I got a 0. This was brutally harsh to the good students who attended every class, took notes, and studied, but who did not conform their minds to writing code. But that’s how we learn programming, because the compiler doesn’t care about intentions and “almost” is worth nothing. Alan Perlis said “programming is an unnatural act.” It’s not harder than other jobs — in many ways it’s easier — but it’s much weirder, and it makes you weird. Professional programmers write bugs, constantly: why can’t they just write the code, without the bugs? Because our minds aren’t built that way.
- cauch 2y ago> I learned how to do them in college ... I have the opposite experience: when learning physics, math was really difficult to negotiate with the professor, because it is mathematically correct or not. They had their table that said "if they have done this, X points, otherwise 0", which is an exactly equivalent system as the one where your grade corresponds to the number of test your software passes. It was easier to negotiate points in the computer science lectures, where I could argue that having used some concepts shown in the lecture (using object-oriented, recursive functions, ...) was worth some point even if I did not finish my algorithm. I think your experience (and mine) is just because you have been exposed to "beginner tests / optional course" in one field and "higher grade / main course" in the other. Beginner or optional lectures tend to give more leeway. > Professional mathematicians also cut either other some slack. Most proofs published today have small errors ... That's just not true: if there is an error, the result is not reliable, and it is therefore extremely important to identify them. It does not mean that the person who made the mistake will be thrown out of the field (of course not, every mathematician has made mistake some time, it's part of the job). And by the way, I wonder how you are in position to know that. You are claiming that "those bugs are never fixed". I've observed math-oriented conferences where some of the talks were all about discussing these bugs. I'm sure if you even have an example of such not-fixed-error, you have absolutely no idea how it was treated later by the scientific community. It's as stupid as saying "firefox 6 has a bug, it never has been fixed (but of course I did not look if they released new version)". But the problem with this argument is that you are comparing that to a field _that is build around the fact that bugs will always exist_. You have debugger, code review, testing environment, and despite that, every released software always end up have some bug fix updates. You are arguing that it's different for mathematicians because their publications contain errors (which is at best a very misleading description of the reality), while at the same time, DEVELOPERS RELEASED SOFTWARE WITH BUGS ALL THE TIME, in a way bigger rate and with sometimes way less following (some bugs are even some times considered "will not fix")