> 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.
It is that Mathematics is far more general and uses a myriad of notations developed over hundreds of years and adapted to various sub-fields/domains/models as necessary. This makes it far more flexible and powerful than any programming language. That is why Multi-Paradigm languages became a thing i.e. there is a need for programming languages to provide a larger set of computation models which can then be exploited by the programmer to map his domain models (mathematical or not).
For example; why do many(most?) programmers have difficulty in transcribing algorithms given in pseudocode to their favourite language? Simply because they have not understood the algorithm at the fundamental mathematical level but have only picked up the patterns through which it is expressed in their language. Note that this is the default way our brain works and how we manage real-world complexity without really understanding everything (satirically phrased as "monkey see, monkey do"). But we can use mathematical methods and reasoning to minimize going off the rails because it forces us to make explicit our assumptions, definitions and proofs which is at the heart of problem-solving. So we use all the mathematical tools we have at hand to structure and solve a problem and only later map it to our programming language. But note that as we gain more experience this mapping becomes intuitive and we can directly think and express it in our favourite programming language.
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.