Why programming methodologies are pointless

Well, "education" is too vague term to speak of then, because, really, it's still a question if obligatory school education is more harmful or helpful, even goals themselves aren't defined good enough here to decide if something "works" or not. But, yes, I understand that wasn't your point either.

> And yet, we as a civilization can still benefit from "math proofs" in spite of the fact that there are some philosophical differences on what "proof" is.

Not really. You don't generally benefit from proofs being correct. You benefit from something you think is correct works well for your purposes, and it usually isn't proof itself, but some result derived from it. It's actually considered even paradoxical, that our math "works so well" despite of very foundations of it being proved "not working". It's like… well, I cannot remember good enough example right away, but consider different folk beliefs: many of them are actually pretty good advices, but not because there are some true reasoning behind them, but simply because they advice to do something in some situation that occurs to be helpful in case of phenomenon which in real life often occurs along with described situation. So some enlightened gentleman who is against silly superstitions and can show that "proof is incorrect" only suffers from that, because despite "proof being incorrect" the adviced behavior is still the safest one.

And by the way I don't only mean "philosophical problems" like ones we've got after Goëdel. I remember being told when I was a kid that mathematics are very old science, that it was used and developed by ancient persians, egyptians, etc. And, well, it was. So years later I was really, really astonished to learn how frivolous to say at least that "mathematics" was. Many things that we know as theorems today weren't actually theorems back then (which isn't surprising by itself, because the mathematical notation itself is very late invention, but I expected the essence of it to be the same), but more like beliefs or pretty redundant technical recipes on how to make this or that thing done. Even one comparatively late and "truly mathematical" text — Euclid's "Elements", that is, — isn't without faults. Many of his proofs weren't proofs by any today's standards, or even by standards of 100 years ago. Many of his very basic statements were dismissed later as being redundant or incorrect or simply pointless in the sense that "they mean nothing" in the context of maths. Still, as you know that work of his was quite helpful for later generations.

> Those are 2 very different sentences and I did not write what you think I wrote.

Actually not, I didn't think what you think I did think you wrote. I understood you correctly. I said that ["best practices" are not disqualified because of disagreements] isn't the most correct thing to say, because if there is disagreement between adepts of "best practice A" and contradictory "best practice B" it's very much possible — even likely — that "best practice A" could and should be disqualified in favor of "best practice B", because the second one is objectively more beneficial (and then it would be "disqualified because of disagreements" indeed). Yet because world isn't black and white "best practice A" could also be working, so if you stick with A it could be better than nothing at all.

> The crux of my argument is relying on methodologies to write good software or to guide a design is pointless.

> Instead of trusting everything you read, you should question it an consider it in practice before you actually follow it.

But once you've questioned and evaluated it, its still a methodology. If you just mean you shouldn't take published methodologies on faith but consider how they work in your particular environment, that's widely accepted truth. Its, among other things, a central idea of the Agile software movement, as well as central to Lean methods (not just in software, either) and, more generally, to all models based around a Plan-Do-Check-Act cycle and variants thereof.

Its hardly a controversial or new observation, though there are plenty of failures to put it into effect.

I find that when it comes to optimizing code with an emphasis on readability, the improvement is rarely only 5%. Plus the improvement is not just the end result's performance, but also in writing.

I think I don't understand this readability thing. I have trouble keeping the structure of large programs in my head. So for me, the number one readability property of a program is it's length. The shorter, the quicker I can read it.

For other people it seems to be a lot more about code they don't understand. List and dict comprehensions are one such thing, especially the iterator-based ones. Using variable capture with in-line functions is another, and God forbid I pass around a function pointer to an inner function, because it often lets me avoid writing an entire pointless class that I have to remember exists. I use functional programming constructs constantly where they make sense, which tends to be a lot of places. Why is all this forbidden ? Is this because people don't know what they do/how powerful these constructs can be ? I feel that rewriting a nested list comprehension into a 20 line function does absolutely nothing to clarify matters for me, it makes things worse.

No, you don't use the proof of Pythagorean's Theorem every day. I guess you never did at all. You use some computational procedure which is developed along with that proof. For a layman it might seem there's no difference, but difference is huge. For Pythagoras himself and other people who used this simple procedure in that time it was more like physical quality of the real world, one of many procedures used to divide land on parcels (hence geometry, by the way). The "mathematical" part of his philosophy was more like religious practice with peculiar ideas, than what anybody calls "math" today.

The problem of "proof" didn't exit back then. What is proof? What looks like correct reasoning to me, that's what it is! And that was like a fine definition for every sane for a very, very long time. Have you read Kant's "Critique of Pure Reason"? It was way later that Pythagoras, Kant was obviously quite smart man and his reasoning was pretty solid for his time. Now it's nonsense. Because Euclidean geometry was considered the only possible back then, and Kant indeed believed it's the only possible. Then some 100 years later it just appeared out of nowhere. That's when a problem of "proof" and "formal reasoning" was actually started to be considered. And only really became a problem after Goëdel. The whole math you use every day by making cell-phones, building atomic reactors and launching rockets to the Moon was mostly invented before that by people who weren't so concerned by proofs, the central object of mathematics today.

Similarly, you use just some formula you was taught at one point, and some semi-intuitive rules by which you can derive other formulas from it and don't really care about proofs. And although you without doubt have heard about Lobachevsky and Riemann and even Klein, and heard of "Erlang" (even if it's just a name of programming language to you) you don't really think much about Pythagorean's Theorem's proof and what it's built on, you use some computational methods you've been taught and what seems like "correct reasoning" to you. Actually, you even reinforced that by your examples, because there's many more ways to calculate a "distance" inside matrices or in a video game (and on plain Earth it's more based on physical properties you care for and would be fine even if only "proved" empirically). Because "distance" is not derived from Pythagorean Theorem, distance is defined and is one of key properties of some geometry. That is, you define geometry by introducing formula of how distance is calculated.