And half of mathematics is more or less the study of formal languages and their consequences?
You can say that they're different in order to keep people who are scared of math from projecting those feelings to programming. Or you can say they're the same to draw deep insight between programming and one of the oldest fields of study of human kind.
I find that people tend to reject the relation when they know of math as calculus, i.e. the analysis side of mathematics. When they bump into the algebra/proof side of it the connection is more clear.
As a corollary, people who are "good at language" are probably going to be quite good at algebra/logic mathematics as well if they approached it from the right angle.
That was my thought too, math is obviously tied very closely to language. And programming did come from CS which came from math. Web/App dev is just so far downstream from all of the math, that people in those roles can get away with ignoring it.
In fact, if you accept the premise of math as a language, most of the piece can be boiled down to: "language skills help programming skills, whether that language is mathematics or not".
Another nitpick:
> A common variation on this: without a CS degree, you can’t build anything substantial. Which, ha ha! Don’t tell the venture capitalists! They’re down there on Sand Hill Road giving actual money to hundreds of people building software projects without any formal qualifications whatsoever. In fact, they do it so often that the college-dropout-turned-genius-programmer is our primary Silicon Valley archetype of success. And monetarily, their strategy seems be to working out for them, if the fleets of Teslas on 280 are any indication.
1. Tesla is not a "software project" and I can't imagine that building a car is light on math.
2. Elon Musk has a degree in physics and dropped out of a Stanford EE PhD. He's not a "college dropout" or a "genius programmer." The CTO, Straubel, also has (non CS) engineering degrees from Stanford.
3. To my knowledge Tesla was initially 100% funded out of Musk's PayPal money, not venture capital.
"Math is irrelevant, look at Tesla!" is simply a ridiculous thing to say.
Now that you point it out I can see how it could be interpreted that way. I had trouble recognizing that because I don't think being wealthy (owning a Tesla) is an indicator that one "built something substantial".
That's a really restrictive and explicit demarcation of "formal language". I'd happily describe logic as formal language and then go hunting for places which seem to have non-trivial interactions with logic.
Well, if you define it to be broad enough, then you are correct by definition.
My point here is that there is a big, broad cultural gap between mathematics and programming that you are not going to breach merely by saying that a lot of mathematics is about formal languages (in the nontechnical sense of "formal language").
Far from it. Most of mathematics does not talk about formal languages and most of mathematics itself uses very informal language. It looks forbidding to outsiders, but there are many linguistic styles, fashions, abbreviations, shorthands, jokes, puns, and conventions in mathematical writing, very little of which is easy to algorithmically feed into a computer.
Sure, and I'm not claiming that you must unify them. Or that you can't. I'm also not saying that the language of mathematics is a formal language, but instead that it shares structure with them. The very notion of the interplay between a theory and its model is not dissimilar.
I'm not trying to absolve a cultural gap. Nor am I trying to claim that if you dropped a mathematician into a programming role they would thrive, or visa versa.
I'm simply trying to claim that there is a whole lot of similarity between the two and refutations of that are silly. Seeking a clear-cut demarcation between fields is a little silly as an exercise.
Finally, exploiting the similarity is powerful. Both fields benefit from this fact already and the more widespread the idea is the better.
I took a programming course where we wrote a number of programs in assembly language. We were given a set of rules and operations, a starting point, a goal, and we spent our time carefully assembling sequences of statements that took us from the starting point to the goal while obeying the rule system.
I took a math course where we did a number of proofs in natural deduction. We were given a set of rules and operations, a starting point, a goal, and we spent our time carefully assembling sequences of statements that took us from the starting point to the goal while obeying the rule system.
I'm dense, but I wondered about the strength of the correspondence between the two. It turns out that there's a nice paper by Philip Wadler [1] that illustrates the equivalence of natural deduction (math) and Church's lambda calculus (math, but programming).
[1] 'Proofs are Programs: 19th Century Logic and 21st Century Computing', Philip Wadler
I haven't read Wadler's paper, so he may well refer to this, but he relation between programs and proofs generally falls under the well-known Curry--Howard Correspondence[1], Curry being, of course, Haskell Curry, namesake of the language and the practice of Currying.
Effectively: a maths education is a great IQ test. If I was hiring a press agent, I'd still ask math questions.
E: "I think this is great. I was always interested in computers as a kid but was awful in math."
When I was a kid I was intermittently good and bad at maths, and hit a low point in high school trigonometry. Different teachers, different styles. I still "grew up" with college calculus, and ended up taking even graduate-level courses in mathematics. (Not without spending a year or so in film school thinking arts were right for me because I wasn't 'mathy')
We need to do away with this widespread notion that some people are good at maths and some have other talents. That's just mathematical anxiety, poor organization (I was bad at high school linear algebra because I couldn't line up my matrices right on paper) and some level of license already being given to people to suck at this.
We don't tell people they can be bad at talking. Kids who can't talk to strangers or have bad praxis are taken to psychiatry.
As a civilization, we need to suck it up with mathematics. As long as we tell sociologists that they don't need to know maths, we're gonna end up with bad theories of society that don't understand nonlinear dynamics, as much as mathematicians scream about catastrophe theory. And then there's this: programmers who can't grok some two years of college maths are just going to suck constantly. How many complex "language problems" resolve into constraint linear programming, FFS?
> We don't tell people they can be bad at talking.
Of curse, we do. People is terrible at talking in public, for example. And a lot of people have serious issues talking with others (like the opposite sex).
In fact, problems in human communication are far more serious and widespread than problems in math. The problem in how teach and learn math is a subset of it: If we have problems with math, is the failure in how the subject is talked among us.
If you were as defined by being bad at speaking as some people are by being bad at math, you would starve to death because you couldn't pay your bill at the grocery store.
> We don't tell people they can be bad at talking.
The brain evolved to communicate effectively with others. It did not evolve to manipulate symbols in a logical way. We can do it (some of us rather well) since the brain is still quite flexible. But it may account for the difference.
That's funny, but if your serious then your response does not make much sense here. My point is: Language came early in human development and to humans everywhere, without exception. Indeed the need to communicate may have been one of the main selectors justifying the cost (Brains are expensive to run). But many tribes are ok without maths and it has been around for just about three millennia and so could not possibly have had much influence on brain development.
> If you took a dynamic methods class in school, you know that big-O notation is pretty much meaningless in the real world. Which is to say, it doesn’t matter how an algorithm operates on an arbitrary set of data
I once spent a day or two trying to figure out why our network simulation was grinding to a halt.[1] The research guys, of course, blamed us engineering guys (you're writing slow code!) Turns out that one of them changed a key algorithm so now it was exponential in the number of nodes in the network. Worked fine when he did a quick 5-node sanity check on his machine, but wrecked havoc on the 50-node full-scale simulation.
Yeah, you can get a surprising amount of stuff done by just derping around. Doesn't mean the educational system should encourage that.
[1] This was a few weeks before a major milestone demo, and days were precious.
So this person was not only unaware that the algorithm was aad, they also were unaware that one algorithm oould be worse than another? Unless that second part is true, you juat have an employee making poor decisons. More aaths won't help with that.
Honestly, I've wavered on this topic...I used to think that math wasn't an inextricable part in understanding programming, since it doesn't seem we do anything more taxing than incrementing values by one, on a day to day basis. This recent interview with mathematician Jordan Ellenberg really piqued my interest though:
> I would say that math, almost alone in the school curriculum, is the one place that you can create knowledge absolutely from scratch and know that you’re right. That’s rather amazing and I think that’s one reason math has a central place in school. If you’re taking history and someone says, “This is what happened in the Eisenhower administration,” you have to take the teacher’s word for it. If you don’t, you can look it up in a book and you compare that book’s authority to your teacher’s authority, but in the end you have no direct access to what’s true and what’s false. Math is different. In math, you can actually directly perceive what’s true and what’s false. You can count and you can measure and you can create that knowledge for yourself. That’s an incredibly powerful thing. If students come out of their math classes in school without really experiencing that, that’s quite a waste because it’s very special and it’s something only math can offer.
This, for lack of better term, faith in logical proof...that certain forms of analysis and problem solving can be built from and derived in an irrefutable way...that's hard to get across to novice programmers...such as the idea that debugging is not just a matter of luck and randomness, no matter how complicated that stack trace or how you cross your fingers when turning on your computer, but of logical deduction.
Sure, everyone who is an adult goes through many years of math to graduate high school...but how much do they really appreciate that mathematical assertions can be, as Jordan puts it, basically created from scratch and be irrefutable? Which is something that you can't say for many non-math topics that we run into day-to-day? And if you don't have that grasp...even if all the actual math you do in your code is x += 1...you may not have the intellectual fortitude to deal with all the ways code can diverge and break.
I was just reading Per Martin-Löf's On the Meanings of the Logical Constants and the Justifications of the Logical Laws [0] which talks about this exact notion from Martin-Löf's modern intuitionistic logical perspective. This paper is a little dense and meandering, but I challenge anyone with an interest in the relation of programming and mathematics to take it on.
An ultimate conclusion it attempts to justify is that theory and proof (identical to "type and program") are a noun and a verb respectively. The act of consuming a proof is the one where you, the reader, consume some evidence which subsequently substantiates the proposition of interest.
What that means in relation to this parent's notion is that mathematics, and indeed programming or anything which can be connected so strongly to formal logic, necessarily draws all of its meaning from the words used to express it... and thus, once you've heard them (read a proof, seen a program) you have all of the facilities necessary to manipulate it and test it and learn more.
Which is exactly what makes all of these bodies of work, together, so accessible and wonderful. And it's exactly why history always feels less powerful.
Programming is deeply and inextricably mathematical.
However, most programmers don't actually know mathematics, so it's difficult to see that. This is further exacerbated by the fact that people creating APIs and libraries also don't know math, so they don't see it, and consequently design APIs and libraries that don't show mathematical characteristics. (This is not because they are "better"... it just means that mathematically these libraries and APIs are mind-bogglingly large and complicated objects, instead of simpler and more powerful ones.)
Schools don't teach much math. Non-zero, but not much. Even a computer science bachelors degree teaches only a smidge of math, and not enough to learn how to correctly apply it to real code.
If you're not doing proofs in school, you aren't doing math in school. I do not mean that all math is proofs or that only proofs are math; I mean literally what I said... if you are not doing proofs in school, you are not doing math in school. (If you get up to post-grad this can change a bit, but pretty much all that is available to bachelors students are in these courses.) You can use this as a yardstick to see how much math you actually know; if your proof experience was confined to just one or two classes where you begrudgingly wrote a few proofs, you don't really know math, and, well, probably shouldn't be arguing about whether programming is or is not this other thing that you don't even know. Memorizing a series of legal transformations of equations with perfunctory walkthroughs of their validity by a disinterested professor is not math. It's calculation. If you've observed to yourself that a computer could well do that... well, yes, they could. Computers remain fairly bad at math but they've got us creamed on computation, even symbolically. The calculation you learned is not math.
Math is about building systems of axioms, building on those axioms, learning what you can and can not guarantee, how to maintain those guarantees, how to build big things based on those guarantees. Safely refactoring code while maintaining its behavior is math. Building an API with simple primitives that can be safely combined to obtain various useful effects is math. Compilers are big piles of math about graphs and nodes. And I could go on and on. Pretty much every program I write is a simultaneous exploration of what the simplest primitives are that I can write and the operations for safely combining them, and this includes even brutally practical systems like process monitoring or memory pools.
To the extent that the average developer's refactoring is generally not safe, that indeed the language itself probably doesn't even permit truly safe refactoring, that most APIs are not built around simple, powerful, safe primitives, that most "compiler"-y code is a big pile of hacks, and so on, that doesn't show programming isn't about math. It shows that most programmers are bad at the relevant math, often to the point of complete ignorance that math is even involved, indeed often not even knowing the relevant words for the basic things. Consequently, yeah, they argue that programming isn't math. It is. They just don't realize it because they lack the skills.
This is not targeted specifically at the original author, BTW. "Programming is not math" is a widely shared opinion.
I might be one of those people that don't realise that programming is math because I don't know enough math.
I know about the classic algorithms, but I've never had to code any for real. And I haven't had to write a compiler. I know enough about graphs and trees to know when to use them, but don't ask me about all the different ways to traverse them, or the differences between red and black trees, and balancing trees, etc.
But I'm an applications programmer. Most of the time I move things in and out of databases, and I use third-party libraries and APIs. I'm curious: do you think it would help applications programmers to know algebra a bit better, or trigonometry? Or anything else from the standard math curriculum?
In all honesty, for me the biggest difficulties in programming are making clear, concise and cleanly structured programs. And that for me isn't math, maybe simply because I didn't study math, I studied philosophy. And in philosophy what we had to do was write clear, concise and cleanly structured arguments.
So do you think it's really a case of regular everyday programmers not being better because they don't know math?
"So do you think it's really a case of regular everyday programmers not being better because they don't know math?"
Causation is a strong claim, and I lack the evidence to back it up.
For an application programmer moving things in and out of databases, here's an example of the sort of thing you are dealing with all the time and may not realize how deeply mathematical it all is:
1. There exists a set of Operations on the database.
2. Each Operation has some characteristics:
a. Atomic
b. Consistent
c. Isolated
d. Durable
and each of those statements itself carries mathematical content (for
instance, almost all databases ship with ways of choosing what
Isolation means).
3. Operations may be composed into Transactions, which depending on how
they are manipulated may or may not violate the properties of the
isolation itself.
4. For each such Transaction, it may either Succeed, Fail, or do something
probably-horrifying in between.
As you go to use the database, you need to understand these properties, how they work together, how to harness them best in your code and how to deal with when they break down (for instance, migrations often break transactions). As you write code that ties together database operations, you're doing mathematical work composing together various atomic operations to obtain the result you want. This is particularly obvious if you've ever written code that manages transactions yourself, but has to involve other various client-code function calls within the transaction; you rapidly get into the world of "recursive transactions" in one form or another.
How do we recognize a "mathematical" API? A more "mathematical" database will work to minimize the "do something probably-horrifying in between" cases. More of the compositions will be legal without breaking the Transaction promise, i.e., perhaps you will be able to roll back a schema change. The properties will be clearly spelled out for each operation, and the transaction will do a better job of maintaining them. Care will be taken to ensure that any data conversions are as "isomorphic" (for now, read "reversible") as possible, and will generally refuse to "guess" what something means.
By contrast, a less mathematical database will contain more operations that break the guarantees. The documentation of what properties are maintained by which operation will be lacking. Transactions will frequently be broken because it's "no big deal in practice". Data that doesn't fit the hole it is being put into will just be hit with a hammer until it fits, and you will not necessarily be able to figure out what it started as. ("This date is 0000-00-00... where did that come from?" three days later "Oh, crap, I inserted someone's name as their birthdate...")
Basically, PostgreSQL vs. MySQL, to put names on these two styles, especially older-school MySQL... because, you see, over the years MySQL has been forced to get more mathematical, because otherwise it loses data and is generally a pain to work with. PostgreSQL's heritage is far more "mathematical" than MySQL, and it manifests in a better product.
If this just sounds like "good API design", well, yeah, good API design encompasses having a strong mathematical focus, but being "mathematically-aware" code goes beyond that.
Few programmers really know math, but even fewer really get how to translate that into practical code. It's a hard discipline to learn.
I've seen someone take a piece of code from 72 lines down to 3 lines by just doing some simple mathematical analysis before actually getting to refactoring. The code was also simpler, and easier to understand.
Do you need math for be a good programmer? No. Does it help to know math while programming? Absolutely.
That's sounds like example of someone with math skills applying them to make an awesome bit of code.
But I've also heard about math PhDs write the sloppiest code code imaginable: functions 1000+ lines long, copying and pasting functions to add a parameter... (in production code for a software company, not a research project).
So like you said, math helps but I'd like to extend that thought and say that you can make bigger gains elsewhere. For example, if you're a sloppy coder and don't know math, go out and get a book like "Code Complete," "The Pragmatic Programmer" or "Clean Code" first.
I've also seen a programmer waste 6 months on code that didn't solve the problem because he was a poor communicator and got all the requirements wrong. I don't disagree with your point but it doesn't really mean that much. A good programmer needs to be well rounded -- understand math, logic, language, human nature, etc.
If you're calculating missile trajectories; math is going to be a more important component. If you building a Facebook plugin, it's probably much less important than other skills.
(1) I don't understand how the programmer wasting 6 months relates to my example. (2) I don't believe you know what math is/isn't, calculating missile trajectories is just one way of doing math. Math is not the same thing as Arithmetic. Also, depending on the type of plugin, math can be quite a useful tool. For starters, if you're playing with Facebook's graph api, knowing about graph theory can be quite handy.
This article just indicates a cramped view of math and programming.
Programming is math, very simply. Consider the simple Turing Machine: invented to give proofs in what we'd now call mathematical logic. Coming up with Turing machines to solve given problems is so obviously programming, that I have to suspect Ms Mei hasn't ever looked at Turing Machines. The same could be said of lambda calculus and Combinatory Logic.
But OK, I'll go with "programming is not math" just to examine the consequences, which is a mathematical activity in and of itself. Let's just ignore things like completeness and consistency, and formal languages and parsers and spend our time puzzling over why some sets of requirements cause us to spend unpredictable amounts of time writing the (not math!) program to meet those requirements. Let's just puzzle over why it's so dadgum hard to find malware in our files. Let's spend large amounts of time hacking around with our multi-threaded servers, because gosh darn it, it's not mathematical.
"Engineering isn't mathematics. Look, I have a calculator, I punch numbers from the ANSI standards and woop the buildings stay upright. Engineering is about understanding safety laws".
P.D: A feel of several of the comments here, so is not exactly directed at the parent.
Look like some of the defense in the idea of programming is math is reduced at: With math you can be more efficient at solving X task.
That, itself, is proof that programming is NOT math, instead is a tool (like always is) that could enhance it. But the fact that developers ignore the math-y aspects of it and sill ship code show that is not a central aspect of it.
Is "spend our time puzzling over why some sets of requirements cause us to spend unpredictable amounts of time writing the (not math!) program to meet those requirements."
I'm not getting at "with math you can solve task X with efficiency". I'm getting at "even if you have a stunted view of math, you're still doing math by programming". I gave examples to the effect that if you don't understand math, and you believe "programming is not math", you'll be puzzled by your inability to perform tasks that when viewed as math, are known to be impossible, and you'll end up with false-to-fact views of what's lamentably called "software engineering".
The central idea of the linked post is that programming have long ago spread to more circles apart of math, and if in the past solve math problemas was the #1 activity that is not longer the case, and then, programming is dominated by other activities apart of math.
But, some people insist to teach programming ignoring that and still thinking that programming is a tool for math.
Now, I think is more right to say math is a tool for programming.
It's really good that some form of craft programming has spread as "not math". But let's not kid ourselves that math isn't programming, and programming isn't math.
It's like finding your way from St Louis to Chicago (in the US) or Rheims to Paris, say. You don't need to know that you're navigating on the surface of a spherical body. You just need to know a little map reading, or listen to Google Navigation giving you apparently planar directions and execute them. Just because your journey looks and feels flat does not mean you live on a flat earth.
You can even keep up a flat earth view of the cosmos, but ultimately, you'll end up re-inventing Geocentrism and embellishing cycles with epicycles. And you'll be mystified by how a few wizards can fly non-straight-line routes from New York to London and get there faster than your flat earth "straight line".
I hereby acknowledge, swear or affirm that the previous is an analogy, and therefore can be carried to far for purposes of building a straw man counter argument.
Yeah, but the problem (as you point) is that you can say that navigating is astronomy, or physics or relativity. But you don't call "traveling is relativity!", you call it traveling. Math, (classic) physics and relativity are ways to understand it, sure, even describe it, but what is more true than the other: classic physics, relativity, math?.
Here the problem is not about understanding the foundation of things, is about not apply to all the levels in the abstraction the same label. When you walk in the part you are NOT doing math. Your are walking.
This is the point expressed in the blog. It have not argued that programming is totally devoid of math, that math can't be used to formally think about it or something like that. Is that is better to think that programing is programing, and like you don't say "programing is relativity" then teach programming using relativity(!) and dismiss programing as a real, whole thing that only can be explained by relativity(!) and tell everyone that to be a good programmer you MUST understand very well relativity.
The point is that the formality of process description is mathematics. It may not be mathematics as you understand it, and that may largely be because you can intuit a large part of what you are doing as you are doing it, and that's an unfamiliar feeling with math. But let's get this straight: cancelling out out the unnecessary steps or factoring out the common steps in a procedure is exactly the same thing as it would be in an algebraic expression. In the simplest application, it may not seem like there's anything "formal" or "mathematical" going on there, but that's only because it's simple and easy to spot. You can also look at four things and see four things without counting them, and divide them into two twos without doing anything that feels like division. Just because it doesn't feel like mathematics to you doesn't mean it isn't.
There is research in this area:
"Contributing to success in an introductory computer science course: a study of twelve factors" :
http://dl.acm.org/citation.cfm?id=364581
(note math background is positively correlated with success, language skills were not considered)
"Language Factors in Mathematics Teaching and Learning"
I think there is enough research to suggest that if language skill were critical, I think one of the surveys would have noticed it. If anything the math research suggests that cultural fit with the teacher is more important, so that foreign students are likely to have problems even if fluent in the teaching language, due to cultural differences.
Research into Comp Sci has been going on decades becuase apparently its one of the hardest classes to teach effectively. With a high drop out rate worldwide, and a good chunk of students scrape a pass without it ever really clicking.
Naive question: "language skills were not considered".. this mean them not think in include it, or that it test for it but not see a correlation?
"Research into Comp Sci has been going on decades becuase apparently its one of the hardest classes to teach effectively"
This apply to math, rigth? So, if (as I experienced) programming in university is teach as math, and get the same bad results, them the solution is double-down in be more math-y?
I learn programming in a tech school. Far more effective. In my experience with interview more than +100 developers, the people that go to university (and be their introductory at programing) do worse at programming than the people that don't.
Explanation: math is rigorous, programming is rigorous, people good at rigor will be good at both. Nothing to do with the trigonometry and number theory knowledge being directly transferable, though practice with one could improve your rigor and carry over in that respect.
I think the fundamental problem is this: programming is not computer science. Think physics vs mechanics, or biology vs medicine, or theory vs practice. Nobody will expect a physicist to fix their cars, or a biologist to cure their sickness. Nobody studies physics to work as a mechanics.
On the other hand, computer science, being young as it is, is still confused with with its instruments (computer) and application skill (programming). This causes all the confusion. It was once pointed out to me that math major undergrads generally perform better than most computer science undergrad in many PhD programs. When you think about it, academia for computer science involves things like type theory, computational calculus, proof of correctness, etc. Much of these has little to do with actual programming!
So, programming is not math. Computer science, on the other hand, is strongly related to math (same way that physics relates to math; remember, physicists more or less defined calculus).
> Think physics vs mechanics, or biology vs medicine, or theory vs practice. Nobody will expect a physicist to fix their cars, or a biologist to cure their sickness. Nobody studies physics to work as a mechanics.
Now, but you can't get into medical school without taking organic chemistry, etc, and you generally can't practice as a mechanical engineer without taking several courses in physics, structural mechanics, and a math sequence up through differential equations.
"It was once pointed out to me that math major undergrads generally perform better than most computer science undergrad in many PhD programs."
There is a significant difference between computer science and archaeology, as academic disciplines. And it's not what you might think it is. A computer science student with out a Ph.D., with only an undergraduate degree, is (I hope[1]) fully competent to be gainfully employed in the field doing actual programming. An archaeology student without a Ph.D. is a shovel-bum, a ditch-digger, perhaps with some experience using surveying equipment, but certainly not qualified to do property title-related stuff.
[1] At most decent schools, anyway. The school whenceforth I came, for example, taught graphics and networking and compilers and data bases, along with basic data structures and algorithms, and a certain amount of actual programming. Someone coming out with an undergraduate degree certainly wouldn't be an ideal candidate to lead an important project, and certainly wouldn't have 5-years experience as a full-stack web developer in Elm and Clojure. But they would have the knowledge base to learn those things without big gaping holes in their understanding. You know, what used to be jokingly referred to as an "entry level" position: basic competence without expertise.
Well I suppose if you're just doing basic web programming you're not doing math. But even that (animations, etc.) can involve a ton of math.
Low level programming, the programming high languages are based on, use a lot of math. Using ruby on rails is just abstracting you from the math you'd have to do if you were actually programming something hard.
This, a lot of people are confused about what programming actually is by the sheer amount of abstraction libraries. A lot of frameworks i have used i would not even class as programming any more. It's more along the lines of a markup language.
It seems to me programming is getting more mathematical, not less, and that if one is going to be a good programmer in the future, they'll have to be more mathematical than at present.
Part of that is because of the rise of parallelism, concurrency, and functional programming. Functional languages are inherently more mathematical than imperative languages.
Part of it is because of the rise of big data and machine learning, which is inherently mathematical by way of statistics.
Part of it is because of the direction of future programming languages with richer type systems - dependent types, etc - which gets us closer to thinking more in terms of logic than computability, and math theory in general.
The Curry-Howard Isomorphism proves that computability (programming) is math is logic - the relationship between programming and math has felt distant so far but that is mostly because of the lack of sophistication in our programming languages. That is changing.
> Doing Riemann sums in Fortran is about as math-oriented an introduction to programming as you can get.
No. Math is not calculus. Math is more than calculus, more than arithmetic. If anyone asserted that "Programming is arithmetic" (or "...is not..."), they'd get their buttocks laughed off of them. But that is exactly what Sarah Mei is arguing against here.
> You might be able to say that math skills are required for computer science success, but you can’t necessarily say that they’re required for developer success.
I suppose you can't. But if you want to stay in this field for more than a few years, you might indeed want to know some of that background, mathy, computer-sciency stuff. Or does somebody need to go through that Java Generics and subtyping discussion again?
> As an example, consider whiteboard interview staple big-O notation.
Yes, let's. I had a conversation with a friend and cow-orker a while back like this:
"Why is this so slow: string1 + string2 + ... + stringn?"
"Because that's an n^2 operation. You copy string1, then you copy string1 and string2, then you copy string1 and string2 and.... Try sticking all of the strings in a list or array or something and then joining them all together at once."
"But this other JS interpreter isn't slow...."
"Because it's doing that array optimization for you, behind your back. I suppose you could limit our appy to that one browser if you are really attached to +'s...."
> But the same logical concepts are embedded in our human languages.
I would like to just note that
1. The best definition of mathematics that I know is something like "the study of abstraction as a fundamental." You can learn abstraction anywhere; it's indeed everywhere. But math is all about it.
2. If I go up to a native Japanese speaker and tell them, "Arigato!" they'll (I hope) pat me on the head and say "You're welcome". They'll probably think I'm an idiot, but they'll know what I'm trying to get across. If I try a similar feat while programming, the magic smoke will leave me blinded and with serious lung damage on its way out of the computer and into the ventilation system.
This. I loved that string concatenation example! I still don't understand how people can be so against big-O notation when it's such a simple idea, with so many applications.
That being said, in some languages string1 + string2 + ... + stringn isn't an O(n^2) operation. (Notably, if your string type is a rope, or if the language has a nary string concatenation operator, or is guaranteed to use something along the lines of a StringBuffer intermediary object)
I've often wondered whether we should think of things the other way round; ie, whether secondary education in mathematics could benefit from a programming component.
Certainly, for my part, becoming a developer kindled an interest in some higher maths, when ten short years ago I was slogging resentfully through my A level. I now love playing around with things like Haskell, precisely because of the 'mathsiness' of it, although I'm at a disadvantage from having not pursued it further before.
It seems to me that a bit of simple code could make the stuff seem more 'real' and interesting than it did to a lot of my peers back then. (And, of course, there was the whole 'try it in basic!'[0] thing in American textbooks.)
MATH IS ALSO LANGUAGE. Just because we've mostly standardized on a few notations doesn't mean that we couldn't have generally chosen to do things entirely differently, or that we couldn't have had as many common ways to express the same mathematical idea as we have computer languages, a variety of sets of mathematical rules to convert between them in more or less efficient ways, or to make the idea being expressed amenable to different types of algorithms or usages. Language is symbols and rules used to represent things, and symbols and rules used to represent relationships between those things.
This article is making a silly distinction.
edit: When you program, you're using language precisely as much as when you use math: as a representation of something that you're trying to communicate, not the actual thing itself.
The article isn't making a silly distinction. The conclusion the article is trying to refute is that Computing is Math. Your point is Math is Language. His point is Computing is Language. Dogs are animals, cats are animals, but cats aren't dogs.
So yes both Math and Computing use symbols and rules to represent things and relationships between them. But that doesn't make them the same. In computing, symbols are mostly used to represent actions to be performed by a machine which is very different from most math.
My main hobby is learning foreign languages and I have noticed that a very large proportion of people on language-learning sites happen to be programmers of one sort or another. Of course, this may just reflect a tendency of programmers to be aware of and use the technology available to pursue their other interests, and thus be overrepresented on such sites, rather than an affinity between interest and ability in computer languages and natural ones...not to mention the fact that programmers coming from a non-English background have a very strong incentive to improve at least their English.
The manual for the Wechsler Applied Intelligence Scale (WAIS) circa 1970 had intelligence score histograms for many professions. Already then programmers were quite outside the average-average.
Also: a mason and a blacksmith, both traditional crafts I admire, learn their tools once; programming is an activity where you have to continually change and relearn tools. This selects for people with an affinity with novelty. You'll probably see more programmers than the base rate when, say, a Nepalese restaurant opens in town.
I think programmers are still from a set of generation cohorts where being into computers from a young age was still a "thing", something that wasn't the default. I'm in my early 30s, and I had the first PC of anyone I knew in an upper middle-class residential compound of five thousand. Nowadays, it's more or less the default that everyone will grow up with computers (tablet computers y compris).
Of course, my first PC booted into BASICA. But still, it's hard to know what programmers born in the 90s, entering the workforce... right now... have as formative computer experiences -- and what the first tablet generation of programmers will think like.
On the other hand my interest for languages/etymology is an extension of the pursuit of expressiveness in programming. So seeing how humans categorized and related syntax with semantics is valuable to me even if I never cared using learning technology (unless you count etymonline, wikipedia and such as learning tech)
Oh, came-on. Programs are math, programming obviously is not. Programming is creating math. And yes, math is a king of language.
I'd ask why do so many people think that math is only computations with numbers, but I do know the answer. It's a shame schools everywhere[1] put so many effort in taking all the creative parts from their math curriculum.
[1] Or should it be "almost everywhere"? I'd be delighted to hear about an exception, but I never had.
Throughout early grade school I hated math. It was very much like the equally-hated gym class: Doing hard things because they were hard to do. Or so I thought; there seemed to be little effort to make either of these fun or relevant.
However, for 6th grade I managed to get into a school for bright kids. Somewhere around 7th or 8th grade I was given a chance to take a new "advanced" math course. (That's my vague recollection; I don't recall being all that good in math in 6th or 7th grade so I'm hard-pressed to understand being offered the option to take an advanced math class, but somehow it happened.)
Turns out, math is more than adding and multiply large numbers and tracking a series of infuriating decimal expansions. I was introduced to all sorts of interesting things. This was where I first learned about, and played, WFF ‘N Proof[0] and Tac-tickle[1].
Math (at least this kind) became fun. It was about patterns and relations and analogies and transformations.
People claiming programming is not math seem to be playing a game of begging the question. They first define math as restricted to those things that are not directly related to programming, and then declare programming is not math. QED.
Maybe this helps people who are leery of their ability to understand programming. I'd rather see things move the other way. Show that math is much more than doing complex arithmetic to help people who are leery of their ability to understand math.
Learning a programming language is a lot like learning a human language, but understanding math is how you learn efficient programming.
If you don't use mathematical reasoning, then you'll produce O(n^3) when you could have produced O(n). Any hack can throw together a script that will hobble along with 4 rows of data. Throw a million rows at the same script and it might terminate properly in a few years. Or maybe it just runs out of memory half way through.
Another problem is winding inefficient boolean branching. If you don't understand boolean algebra, you either over specify cases which makes code cluttered and disorganized, or you under specify and some cases are not considered at all... The result in either case is always buggy code that crashes. It becomes like a virus. Other lesser programmers are afraid to fix it, because it's so complicated. Instead, they just tweak the mess to accomplish their own goals, adding more bad boolean logic along the way. It infects everything it touches.
Finally, certain fields of programming, like machine learning, are almost entirely math and statistics. So, yeah, you don't need math to (poorly) do programming (in certain fields).
You don't need mathematical reasoning to realize that loops within loops generate slowness.
And as far as under-specifying versus over-specifying, I find that understanding the domain problem is better inoculation against horribly written code than understanding "inefficient" boolean branching.
If you just had to say "avoid nested loops" there would be no problem. Programming a solution that works at scale requires math and understanding where you will have bottlenecks before you write a single line of code.
>understanding the domain problem is better inoculation
How does one understand a problem without understanding boolean algebra?
Example. You have good/bad credit, car/motorcycle, new/used, drivers license yes/no. Which combinations allow testDrive()? Now add condition 'ok' to credit, moped and 18 wheeler to vehicles, and commercial to driver's license, because the boss forgot about those. Now how many combinations? Who is allowed to do what? How do you arrange the code so you don't spend time evaluating methods when driver's license of 'no' can short circuit the entire operation? (oh, except for moped, in certain states)
That's entirely boolean logic. If a person is not good at that, they suck at programming AND understanding domain problems.
I'd be more worried about making the code readable and easy to modify than high performance. You realize this is at best 5-10 OPS right?
Because in 12 months, nobody is going to know that you saved 2 operations by cleverly "arranging" your code.
I'm not saying you shouldn't arrange your code as best you can, but performance in this situation would absolutely be secondary to readability.
The link you give has nothing to do with the topic of math. It's mostly about knowing how your application is interacting with the system and a basic pragmatic approach to lock contention (also not math).
I have a lot of psychiatrist friends. I had psychiatric treatment at some point, befriended my former doctor in the process and then his group of friends.
It's amazing how much they have chemistry as a conceptual primitive -- just as much as I have linear algebra as a primitive. They drop "oxygenase" (or something) in casual conversation like I drop "eigenvector".
And 90% of what they do is talk to depressed people and sometimes hand some Prozac or some Xanax!
I think the truth to this depends on the person and their particular motivations for wanting to learn to program jn the first place. This can be very different for different people. For example, if you want to program in order to create 3D video games with custom physics/graphics then obviously math is going to have to play a big role in that at some point or another. If your goal is programming for its own sake then math is important for you to learn theory and computer science foundations, however it seems to me that you can learn math as you learn these things. If on the other hand you just want to learn to program to customize your tumblr or even just trying to get an entry level be a web developer position then you probably won't need much math. It cant hurt though.
Math, English, Python, Chinese, Ruby - these are all just languages. Programming languages and Math are simply languages designed to be good at describing phenomena that can be defined with precision. Programming languages are optimized for describing precise sequences and procedures, while the language of Math is optimized for describing precise proofs. You could actually write pretty much anything that is written in math or Python in English, but the English language has so much ambiguity that you would be more prone to making mistakes. English would also be much more verbose and would not be parseable by a computer.
The numerous compilers (courts) for this language frequently produce different and conflicting results, a situation which cannot be fixed but merely worked around by adopting the result of a master compiler as the authoritative version. The compilation process is also quite slow and very expensive.
So if legalese can be considered a precise, formal language, it must be considered one with an extraordinary amount of undefined behavior.
It is more precise than normal English dialect, but still much less precise than math or python. At root, the phenomena that legalese describes are often imprecise. For instance, there is no perfectly precise way to describe the boundaries of a non-compete agreement, or what exactly constitutes "negligence." (This is why we cannot actually replace law with code)
Agreed. My first thought was also along these lines:
Programming is not math, but it is logic, and math is almost always a purer and more demanding expression of logic than language.
Logic is important because programs always have to "resolve" into something specific in order to compile and have a result.
Most usage of language is devoid of structured logic, or "fuzzy" logic, and is poor training.
Just writing and reading this post is an example. I'm trying to be logical, but logic and persuasion in language is a different ball game - the reader is the "compiler" and as we know, they all work differently. :)
So, if you aren't comfortable with math or engineering on at least some level, you're going to be operating at a disadvantage as a programmer IMHO.
Doesn't mean you can't do be a programmer "at all", but the most demanding environments will continue to require it.
I agree with you. I didn't understand, or even really care for math, until math was described to me as a description language for abstractions.
If the author had taken the time to make this understanding as well she would have realized people that are "good" at math get programming just as well as people that are good at Japanese/French/whatever is because they are both languages.
Programming for the most part is about understanding program structure and modifying the said structure.
Different people view programming very differently. For example for me programming is mainly a way to understand things. I program things I want to learn about. My understanding of programming helps me understand computers and computing. Then I have a friend who couldn't care less about how exactly things work under the hood, or in theory. All he cares about is making a product, and programming is his tool.
There's a vast difference between computer science and software engineering. I'm afraid most people with CS degrees, let alone those who want to get one, don't even understand this themselves.
Imperative programming probably isn't math. Math describes things and their relationships. It doesn't tell other parties what to do.
That being said, imperative language has certain limits. When one party gives orders to one or more other people, then human language does the job fine. But when it's multiple people telling each other what to do, that's when human speech ranges from unpleasant to downright undecipherable.
So you get the same thing with imperatively coded programming processes that need to act concurrently in the same area. Confusion and fighting over resources is just the natural result.
In Canada many parents will enter their children in the bilingual stream, not only for the benefit of knowing another language but also because it acts as a natural filter by removing the trouble-makers and slower kids. I'm sure if she were to give a math test, she too would find correlation between language and math skills.
Programming is mostly engineering. You are rearranging abstracted units. Usually, you are piping data from point A to B, in which case there exists one algorithm to do that. Sure, some devs have deeper problems, but the majority of us are simply building data pathways.
Obviously, computers and programs are machines that do logic. And as programmers we manage symbols (like mathematicians do) that help organise that logic. So I see that part of "programming is math," which a lot of people have argued.
But I don't think we're getting at the crux of the argument: that for programming well there's more of a correlation between communication (e.g., exposing a set of ideas clearly and concisely) than there is in a standard math curriculum.
Certainly, some areas of programming and computer science are very math heavy. But where are the arguments that say that knowing math makes you a better programmer in the "best practices" sense?
Programming is not math! Math is Math! Math is a tool used in programming, engineering, economics, etc. To reduce a subject to a tool used in the subject is reductionist to the extreme and does not acknowledge the richness and complexity of the subject.
Although there are real world programming jobs out there that dont require deep mathematical knowledge i would be very sceptical about the programming skills of a person that has difficulties actually learning math.
My SAT scores were similar; maybe lower math and higher verbal.
I was always much better at writing than I was at math, and in retrospect I think being able to write well can help one program better.
If people are thought to plan how to express their thoughts, organize them in a cogent manner, remove redundant phrases, tighten up wordy expressions, they are picking up skills that can be transferred to programming.
Plus, being able to express yourself well at work is like a super power.
Not that I think programming is more a language skill than a math skill, just that abstract organizational skills are applicable to both writing and coding. I suspect that getting better at writing software might make one a better essay writer, or at least a more organized writer.
Push side-effects away and you have maths. Imperative code conflates all the logical relationships onto big state. When you use functions or `algebraic types` you see the overwhelming presence of simple logic and recursion. Be it Lambda Calc, FP, Relational...
as an aside it's kind of interesting why there isn't as much research on teaching programming as their is say on refinement types, separation logic or pointer aliasing. I think the reasons are annoying.
In academic research, nobody cares about education. The big universities that you think of as education powerhouses like Stanford, MIT, CMU, are all at heart research universities. Their faculty were not hired because of their skill as educators, but as scientists. In the training of research faculty (starting in undergrad through grad school and their postdocs) there is very little emphasis or formal mentoring or training on teaching students. Sure, you might TA a class, but this is usually seen as an inconvenience to be discharged as quickly and efficiently as possible, and some programs allow students to get their PhD without ever TAing a single class.
Why do they not care though? Well, educating undergrads won't get you tenure or grant money or publications. These are all the yardsticks that we use to measure faculty success. Wait, don't we use student evaluations? Oh sure, but you know what gets good student evaluations? Giving everyone good grades.
In a larger sense though, most don't care about the study of education. Education research is de-prioritized and de-funded and education researchers and grad students are mocked for lacking intellectual rigor. Undergraduate education majors are not helping - walk past an undergrad education classroom and you could find college students creating paper mache volcanoes. No joke. Some of this is because education research is really hard, both scientifically and politically.
Politically, education research is undermined by everyone. If you are a researcher and you want to study how K-12 education works, for example, you obviously need the permissions of administrators and teachers at a school. Trying to get this permission will set off a powder keg. The administrators might be supportive, or they might think that your findings will be used by NCLB to justify shutting their school down. Teachers won't be supportive at all, they will see your research as an attempt to gather data about their job performance, this will play into the hyper-adversarial relationship between administration and the teachers union, and you will never see the inside of a high school as an education researcher except on PTA nights. I'm pretty sure that nationally this research is not funded as robustly as say efforts to make robots fight with giant lasers because policy people don't really want to know when their efforts are not working and the thought of independent and critical scientists studying the education system terrifies them.
So, as a young researcher, when you sit down with your adviser and say "but nobody knows how our students learn programming", they will forcefully explain the way the world works to you, and "suggest" that you abandon this line of inquiry for something "safer", something more funded, like perhaps an algorithm to detect cats in photographs on the internet. You can publish on that. It will help your career. Educating undergraduates doesn't help anyone's career.
It's not clear if this directly addresses your complaint ("programming education" vs "computer science education") but there is a specific special interest group for computer science education that's been holding conferences since 1983.
Anybody who has the aptitude to make a career in a given field, has the aptitude to teach themselves, with a bit of guidance from a syllabus, a professor, and/or a TA. Most learning inherently must be done by the learner. The learner has to study the material at their own pace, and then practice, practice, practice. There is very little a third party can do to expedite the process, other than provide overall trajectory, review the output, and give some tips when the learner is really stuck.
It's hard to disagree with a statement like "learning inherently must be done by the learner", because what are the instructors to do, stick their hands into the minds of a student and place the knowledge there? However I think you (and attitudes like this) go a long way to discount the skill required to provide guidance, to recognize when the learner is really stuck, to review output, and construct an overall trajectory.
I think it's the case that someone who can make a career before starting education can teach themselves, but what about the other way around, can we give the proper instruction and inspiration so that someone could have a career? Boring/bad classes disengage students, interesting/good classes engage students. What even makes a good/bad class? Wish we could study that...
At the post-secondary level, If you get stuck, to the point where you can't figure something out by asking intelligent questions or reading relevant reference material, then you don't belong there. Your journey should have stopped at high school. Maybe sooner.
Professors are not teachers, and they shouldn't be. They are there to expose you to knowledge and you are there to absorb it and expand on it if you can.
Don't go to university to get a degree so you can get a job. Go because you want to learn. If you do it for any other reason you're going to end up in debt and disappointed.
The commercialization of higher learning has perverted it. They encourage people with poor life planning skills to pursue degrees that just leave them poor and bitter.
There is very little a third party can do to expedite the process
So why is college so damn expensive? Why does formal education exist at all? Just because the study of education hasn't been very rigorous and is widely ignored doesn't mean that there aren't better methods to find.
In the modern economy, you need access to a high-paying career path in order to have economic security ( http://intellectual-detox.com/2013/01/20/economic-classes/ ). College provides the social network, acculturation, and signaling that make it much more likely to gain access to such career paths. A good college is a college that has the best reputation and attracts the smartest and most savvy fellow students. Everyone has an incentive to attend a college with an existing reputation and students bid up the prices for these limited slots.
Also, colleges can pursue perfect price discrimination. The sticker price is set very high to extract the most money from those who can easily pay. The price is discounted based on ability to pay.
Why does formal education exist at all?
Well, originally, books were really expensive, thus self-teaching was hard, so the most cost-effective way to learn was from a lecture or a teacher with a slate board.
Currently, it exists because the formal education system teaches everyone that the formal education system is very important, that economic growth and our national competitiveness depend on more and more people going to college. People believe this myth, and then vote for politicians who sustain the institutions.
> Currently, it exists because the formal education system teaches everyone that the formal education system is very important, that economic growth and our national competitiveness depend on more and more people going to college. People believe this myth, and then vote for politicians who sustain the institutions.
It also exists because the gatekeepers for many professions require it. In many cases, they require multiple levels of it.
This problem keeps getting worse, too. For instance, NCEES guidelines require an accredited engineering Bachelors degree for a PE; they want to add mandatory post-Bachelors education to the licensure requirement because they feel engineering Bachelors degrees are too short.
Getting a PE also requires several years of experience working under the guidance of an existing PE. Maintaining a PE further requires continuing education.
Is anyone talking about post-graduate education requirements for the FE?
Well if you do not have a computer at home or access to books, then no, you won't be able to make it. But the solution would not be to spend money on schooling, but to buy everyone who cannot afford it a computer and a Kindle with a subscription to educational books, which would be a lot cheaper.
This is something obvious, but lost on some minds -because feel attacked?-.
IF programming is math, then math IS programming?
That's absurd!
Math loving people see everything with their math-eyes: Everything is math, everywhere.
Math is math. Biology is biology and programming is programming. Nothing can be everything at the same time, because then you need a God-like mind. Everything a human mind produce is a slice of reality/imagination, ergo, specialization.
Biology can be (partially) explained (sometimes, badly and worse) with math. BUT can be explained far better with language.
Math could be considered (or is?) a language, but is a shitty one (like a truly compressed C/Perl code) that as one-liner code is great to encode fast some stuff, but at large, is not the best way to convey IDEAS.
That is why I'm using words, here. Not math!.
That is why a programming language is made of WORDS, not math symbols. That is why, you don't write a app with math, you use symbols and languages.
That is why math is based in the kind of symbols derived from language, too.
This NOT mean math is useless or bad or something else. Is just a obvious observation: Math is not the focus in programming. Is not the focus in almost anything that happen in the realm of a human mind, UNTIL you need it. And programming stuff you don't need much of it, and when you truly need it? Still language dominate the task.
Not believe? Go read the source code luke, and see how much math vs words are there. You can check any large codebase, and see it for yourself.
When the analogy of "Programming is like a car.. is like building a house, is like ...." fall apart nobody insist that programming is like architecture. So why do the same with math?
And half of mathematics is more or less the study of formal languages and their consequences?
You can say that they're different in order to keep people who are scared of math from projecting those feelings to programming. Or you can say they're the same to draw deep insight between programming and one of the oldest fields of study of human kind.
I find that people tend to reject the relation when they know of math as calculus, i.e. the analysis side of mathematics. When they bump into the algebra/proof side of it the connection is more clear.
As a corollary, people who are "good at language" are probably going to be quite good at algebra/logic mathematics as well if they approached it from the right angle.