91–100 of 165 posts
You can get by with an "algebra" level understanding of programming. However, concepts such as recursion, and other metaprogramming don't really make sense at that level. You can make rote crud apps with an algebra level understanding of programming.
When it comes to deep level programming concepts, debugging complex apps - working on hard performance issues, I have no problem.
Earlier quoted context omitted.
Mathematics is also a "communication language with really strict rules". In one sense, programming often uses math. And math often uses programming. But, in a deeper sense, programming is math and math is programming. They're just different views on the same underlying ideas. They're different fields of study mainly because the priorities are so different. Of course, this doesn't mean it makes sense to map Objective-…
Mathematics can easily be applied to anything from cooking to theoretical physics. That doesn't make any of these things math or the other way around. You can use math to solve a programming problem (perhaps to a greater extent than in cooking) and you can express many of the problems in mathematical terms, but in the end math is an abstract tool and programming is not.
Rather, the relationship is between what a program is and the very foundations of mathematics--formal logic. In particular, a programming language is a formal system exactly the same way a logic is a formal system. A mathematical proof is really the same sort of object as a computer program. It just turns out that the goals behind the two are different, so the rules of the formal system (either a logic or a programming language) behave very differently. But, at a high level, it's the same idea.
In fact, the way we ascribe semantics to programs and programming languages is analogous to how we can reason about proofs and logics. As a rough comparison, denotational semantics are like model theory and operational semantics are (sort of) like proof theory.
That said, for the most part, this relationship to mathematics is actually orthogonal to the sort of math you would use in writing a program. Linear algebra, geometry, group theory and so on are great for applications but not what I was talking about. Instead, the mathematics I was alluding to only comes out when you get sufficiently "meta" and start writing programs that operate on other programs--static analysis, verification and so on.
I'm not sure what you mean by "abstract tool", but programming is just as much an abstract tool as mathematics. The only difference is that we have some handy hardware for realizing the former.
Programming isn't analogous to math, programming is a communication language with really strict rules that uses math of all stages. Different tasks involve different math. I'll give some common examples for laymen, but they may seem obvious in hindsight: Programming a very rudimentary "snake" computer game is [using] using Algebra. If your son (or anyone) understands variables, assignment and adding them together, th…
This seems like it should be so, but real world experience tells me it is not. Understanding how someone can understand one and not the other is beyond me, but its exceptionally common and a huge stumbling block for me to teach people programming.
The fact that we are usually writing relations in algebra, but instruction statements in programming is really quite significant, even if they look similar.
I would say that basic crud-level programming is equivalent at its base to pre-algebra but to get really good at it you have to focus on making it like geometry. Unfortunately too few programmers work on making the code well structured, maintainable, etc.
The second problem is that CRUD itself can mean all kinds of things. Again, at a basic level it is equivalent to pre-algebra, but to do the database side right, you have to appreciate and understand the stuff I learned in first year calculus. Much of this doesn't need to be taught there. But a strong, internalized understanding of terms like function, discrete function, etc are absolute prerequisites for db design.
My answer would probably be "all of the above."
The premise is flawed, in two ways.
First, programming is not math. It can be math-y, but that's not the same thing. Neither is programming any "level" of linguistics, even though it can be language-like at times. You can reason about certain aspects of programming by using math concepts, such as lambda calc, discrete logic, or Turing machines and similar constructs.
Second, and most importantly, math is not a valid measure of difficulty! Some people have an easy time with equations, but can't for the life of them figure out how loops work. With other people, it's the opposite. And it really is that trivial.
Earlier quoted context omitted.
Mathematics can easily be applied to anything from cooking to theoretical physics. That doesn't make any of these things math or the other way around. You can use math to solve a programming problem (perhaps to a greater extent than in cooking) and you can express many of the problems in mathematical terms, but in the end math is an abstract tool and programming is not.
No, the relationship between programming and mathematics is much deeper than that. In particular, it's not a relationship to the sort of mathematics you are thinking of--not the sort that you would use to solve a concrete problem or apply to physics or cooking. Rather, the relationship is between what a program is and the very foundations of mathematics--formal logic. In particular, a programming language is a formal…
When people program, they (usually) don't do math. And that's it.
The fact that you can view a programming language as a formal system, and the fact that computer programs can be viewed as mathematical proofs of mostly totally uninteresting propositions, doesn't magically turn programmers into mathematicians, just as the fact that the brain can be viewed as a chemical and physical system doesn't turn every thought into a chemical experiment, and each thinking person into a chemist.
Saying otherwise is just an abuse of language.
Programming isn't analogous to math, programming is a communication language with really strict rules that uses math of all stages. Different tasks involve different math. I'll give some common examples for laymen, but they may seem obvious in hindsight: Programming a very rudimentary "snake" computer game is [using] using Algebra. If your son (or anyone) understands variables, assignment and adding them together, th…
Earlier quoted context omitted.
No, the relationship between programming and mathematics is much deeper than that. In particular, it's not a relationship to the sort of mathematics you are thinking of--not the sort that you would use to solve a concrete problem or apply to physics or cooking. Rather, the relationship is between what a program is and the very foundations of mathematics--formal logic. In particular, a programming language is a formal…
This is philosophical mumbo-jumbo. When people program, they (usually) don't do math. And that's it. The fact that you can view a programming language as a formal system, and the fact that computer programs can be viewed as mathematical proofs of mostly totally uninteresting propositions, doesn't magically turn programmers into mathematicians, just as the fact that the brain can be viewed as a chemical and physical s…
Proving something in a low-level way--just following inference rules--and executing a program are basically the same things. This is abundantly clear if you formally study operational semantics, but even people who haven't still think operationally. Of course, nobody thinks purely operationally, but then again, practising mathematicians also rely on some poorly defined "intuition".
I never claimed this makes programmers mathematicians. It doesn't. Both fiddle around with formal systems, but the goals and the actual practice differ enough to make the two fairly distinct. But they're still related and we still use the same tools to analyze both: automated theorem provers, type theory, Curry-Howard...
The fact that I can bring advancements from formal logic to bear on analyzing programming languages and the fact that I can bring advancements from programming languages to analyze proofs means this is no mere "philosophical mumbo-jumbo". This includes all sorts of things you probably think completely removed from mathematics, like verifying properties of drivers or automated debugging.
Not only is it a deep relationship to think about, it's one we regularly exploit. Even if most programmers do not acknowledge it, it exists. Really, you're saying more about the state of programmers' education than anything else.
Besides, you never really made much of a point. You made a statement and a poor analogy in its support and accused me of "abuse of language", but never said anything substantial.