(Please remember that voting does not up vote the poll.)
Programming a very rudimentary "snake" computer game is [using] using Algebra. If your son (or anyone) understands variables, assignment and adding them together, they fundamentally understand Algebra.
Programming a the general parts of a diagramming library or a game with some physics is [using] Geometry and Trig.
Programming complex features of a diagramming library involve discrete math and graph theory.
Programming diagramming layouts can involve Masters level math understanding. (Sometimes, even when the algorithm is well known, it can take months to understand and implement, like planarity testing and embedding before 2004[1])
So it's roughly analogous to the difficulty and specificity of the task, which varies wildly.
~~~
[1] in 2004 there was a fast and "easier" to understand planarity testing and embedding algorithm, I suggest you skim it for an idea of the kind of math programmers can get into: http://jgaa.info/accepted/2004/BoyerMyrvold2004.8.3.pdf
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-C programming onto some "level" of math. For one, the whole math scale is completely arbitrary--who is to say that abstract algebra is more advanced than calculus? They're orthogonal. Moreover, Objective-C is in a part of programming which has really, really different priorities from normal mathematics. I still maintain that they're fundamentally related, but you're doing such different things that there's very little practical overlap. Certainly not enough to translate to some common sub-field of mathematics, much less one taught to high-schoolers!
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.
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.
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.
In this sense, programming is much more algorithmic, and hence I would argue, not particularly like math (the content) at all.
We all get it, and we all agree - programs can be viewed as a subset of mathematics. Every CS undergrad knows this. It is conceptually misguided to view this piece of information as revealing anything deep about what programmers do, just as it is conceptually misguided to view our ability to reduce both fishing and singing to brain activity (or to reduce everything to the laws of physics) as saying anything deep about what fishermen do. It doesn't became any less misguided simply because examples exist where math can be directly applied to programming, and vice versa.
It is philosophical mumbo-jumbo because you are taking two activities with clearly distinct meaning in everyday language, and instead of simply acknowledging that we can invent a new meaning for them under which they are the same, you instead convince yourself that this new invented meaning is the only fundamentally correct one (or somehow "deeper"), and that it also has the power to show that the 'everyday' meaning is wrong. But you are not showing anything about things we already know - you are simply presenting new, different ways of looking at them, that bear little relevance to the question at hand (A circle is topologically equivalent to a square. Does it mean that our 'old' preconceptions of difference between circles and squares are now wrong?).
The activity of doing mathematics, as those words are used in everyday language, is different from the activity of programming, even if in some senses (perhaps in more than one) they can be viewed as the same. The activity of running is different from the activity of fishing, even though they can be reduced to similar building blocks.
I do not object to the mathematical connections you present, I object to the philosophical interpretation you give to them.
I disagree. Whenever you implement an algorithm, you build a proof of correctness in your mind. If you reasoned about your program and are convinced that it handles all corner cases properly, then it would only be a formality to write this proof down. If you can't easily do that, then you can't possibly be certain that your program has no bugs.
In practice, you don't bother with this kind of thing unless you are writing extremely complex algorithms, of course, but that doesn't change the underlying principle.
Almost everybody else who writes programs isn't thinking in terms of mathematics, be it of computing or any other thing. Asking "what level of mathematics is this equivalent to" is therefore kind of a nonsense question--it has no real answer, because it implies there's a legitimate comparison to be made when there isn't.
Anything beyond understanding some basic Algebra and Geometry concepts isn't required in order to program.
Most of the stuff (at least that I have run into) is just organizing data into a visual (like a report or graph) that will allow someone to make informed decisions. This only requires basic math (averages, percentages). If you can filter data, perform basic math functions on that data, spit it back out onto a report or graph then you can program for the majority of business needs.
The only time advance mathematics would be needed is if you are coding for scientists/mathematicians that want to apply advanced math to their data.
> I'm not sure there is such a difference between mathematics and an "algorithm"
This is like saying: "There isn't such a difference between neurology and physics. A brain can be viewed as a collection of cells, which in turn can be viewed as a collection of organic molecules, which in turn can be viewed as a collection of particles, and physics studies particles. So neurology = physics. Q.E.D"
But what is missing here is the realization that it is exactly our decision not to view the brain as a collection of particles which gives neurology it's meaning. The decision to view something as something else is not trivial. When you choose to view X as Y, it is no longer X you are talking about.
You wrote: "...it just may not be the kind of mathematics we usually associate with the word."
But it is precisely what we "usually associate with the word" which gives meaning to words. If in this "usual" meaning it is wrong to say that mathematics is the study of algorithms, then mathematics isn't the study of algorithms.
When we want to create new precise definitions to old words, what we are trying to do is to formulate a description that fits as best as possible our everyday use of this word. If we ended up with a definition of math that says "the analysis of everything is math", the only logical conclusion is that we did a pretty bad job.
Programming a first person shooter requires linear algebra. Programming crypto-algorithms require discrete math.
I think it's analogous to math in the sense that a programming language is a formal system, just like any logical system. The syntax is defined by formal rules, it semantics if not defined formally is strictly defined by the compiler implementation or hardware.
Actually, the link between programming and proving as been characterized by the "curry-howard isomorphism" that says that a program is a proof of his type. In that sense, programming = writing a proof.
For instance, in ML : the program "fun (x,y) -> x" is a proof of the proposition "A and B => A". This idea can be extended to more complex types/propositions (see the Coq proof assistant for instance).
That being said, writing programs usually require different set of skills than doing mathematics. The best programmers are not always the best mathematicians and conversely. To me difference shows especially for big complex software, rather than smart algorithms in programming contests for instance.
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.
In a direct use way - any time you program with conditionals you are directly applying boolean algebra. There is no way around it - you have to understand how the basic rules of boolean algebra work. e.g. how does 'not' distribute, how do "AND" and "OR" work, etc. And it certainly helps with simplifying code if you can apply DeMorgan's law or distribute your conditions differently. There is a reason it's called refactoring code - it is just applying the algebra rules (usually the boolean ones) to program flow.
Similarly, but a bit more abstract, string primitive operations are an algebra for working with series of characters. They are equally strict, although not the exact same rules as those for points on a curve. For instance associativity doesn't apply to addition. Multiplication isn't defined for some languages, and there are different ways to define it for other languages (does it distribute, etc). This isn't even that abstract...
Given a string, solve for the character at position x. This is not really different than given a function, solve for the position at x.
Given a function, and value y, solve for x. Its the same as given string, find the indices for a character.
The operations are a bit different, but the reasoning between them is exactly the same: manipulate the givens with the rules that are defined. Use the rules to find properties of the target.
[1] there are other algebras - for example ring theory algebra. It has rules that are different (mostly generalizations of basic algebra rules, but that have weird and non-intuitive results if all you know is basic high-school algebra). This sentence from the wikipedia article explains it well:
"It follows that algebra, instead of being a true branch of mathematics, appears nowadays, to be a collection of branches sharing common methods."
I don't know that well-known algorithm, and neither does Google, it seems. At least, I can't find it, and can't see how it would work. Now, section 5 has a procedure that requires <= 3n-5 edges for a graph with n vertices. Is that supposed to hold throughout? If so, what's that 3n-5 about? Are there well-known theorems or algorithms to disprove planar it's for such graphs?
A more important part of algebra is symbol manipulation, and understanding why some manipulations are valid and others are invalid. That symbol manipulation is the core of grade-school (or trivial) algebra. Being able to 'see' how to solve a problem, and being able to abstract general rules to solve whole classes of problems, all flow from that.
Of course, there's a disconnect between using '=' to denote a state of being (the state of equality) and using '=' to denote an action (the action of assignment). As an example, 'x = x + 1' is either trivially nonsense or trivially valid. Haskell actually uses '=' in the mathematical sense, to denote a state of being, and SSA languages such as Erlang come pretty close to it, I think.
Some people program insightfully, or so I am told by people who program, and other people program nothing but kludges. Among mathematics learners, there are great variations in the levels of "profound understanding of fundamental mathematics" (PUFM) among people who are studying the "same" level of mathematics. It interested me that you mentioned neither number theory nor combinatorics among your list of secondary mathematics courses, because in some other countries, those courses would come well before calculus. In general, any reader of Hacker News could learn a lot about what is missing in the United States (or, more generally, in the English-speaking world) in elementary mathematics instruction by reading Knowing and Teaching Elementary Mathematics: Teachers' Understanding of Fundamental Mathematics in China and the United States by Liping Ma.[1] There is a lot to basic mathematics that is far from easy, if deep understanding is what you are looking for. In the countries that excel over the United States in mathematics instruction, proof is part of every mathematics course, not just part of geometry, for example.
[1] http://www.amazon.com/Knowing-Teaching-Elementary-Mathematic...
There's room to wonder about how much of a causative role this has, and how much it reflects consumer demand. When my sister started taking algebra, my parents asked me to help her, and I was careful to provide proofs of all the algebraic properties of exponents (e.g. x^m * x^n = x^{m+n}; x^0 = 1; like that). That's not usual in the US, and didn't feature in her textbooks or supplements, but I did it basically just because it was important to me.
Can you expand on that? What do students do in other mathematical areas if they don't do proofs? I did all of my studies in France and I don't how much of a difference there is (though all my friends who have studied both in the US and in France found the maths classes a lot easier in the US).
The book I already mentioned, Knowing and Teaching Elementary Mathematics, will give much of the sad story. A really sad description of how mathematics textbooks are written in the United States[1] and a contrasting description of what kinds of problems are found in Russian textbooks[2] fill in more details.
It was on my second stay overseas (1998-2001), that I became especially aware of differences in primary mathematics education. I discovered that the textbooks used in Singapore, Taiwan (and some neighboring countries) are far better designed than mathematics textbooks in the United States. (During that same stay in Taiwan, I had access to the samples United States textbooks in the storeroom of a school for expatriates, but they were never of any use to my family. I pored over those and was appalled at how poorly designed those textbooks were.) I discovered that the mathematics gap between the United States and the top countries of the world was, if anything, deeper and wider than the second-language gap.
Now I put instructional methodologies to the test by teaching supplemental mathematics courses to elementary-age pupils willing to take on a prealgebra-level course at that age. My pupils' families come from multiple countries in Asia, Europe, Africa, and the Caribbean Islands. (Oh, families from all over the United States also enroll in my classes. See my user profile for more specifics.) Simply by benefit of a better-designed set of instructional materials (formerly English translations of Russian textbooks, with reference to the Singapore textbooks, and now the Prealgebra textbook from the Art of Problem Solving),[3] the pupils in my classes can make big jumps in mathematics level (as verified by various standardized tests they take in their schools of regular enrollment, and by their participation in the AMC mathematics tests) and gains in confidence and delight in solving unfamiliar problems. More schools in the United States could do this, if only they would.
[1] http://open.salon.com/blog/annie_keeghan/2012/02/17/afraid_o...
[2] http://www.de.ufpe.br/~toom/travel/sweden05/WP-SWEDEN-NEW.pd...
[3] http://www.artofproblemsolving.com/Store/viewitem.php?item=p...
The structure of formal proofs is taught in geometry. That's pretty much the only course where students are expected to prove theorems about the subject via proofs. In most of the other courses students are taught the formulas and techniques, axioms and theorems, but then apply them, rather than attempt to develop or prove them themselves. They're also, typically, not shown a proof of the theorems they learn, they're just told to accept them.
Wow! I can't even imagine how that works. When I went to school (and that's in Europe, not Asia), the notions of theorem and proof were taught in the fifth year of school (out of 12 pre-college years -- 8 in elementary, 4 in high school). That was, indeed, as part of geometry. Starting from high school, however, pretty much no formula is given without prior demonstration. Subjects where they can't do that (like mechanics -- that's taught in Physics prior to pre-calculus and calculus) are a royal fuckup. You aren't usually expected to be able to reproduce the proofs for those formulae, but a) you're strongly encouraged to study them, because they help you with the exercises and b) it's usually implied that, if you can't remember the formula, but you can prove it, it's OK. For example, if you can't finish a problem in a test because you don't know the formula, but you obviously try to find it, the professor will sometimes give you full credit, depending on circumstances and following a short talk.
I didn't even like math back then, save for geometry, but I reckon this was the most important thing I learned there. Unless you're dumber than a toaster, you're typically able to apply what you learned to everyday phenomenae after ten years of school; the bonus you get is also being able to reason rigorously and correctly, which is an important takeaway no matter what path you choose to follow.
At whatever level of Math (or any subject) you develop this skill, you are ready to be a programmer.
Disclosure: I'm a full-time tutor for third and fourth grade mathematics in the inner city through the Denver Math Fellows program ( http://www.teachindenver.com/teachindenver/denver-fellows-pr... ).
Programming can be a mix of many things: reasoning about associations and state, designing processes or interfaces, or—most saliently—modeling a domain that may or may not mathematical in nature.
To compare a programming language/runtime with a US math curriculum makes about as much sense to me as asking for the Richter magnitude of a sledgehammer.
>what cognitive level is bog standard, journeymen, CRUD programming in Objective-C?
He should probably have clarified it in the title
> bog standard, journeymen, CRUD programming
What do you think are the cognitive demands of that task, however defined?
Just like math, you can go as deep into a programming language or concept as your mind will carry you so there's no equivalence relation.
The "cognitive load" or whatever is really just a function of how much you've practiced and internalized that area of math. Calculus builds on algebra, sure, but once you've internalized algebra you don't have to "think real hard about algebra" _while_ you "think real hard about calculus."
Running a 10k for the first time is not the same as running your first 5k twice.
But I guess my point is that programming at an "Algebra" level means you have very little knowledge the language, while programming at a "Calculus" level means that you have much more knowledge.
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.
Could we say that programming is: part codified reasoning, part automation, part creative practice, part figuring out how computers and networks work, part figuring out how your toolkit works, part figuring out how the platform your coding against works?
I guess that it is only mathsy insofar as the problem domain is mathsy.
I see a whole wave of non-sciencey people learning how to code in the near future. These people are not very math-oriented.
Which, in the case of the OP, seems to be "My son is awesome."
Under such a worldview, my personal view of the mental requirements of a simple CRUD type of task is that the ability to apply definite rules called for in the "algebraist" approach is closest (and extremely necessary). I've read many comments that beginning programmers can have a hard time understanding that the computer will do exactly what you tell it to do, and nothing else; applying algebraic rules is a very similar concept.
Geometry is an unpopular choice in your poll, but I think it has some of the same flavor of recognizing that "by labeling this complicated term 'x' and this other complicated term 'y', we can transform the current state of the problem into exactly the preconditions for theorem T" that I'm thinking of.
Anyway, overall I vote for algebra 1.
Similarly, "pre"-calculus. It came before calculus. Does that then include the ability to tie my shoes? I learned it before calculus.
When I took math classes in college it all made more sense. OK, you have course sequences, where you look at one thing one semester, another thing the next. But that was always a recommendation; you could take them out of their numbered order. And usually the title of the class was a topic, not just a number.
You don't need any of high school math unless your specific application requires it (i.e. graphics involves polygons, anything quantitative involves arithmetic and unit conversion, you may want to report percentages and averages at some point.)
Things I remember from K12 math classes that were useful for programming in general:
- What variables are
- What functions are
- You can compose functions (this was obvious because I had been programming for 5+ years before function composition was introduced)
- Very basic set theory (Python list comprehensions resemble set-builder notation)
- Introductory propositional logic (though I learned this in the context of programming 7 years before I was "ready" for it in math class)
Learning to prove things about triangles (geometry) exercises some of the same skills as programming, but I wouldn't say it teaches them. Certainly none of the theorems or facts have ever been useful, just the process of reasoning.
As for me, I have taken math to the level of Differential Equations and Linear Algebra.
- Want to even think of committing to scalaz/haskell? Category theory
and lambda calculus.
- Want to develop a physics engine for a modern 3d shooter?
Geometry, trig, single/mutli-variable calc, algebra, and differential equations.
- Want to do some NLP? Discrete math, automata theory,
not to mention a strong background in linguistics.
- Want to do some ML? Bayes statistics.
- And so on..
Edit: This was prior to OP clarification. :)
I still remember getting to college thinking I was hot shit because I learned calculus as a freshman in high school, and then realizing I had no clue how to construct a proof. Calculus is taught in schools because it's how you send rockets into space, and in many STEM professions it's a dead-end that isn't all that useful for the job.
I'm going to hazard a guess that you could teach it to most children his age although perhaps not as fast. I think the main obstacles being motivational and esoteric, not cognitive.
Not sure I like the structure of the poll choices either. Does anyone really think that trigonometry is at a higher cognitive level than the classes that are taken before it?
Programming is a progression from being able to give logical directions and knowing some simple arithmetic and commands all the way to knowing all kind of obscure things from discrete mathematics and linear algebra, perhaps with some application of things from calculus, statistics, and trigonometry occasionally thrown in.
However, what will separate proper journeyman code from mush is design and organization, something which is not entirely in the realm of math. There's a reason that programmers talk a about design patterns and waste a lot of time naming things.
So in a sense the cognitive root and differentiator of journeyman code is more analogous to the root of an understanding of architecture and planning than math.
Keep in mind that many professionals (occasionally myself included) do not even write journeyman level code.
But i guess this is a difference between extraverted and introverted thinking.
(1) It has relatively few pre-requisites in comparison to advanced calculus (which I'm assuming means something like a first course in real analysis).
(2) It isn't rote. There's more creative thought involved in solving problems. Even high school calculus is often extremely rote. I think programming is rarely rote, even if it's just a CRUD app. You have to strategize about how to approach the overall architecture of the program and make predictions about how early design decisions will affect future extensibility and more.
My first course in real analysis didn't have much in the way of prerequisites at all. I loved it because everything was covered ground up (including concepts like "limit").
There's a reason most universities require students to have completed the entire calculus sequence and often even a special "introduction to proofs" class before exposing them to a book like Rudin's.
At a basic level, programming and algebra have a few key things in common (variables most notably), and more generally you'll probably end up using math to solve some common problems that come up in programming; that won't really rise to the level of advanced mathematics, though, beyond roughly algebra plus linear algebra.
More importantly, though, math and programming are both heavily about learning, seeing, and applying patterns. Algebra, trigonometry, geometry, calculus, discrete math, and linear algebra all give you a toolbox of patterns to apply. Likewise, the more you learn about programming (or more generally CS), the more you have a toolbox of patterns to apply. Both heavily involve analytical reasoning and fast pattern matching against a vast set of possibilities. In other words, both of them bend your brain in many of the same ways, and they cross-train incredibly well.
Therefore I don't think it should be compared with math. Unless you are writing a program for a very specific scientific problem that requires the elaboration of a mathematical model.
Usually the computer does all the math, all you need to do is type the operations you need it to calculate.
I'm not saying they're completely unrelated, I just think linguistic skills are more relevant in most cases
There are certain levels of math or logic needed for various programming tasks, but it is not 'analogous' to any level.
For example, function composition is very useful in programming and thus Algebra (or was it Algebra 2???) comes in handy for understanding that at a basic level.
However, if you're doing graphics programming, then you often need experience with geometry (composition of basic shapes to form more complicated shapes, linear algebra (matrix operations), and modern algebra (quaternions).
The answer depends on how great you want to become. Take as much math as possible to find the best solutions. I come from a background of the hard sciences, I never took programming in college and I was able to pick it up quite easily because of my strong foundation in mathematics, analytics and logic.
I would put it into these terms, however, for simplification.
Coding simple programs is probably analogous to algebra/functional logic.
Having a 3-D model of workflow process with escalation loaded into your mind when you're working on an architecture is more akin to calculus. Add User Experience and network requirements into the mix and the skill is more akin to writing an Overture and the Opera. At this point you have a different animal than described above.
That said, I spend 90% of my time writing geometric analysis libraries, so I am biased.
Some programming problems require specific areas of mathematics, some others, some none at all. All programming, as well as all real mathematics, require the ability to reason logically about a problem.
Based upon this understanding, I can't chose any of the poll options, but if I had to, I'd go with geometric proofs as well.
I want to offer a few clarifying points: We homeschool. My son likes math but does not like the 'busy work' associated. Mom was wondering if my son just didn't get long division, ratios, and fractions. I was thinking that if he can program js, awk, lua, and objective-c then he can do anything that arithmetic might demand of him.
In other words I intuited a character issue not a cognition issue and wanted other opinions.
Also, I really do understand that programming cannot strictly be equated with math. I purposefully used the word analogy because they are not 'fungible' things. In fact the term analogy connotes that I understand that there is a resemblance in some particulars between things that are otherwise unlike.
I posit that the resemblance is effort of cognition (though, of course, some might disagree that there is even that point of connection).
Another common misunderstanding was that I was asking how much math does my son need to know/learn to be a programmer (or otherwise). We will explore the very limits of his education (sane, practical, healthy limits); that's the whole point of us homeschooling him. Once he hits mom's limit in any given realm we will out source. I hope his current love of math/science/writing will know no parental impediment.
there is relatively little utility in learning arithmetic by rote and its not surprising that your son doesn't want to do it. however, as I'm sure you know, rote arithmetic problems are present on state exams and your son will need to be able to do it in order for his home schooling (which is great, congratulations to you) to be officially recognized.
there's a certain point at which the learning process stops being about gaining knowledge and skills, and starts becoming more about learning how to conform to institutional requirements. this sucks. it sucks real bad. you already know this though, which is probably one of the reasons why you chose to home school. unfortunately sucking it up and learning how to play ball with the institutions of our society is actually a really important thing, painful and boring as it is. long division by rote is some kind of proxy for this. better get started with building up your son's tolerance for annoying shit.
Don't knock rote mathematics. 'Busy Work' in most other fields is called 'practice'. And like all things, practice is the key to improving a skill. Repetition, memorization and muscle memory are all key fundamentals.
If your son wants to be a quarterback, you practice throwing a football. Over and over again with slight variations to the angle, distance and speed. A meaningless procession of skill building that builds the muscle memory and "know how" required to be successful at the more complex task of managing a game and leading an offence, which is what a quarterback really does. You can't be good at throwing to a receiver on a button hook or on a screen play if you are still mastering how to manipulate the speed and position of the ball as it leaves your hand.
We would laugh in the face of anyone that suggests otherwise.
Your brain is no different. It needs practice in the basics before it can progress to more advanced topics. You need to spell before you can write a story, and you need to know addition and multiplication before you can perform calculus. The basics for math need to be implanted in your brain for immediate retrieval, so that your processing power can focus on the higher level task.
It's not enough just to know that "there" can be spelled three different ways. To be a good writer, you need to know instantly which one to use when, otherwise you just simply aren't very efficient. Likewise, a person needs to know instantly that 8 and 64 have a distinct factor/product relationship to be able to understand that a rectangular floor with an 8 foot length, 3 foot width and total area of 64 square feet cannot possibly exist and has been measured incorrectly before you proceed to buy all that carpet.
The most skilled in any field have the greatest mastery of the basics. Mathematics is no exception.
Given that, programming is everything and anything. Which is why a good programmer would always focus on the problem not the knowledge required to solve the problem. Because if you embark on tough project, find solutions is essentially like making a discovery.
In my opinion you shouldn't ever first learn books(apart from the very basic ones) and then go in search of problems. The right approach is to look for problems, and while solving them and you can learn the knowledge required to solve those problems as you go along.
Programming is analogous to nearly everything in math. Programming is only a tool, which you can use to solve various problems around yourself modeled in some mathematical form(In short everything).
Which is why programming is the most awesome profession ever. Because by nature it lets you probe and grok the nature, working and science behind everything. That is why programmers are so good at problem identification, solution design and problem solving in general.
Similar to your son, I have been programming since an yearly age. We had Macromedia Flash back then, and over the course of my academic life, as i progressed in the Mathematics courses, my programming capabilities increased with leaps and bounds. For example, the movement in my games was usually similar to Pacman or bomberman. No arcs, or curved paths existed. As i learned about 2D motion, i started making Platformers. As i learned trigonometry, I started making games involving curved paths on a 2d plane. Even a realistic Car game. i remember coming home from high school the day they taught us about "Radians" and began usign the sin, cos, tan funtions of ActionScript (because the documentation said it used Radians and that never made sense to me before). It was that very year i programmed game AI that would chase the player in a realistic way.
So yeah, math helps
Also, memory, which is all we are manipulating at the end of the day, is linear; points on a line.
RAM is equivalent of "tape" in a Turing machine. If its anything resembling linear for any amount of time, the machine would not be Turing complete ... and therefore a not very interesting programming language/model.
Consistent, in software at least, is the concept of memory being linear; references using a start and end point, and points between.
Programming is recipes for a computer to follow. In many cases there is Zero math involved. You can write plenty of Data Entry code and never use a single numeric function.
Conversely you could write a single line of code that required all the math skills of a Quantum Physics Doctorate.
Programming is not "math" it is recipe authoring. It is more analogous to home ec than Dif-e-q
Numbers are not math.
(Anyway, I agree that the poll is strange.)
HN makes me sad these days
I don't remember feeling too challenged when I learned algebra. It wasn't until I got to trig and calculus that I really started having to stop and think hard.
As for my career, I've turned out to be an above average programmer but not superstar level. And I haven't lucked into any big dot-com jackpots, though I've tried.
So in my opinion, your son is probably smart and could do well, especially if he learns how to stay focused. But I don't think his programming at 11 is necessarily proof that he is a genius or anything like that.
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.
In that vein, I'm not saying you need to literally know algebra, just that it's a parallel kind of progress.
The point being that if you know algebra well, you can do useful things with math. In a similar vein, if you know functions well, you can do useful things with programming.
Creating a software solution (program or app, whichever is it called these days) goes beyond programming/coding it, and it often depends on the problem you're trying to solve aka the problem domain or simply domain. That's why creating an mobile app to track a list of things to do on a person's day requires a different process for creating it than creating a solution for an self flying aircraft, weapon, banking, or medical system.
So, I don't think programming in general is bound to any math level. Some systems may require some specific math in order to create an adequate solution for them.
The problem arises, in that I adored maths, and had amazing teachers , and my father is an engineer and would sit me down every week and teach me more about maths, so how much can be attributed to programming, is hard to say. All I know is that variables introduced in the classroom made the class look at me funny when I pointed out how they worked when programming, in grade 6!
While I know the definitions of each term, I'm unclear on what exactly 'Pre Calculus' would be in this case. Also, is Trigonometry higher than Algebra or Algebra 2, if that question even makes much sense? Finally, what are the differences between Algebra and Algebra 2, and Geometry and Geometry 2?
However, it can be a great motivator to learn new areas of mathematics.
Consider a simple game engine: writing a program that displays sprites on screen and moves them will build an understanding of basic coordinate systems. Collision detection requires slightly more advanced math in that coordinate space. Pathfinding (say, for enemies chasing the player) requires all that, plus basic trig, plus some understanding of randomness and probabilities.
Particle behavior (for weapons, jump physics, etc.) begs for calculus. Error-handling can be a great intro to the difference between total and partial functions, etc. etc.
This was a huge motivator for me in learning mathematics both during my time in school and beyond. Instilling a love of problem-solving through coding is a great way to put your kid on the route to continuous learning.
Sure you might be able to do it with a knowledge of nothing more than basic arithmetic, but you're going to be able to understand and manipulate data more efficiently with a solid understanding of algebra.
That being said, Objective-C isn't the easiest language to pick up, especially as a first language. If your 11 year old starts to struggle, maybe point him at something like Python which has a shallow learning curve, great support (especially for beginners), and can do pretty much anything (ignoring the argument of whether it _should_ be used for things like drivers).
If your son chooses software engineering as a career. Advanced calculus may well be required. I've had to debug complex legacy code before that implemented computations rooted in calculus and without that knowledge, I wouldn't have been capable of succeeding.
Just an opinion.
Anyway, we had two logic courses (Introduction to Logic and Advanced Logic) which also have close connections to programming.
programming has an "advantage" over math in that you can just program something and see what happens and therefore gain an intuition and craft your way around things. mathematics is much more deprived in this respect, for a variety of reasons.
overall i would describe programming as a precise form of writing, whereas math is a very pure science
First, how much math does he have to know to be able to program problem X? Depends on what problem X is. This is true, but I don't think it's the question that is being asked.
Second, how much math does he have to know to be able to reason formally in the way that programming requires? That's being discussed, a little, and I think that's the question that was asked. (For what it's worth, my answer is algebra or geometry, at least for a beginning programmer.)
Third, how much math is needed in order to be able to handle the formal notation of something like Objective C? I don't think that's the question that was asked, but maybe it's a question that ought to be asked. (My answer to this one is probably geometry, maybe even trigonometry.)
Note that if you're doing game development, a higher level of math will be required, than if you're writing a crud application that talks to an api; in the latter, understanding linguistics and a good common sense are more important.
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."
One premise of this survey is that math and cs are both "sequential" -- which is FALSE. And the survey assumes the Math and CS sequences can be placed in parallel. This is an artifact of the "grade" systems in school.
The two winners in the poll are "algebra" an HS subject and "discrete math" which is usually taught in college. And I am surprised to see how few people chose geometry :-(
In university, Engineering departments and physical sciences departments teach math to their own students in parallel with more abstract treatments in a math department.
I bought a copy of "Robot Vision" and it's basically multivariate calculus with awesome pictures!
I think that this says more about the level of programming that people are doing than how hard programming is.
So far, my vote is for Calculus.
While a knowledge of functions is vital to understanding Calculus (the fundamental theorem of calculus depends on them), it's only a small component of the bigger picture. Calculus is mainly about how functions change with respect to some other variable (time is common) and the inverse of that operation.
Programming is completely equivalent to constructive Maths (see http://en.wikipedia.org/wiki/Constructivism_(mathematics) ). Constructive Maths is basically regular (classical) Maths, with the acknowlegement that the halting problem is undecidable. One major consequence of this is that we can't use the Law of the Excluded Middle (ie. "for all P, P or not P").
There's some really interesting research going on here that's far outstrips 'advanced calculus', for example take a look at Homotopy Type Theory.
I learned programming before I learned how to manipulate variables in math, and my prior knowledge helped me figure out how to deal with most of algebra.
Could an 11 year old dive into the CRUD with an 11 year old's mathematical knowledge? Absolutely. Will he/she have the ability to rough it through debugging challenging problems that may emerge without the years grit developed as a result of solving difficult calculus and linear algebra problems? Possibly. Perhaps not.
Either way, you sound like an awesome dad :) I say let him have at it!
For example, I have implemented standard signal processing and acoustig echo cancellation algorithms, in both C++ and Java. I happen to have a MS in EE and a BS in CpE. Now, take someone with a CS degree (not CpE.) They may be amazing programmers, but they will have a very tough time understanding the math behind these algorithms--It's all about the domain!
Pre-Algebra / Discrete : Basic variable substitution and functions
Geometry : Drawing 3d figures and graphics
Calculus & Trigonometry : Physics engines
That said, I would say the "ways of thinking" are very similar more than anything. It is similar to things like real/complex analysis in that sometimes you just need a clever solution, but it is similar to something like abstract algebra in that sometimes you just need to hold a lot of information in your head all at once as you go through a long chain of logic.
The correct answer is abstract (modern) algebra.
Having said that I've made build 3D engine all the way up from rendering 2D triangles (had to watch quite a few videos to get the maths right).
This is definitely an apples to oranges comparison.
Depending on what he's actually doing with that data, though, the level may change. Got links?
Many mathy programming languages exist in different dimensions of mathiness. To name a few: Haskell and/or F#, Lisp (specifically Clojure, in my opinion), Julia, R, J, Forth and/or Factor, or PostScript (the language of many printers) Logo, Erlang, etc. All mathy in different ways.
Any one -- Python or Clojure for example give you different sets of rules that you can use to manipulate the symbols of their language the same way different fields of mathematics give you different rules for manipulating the symbols of their language.
In general the better you are at understanding one the better you are at understanding the other.
They often collide more directly. Linear algebra is helpful in machine learning. Geometry and trig are helpful for ray tracing. Geometry is helpful for understanding multidimensional arrays in programming languages. Social sites like Facebook use graph theoretical algorithms to manage and mine their data for big bucks. The mathematical forumla of Bayes theorem figures prominently in many machine learning applications but also rationality, artificial intelligence, statistics, etc. You get the idea.
Most programming languages have a built in notion of a set which is fundamentally identical to the mathemtical concept of a set with the further restriction that the only types of objects you can put in a set are values of that language's data types and you have to refer to the null set as something else like nil or null.
Unless you're using Haskell (one of the most mathy of programming languages, being based directly on the mathematical field of Category Theory and having it's own official category called "Hask") where you have to understand something like the Maybe monad or the Either Monad or the List monad (and why that's largely equivalent to either of the others) in order to even think of not having a value. Of course understanding all of that is easier if you happen to understand what the mathematical concept of monad is. Which you probably don't unless you are a Category Theorist (or recreational Haskell dabbler).
With a deeper understanding of math you can more easily grok the power, elgance, grace and healing powers of things like Haskell and Lisp.
You need at least some understanding of basic math concepts to understand things like algorithmic complexity (i.e. "Big O" notation, amortized analysis, etc). Without this level of understanding you're in for a bad time trying to write anything more than a trivial program operating on a trivial data set.
It goes on. There's a lot to learn. But that's a big part of what I love about computer science. I can consume as much of the literature and concepts and ideas out there as I can as fast as I can and I will never run out of new things to learn, and on top of that, there's an ever expanding frontier full of new discoveries to make.
Anyway, none of this directly addresses your actual question which unfortunately I have no frame of reference for, but it's what I would want to know if I had a son who was interested in programming. And something I wish I understood earlier in my journey as a programmer.
Edited to add: And if I did run out of math/comp sci stuff somehow, it all translates to physics, cosmology, etc! :)
Overly simplified, math might give you a well defined value, but no way to actually calculate that value, that's where computer science come into play.
| bog standard, journeymen, CRUD programming in Objective-C | = 3
But programming and maths aren't analogous but they're also not completely orthogonal, so my answer would be in the complex plane somewhere around:-
2.98 + 1/3i
| 2.98 + 1/3i | =~ 3
Wait that makes absolutely zero sense!
Programming itself isn't math intensive, though. Your application may be.
I work in sets and relations for the most part.