7 ms·

> the average software engineer needs approximately none of that. Not true. He/She doesn't need to know all of it nor in depth but a conceptual understanding i

> the average software engineer needs approximately none of that. Not true. He/She doesn't need to know all of it nor in depth but a conceptual understanding is very much needed to write "correct" (w.r.t. a specification) code. We Humans are natural algorithmic problem solvers and hence can always muddle our way through to a ad-hoc solution for a given problem. Obviously, a lot depends on the intelligence of the individual here. What Mathematics gives you is a structure and concepts to systematize our thinking and rigorously apply it so that problem solving becomes more mechanical. Thus you learn to specify the problem rigorously using mathematical concepts and then use mathematical logic to derive a "Program" satisfying those requirements. At the very least a knowledge of Set Theory, Logic and Relational Algebra goes a long way towards understanding the mapping from Mathematics to Computer Programming. The following books are helpful here; 1) Introductory Logic and Sets for Computer Scientists by Nimal Nissanke. A very nice overview and wide coverage of needed basic mathematics. 2) Understanding Formal Methods by Jean-Francois Monin. A fire-hose overview of mathematical models and tools implementing those models.

cubefox 1y ago
> At the very least a knowledge of Set Theory, Logic and Relational Algebra goes a long way towards understanding the mapping from Mathematics to Computer Programming. I know all these from university, but I did programming and SQL before that without any issues. Learning these mathematical details seemed really not useful in practice, at least for me. Of course, coming up with something like SQL in the first place requires a lot of theoretical mathematics (set theory, relational algebra), but as someone who only uses those systems, like 99% of software engineers, understanding the mathematical theory here doesn't seem very helpful.
- rramadass 1y ago
  I am afraid you have not really understood the mathematical theory and its mapping to programming. Relational Algebra doesn't just mean RDBMS/SQL but is a general algebra where algebraic Operations are defined over mathematical Relations i.e. over a Cartesian Product of one or more Sets. As a first approximation; a) Type = Set b) Function = subset of Relation (i.e. set of Tuples) obtained from Cartesian Product of {input type set X output type set} c) Logical conditions define new relational sets where its members have a ordering relation d) A Program is a series of functions which prune and transform the tuples from the above cartesian product.
  - cubefox 1y ago
    Well, I'm familiar with model theory and Church's simple theory of types, but I don't think things like that are useful in practice. Perhaps the concept of currying would be an exception, if I were a Haskell programmer.
    - rramadass 1y ago
      I am not sure that you have really understood the topics you have named. All high-level programming languages give you a set of fundamental types and the ability to construct user-defined types. Currying is not an exception but falls under the same model if one considers it as a Relation between "sets of functions". Also by Curry-Howard correspondence you have "formula/proposition = type" and "proof = function". So you have a direct mapping between Sets/Relations/Logic in Mathematics and Types/Logic in a Program. A Program then becomes a trajectory enforced using predicate logic through a state space obtained from the cartesian product of all the types in the program. You are using all of the above whether you know it or not when programming in a high-level language. The real value comes when you do it with the knowledge of the mathematics in hand because then it allows you to prove your Program as "Correct" (w.r.t. a specification).
      - elderhammer 1y ago
        [dead]
      - cubefox 1y ago
        > You are using all of the above whether you know it or not when programming in a high-level language. Exactly. The average programmer doesn't have to know the math behind things like types to use them. > The real value comes when you do it with the knowledge of the mathematics in hand because then it allows you to prove your Program as "Correct" (w.r.t. a specification). I don't think the average software engineer does that or would benefit from doing it. I certainly don't.
        rramadass 1y ago

cubefox 1y ago

> At the very least a knowledge of Set Theory, Logic and Relational Algebra goes a long way towards understanding the mapping from Mathematics to Computer Programming. I know all these from university, but I did programming and SQL before that without any issues. Learning these mathematical details seemed really not useful in practice, at least for me. Of course, coming up with something like SQL in the first place requires a lot of theoretical mathematics (set theory, relational algebra), but as someone who only uses those systems, like 99% of software engineers, understanding the mathematical theory here doesn't seem very helpful.

rramadass 1y ago
I am afraid you have not really understood the mathematical theory and its mapping to programming. Relational Algebra doesn't just mean RDBMS/SQL but is a general algebra where algebraic Operations are defined over mathematical Relations i.e. over a Cartesian Product of one or more Sets. As a first approximation; a) Type = Set b) Function = subset of Relation (i.e. set of Tuples) obtained from Cartesian Product of {input type set X output type set} c) Logical conditions define new relational sets where its members have a ordering relation d) A Program is a series of functions which prune and transform the tuples from the above cartesian product.
- cubefox 1y ago
  Well, I'm familiar with model theory and Church's simple theory of types, but I don't think things like that are useful in practice. Perhaps the concept of currying would be an exception, if I were a Haskell programmer.
  - rramadass 1y ago
    I am not sure that you have really understood the topics you have named. All high-level programming languages give you a set of fundamental types and the ability to construct user-defined types. Currying is not an exception but falls under the same model if one considers it as a Relation between "sets of functions". Also by Curry-Howard correspondence you have "formula/proposition = type" and "proof = function". So you have a direct mapping between Sets/Relations/Logic in Mathematics and Types/Logic in a Program. A Program then becomes a trajectory enforced using predicate logic through a state space obtained from the cartesian product of all the types in the program. You are using all of the above whether you know it or not when programming in a high-level language. The real value comes when you do it with the knowledge of the mathematics in hand because then it allows you to prove your Program as "Correct" (w.r.t. a specification).
    - elderhammer 1y ago
      [dead]
    - cubefox 1y ago
      > You are using all of the above whether you know it or not when programming in a high-level language. Exactly. The average programmer doesn't have to know the math behind things like types to use them. > The real value comes when you do it with the knowledge of the mathematics in hand because then it allows you to prove your Program as "Correct" (w.r.t. a specification). I don't think the average software engineer does that or would benefit from doing it. I certainly don't.
      - rramadass 1y ago