I think the author makes a good point about understanding structure over symbol manipulation, but there's a slippery slope here that bothers me.

In practice, I find it much more productive to start with a computational solution - write the algorithm, make it work, understand the procedure. Then, if there's elegant mathematical structure hiding in there, it reveals itself naturally. You optimize where it matters.

The problem is math purists will look at this approach and dismiss it as "inelegant" or "brute force" thinking. But that's backwards. A closed-form solution you've memorized but don't deeply understand is worse than an iterative algorithm you've built from scratch and can reason about clearly.

Most real problems have perfectly good computational solutions. The computational perspective often forces you to think through edge cases, termination conditions, and the actual mechanics of what's happening - which builds genuine intuition. The "elegant" closed-form solution often obscures that structure.

I'm not against finding mathematical elegance. I'm against the cultural bias that treats computation as second-class thinking. Start with what works. Optimize when the structure becomes obvious. That's how you actually solve problems.

I agree with the thrust of the article but my conclusion is slightly different.

In my experience the issue is sometimes that Step 1 doesn't even take place in a clear cut way. A lot of what I see is:

  1. Design algorithms and data structures
  2. Implement and test them

  1. Program algorithms and data structures
  2. Implement and test them

  1. Implement
  2. Test

  1. Test
  2. Implement

IMO, this last popular approach gets things completely backwards. It assumes there is no need to think about the problem before hand, to identify it, to spend any amount of time thinking about what needs to happen on a computer for that problem to be solved... you just write down some observable behaviors and begin reactively trying to implement them. Huge waste of time.

The point also about "C-style languages being more appealing" is well taken. It's not so much about the language in particular. If you are able to sit down and clearly articulate what you're trying to do, understand the design tradeoffs, which algorithms and data structures are available, which need to be invented... you could do it in assembly if it was necessary, it's just a matter of how much time and energy you're willing to spend. The goal becomes clear and you just go there.

I have an extensive mathematical background and find this training invaluable. On the other hand, I rarely need to go so far as carefully putting down theorems and definitions to understand what I'm doing. Most of this happens subliminally somewhere in my mind during the design phase. But there's no doubt that without this training I'd be much worse at my job.

Are people not reading the article or are they so primed into thinking that math is a certain way that the authors words are missed?

  > The natural language which has been effectively used for thinking about computation, for thousands of years, is mathematics. Most people don’t think of math as free or flexible. They think of scary symbols and memorizing steps to regurgitate on tests. Others hear math and think category theory, lambda calculus, or other methods of formalizing computation itself, but these are hardly necessary for programming itself.

  > It’s not that programming languages aren’t good enough yet. It’s that no formal language could be good at it. Our brains just don’t think that way. When problems get hard, we draw diagrams and discuss them with collaborators.

I think if you carefully read the author then many of you might be surprised you're using math as your frame of thinking. The symbols and rigor can help but mathematical thinking is all about abstraction. It is an incredibly creative process. But I think sometimes we're too afraid of abstraction that we just call it different names. Everything we do in math or programming is abstract. It's not like the code is real. There's different levels of abstraction and different types of abstraction, but all these things have their uses and advantages in different situations.

I would submit once you obtain a certain level of experience it becomes IDEAL to begin with implementation, in case a mathematical analysis may be either trivial or impossibly non-trivial... Of course if you're dealing in exchange rates and risk management, understand the math!

I already regret reading this article. Don't get me wrong, it's well written, and I agree with most of it. But every time I read an article like this I get stuck in analysis paralysis for any code I need to write afterwards and that's just not very productive.

Here's hoping my recognising the issue will soften the blow this time! Mayhaps this comment might save someone else from a similar fate

I wish there was a better explanation on what the exact problem was that they were trying to solve. I couldn't understand the problem - if I did I would have proposed my own solution, and then compared to the thinking process proposed to validate if that could've worked better for me, but I can't be bothered to follow the thinking process in the symbols like this without even knowing what we are solving for.

Was it about how to design a profitable algorithm? Was it about how to design the bot? was it about understanding if results from the bot were beneficial?

If that I would just backtest the algorithm to see the profit changes on real historical data?

> Definition: We say that the merchant rate is favorable iff the earnings are non-negative for most sets of typical purchases and sales. r'(t) is favorable iff e(P, S) >= 0.

If I understand the definition correctly, I would say that this is likely even wrong because you could have an algorithm that will be slightly profitable 90% of the time, but the 10% of the time it loses everything.

A correct solution to me is to simulate large numbers of trades based on as realistic data as you can possibly get and then consider the overall sum of the results, not positive vs negative trades ratio.

But many computer applications are models of systems real or imagined. Those systems are not mathematical models. That everything is an “algorithm” is the mantra of programmers that haven’t been exposed to different types of software.

I'm an engineer I think there is definitely some pain points translating math to code.

I've written some nasty numerical integration code (in C using for loops) for example I'm not proud of it but it solved my issue. I remember at the time thinking surely there must be a better way for computers to solve integrals.

That's still a chaotic composition of thoughts, not driven by any identified structure or symmetry of the situation.

Why a program is needed? What constraints lead to the existence of that need? Why didn't human interactions need a program or thinking in math? Why do computers use 0s and 1s? You need to start there and systematically derive other concepts, that are tightly linked and have a purpose driven by the pre-existing context.

> Programming languages are implementation tools for instructing machines, not thinking tools for expressing ideas.

I completely disagree with that assumption.

Any function call that proceeds to capture logic, e. g. data from reallife systems, drones or robot, or robots in logistics - you will often see they proceed in a logic chain. Sometimes they use a DSL, be it in rails, but also older DSLs such as the sierra game logic and other DSLs.

If you have a good programming language it is basically like "thinking" in that language too. You can also see this in languages such as C, and the creation of git. Now I don't think C is a particularly great language for higher abstractions, but the assumption that "only math is valid and any other instruction to a machine is pointless", is simply flat out wrong. Both is perfectly valid and fine, they just operate on a different level usually. My brain is more comfortable with ruby than with C, for instance. I'd rather want languages to be like ruby AND fast, than have to adjust down towards C or assembly.

Also the author neglects that you can bootstrap in language xyz to see if a specific idea is feasible. That's what happened in many languages.

Effort was made to write this article. Deep insight in several statements.

"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.)

I have a love-hate relationship with Math.

I love the logical aspect and the visualization aspect like writing down a formula and then visualizing/imagining a graph of all possible curves which that formula represents given all possible values of x or z. You can visualize things that you cannot draw or even render on a computer.

I also enjoy visualizing powers and logarithms. Math doesn't have to be abstract. To me, it feels concrete.

My problem with math is all to do with syntax, syntax reuse in different contexts and even the language of how mathematicians describe problems seems ambiguous to me... IMO, the way engineers describe problems is clearer.

Sometimes I feel like those who are good at math are kind of biased towards certain assumptions. Their bias makes it easier for them to fill in gaps in mathematical language and symbolism... But I would question whether this bias, this approach to thinking is actually a universally good thing in the grand scheme of things. Wouldn't math benefit from more neurodiversity?

I remember at school, I struggled in maths at some points because I could see multiple interpretations of certain statements and as the teacher kept going deeper, I felt like I had to execute a tree search algorithm in my mind to figure out what was the most plausible interpretation of the lesson. I did much better at university because I was learning from books and so I could pause and research every time I encountered an ambiguous statement. I went from failing school math to getting distinction at university level maths.

what compels software people to write opinion pieces. like you don't see bakers, mechanics, dentists, accountants writing blog posts like this...

Edit: to everyone responding that there are trade mags - yes SWE has those too (they're called developer conferences). In both categories, someone has to invite you to speak. I'm asking what compels Joe Shmoe SWE to pontificate on things they haven't been asked by anyone to pontificate on.

I mean, maybe if your background is mathematics this would make sense. But for a lot of us it isn't, we're more linguistically oriented and we certainly are not going to come up with some pure mathematical formula that describes a problem, but we might describe the problem and break it down into steps and then implement those steps.

[dead]