[gpjanik]

"Think in math, write in code" is the possibly worst programming paradigm for most tasks. Math notations, conventions and concepts usually operate under the principles of minimum description lenght. Good programming actively fights that in favor of extensibility, readability, and generally caters to human nature, not maximum density of notation.

If you want to put this to test, try formulating a React component with autocomplete as a "math problem". Good luck.

(I studied maths, if anyone is questioning where my beliefs come from, that's because I actually used to think in maths while programming for a long time.)

[Zacharias030]

The people I know who „think in math“ don’t think in the syntax of the written notation, including myself.

[gpjanik]

If you're adding some computational/problem breakdown/heuristic steps on top/instead of mathematical concepts, then you're doing the opposite of what the author proposes.

Scientific conensus in math is Occam's Razor, or the principle of parsimony. In algebra, topology, logic and many other domains, this means that rather than having many computational steps (or a "simple mental model") to arrive to an answer, you introduce a concept that captures a class of problems and use that. Very beneficial for dealing with purely mathematical problems, absolute distaster for quick problem solving IMO.

[godelski]

  > Math notations, conventions and concepts usually operate under the principles of minimum description lenght.

I think you're confusing the fact that math is typically written by hand on paper or a board. That optimization is not due to math, it is due to the communication medium.

If we look at older code we'll actually see a similar thing. People are limited in character lengths so the exact same thing happened. That's why there's still conventions like 80 char text width, though now those things serve as a style guide rather than a hard rule. It also helps that we can auto complete variables.

Your criticism is misplaced.