Programming is not math
sarahmei.com
sarahmei.com
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.
No, just a small fraction is:
http://www.ams.org/mathscinet/msc/msc2010.html?t=&s=68Q45++F...
This is but a branch of a branch (computer science):
https://en.wikipedia.org/wiki/Mathematics_Subject_Classifica...
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.
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.
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.
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
[1]http://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspond...
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?
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.
Is there some connection to Molière that I was unaware of, or was that just a brain fart?
[0]http://en.wikipedia.org/wiki/Best_of_all_possible_worlds#Cri...
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.
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.
http://host.madison.com/entertainment/arts_and_theatre/books...
> 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.
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.
[0] http://www.ae-info.org/attach/User/Martin-L%C3%B6f_Per/Other...
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 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?
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.
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.
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.
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.
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.
This article is just immature.
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."
This assume math is the only way to solve it.
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 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.
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.
That is what the article is saying.
Except that this time ``#comments`` has been added to the URL to circumvent the system HN has in place to prevent reposts like this.
-- Richard P. Feynman, The Character of Physical Law
Programming and Mathematics are both language + reasoning. So we can't say programming is language thus Programming is not math.
(note math background is positively correlated with success, language skills were not considered)
"Language Factors in Mathematics Teaching and Learning"
http://link.springer.com/chapter/10.1007/978-94-009-1465-0_2...
"The effect of student attributes on success in programming"
http://dl.acm.org/citation.cfm?id=377467
--------
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.
"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.
I gave it a second read, and it's written like a Tumblr social-justice screed.
Hacker News is reading increasingly like Metafilter. Sad, this.
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).
Making programs and making the computers and software that run programs are two very different things.
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.
http://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse
"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.
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.
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.
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.)
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.
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.
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.
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.
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.
0: http://www.mlagonline.com/games/wff_n_proof.php
1: http://www.gamesforthinkers.org/tac-tickle-a-challenging-gam...
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).
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.
> lesser programmers are afraid to fix it
Red flag.
http://highscalability.com/numbers-everyone-should-know
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.
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).
Programming is the human means to get a digital circuit to turn "one" and "zero" in a particular way.
Applied programming is to a CS degree as diagnosing and curing disease by a physician is to microbiology.
Applied programming is to math what diagnosing and curing disease by a physician is to chemistry/physics.
For fun, go ask your dev friends to compare and contrast NP-complete and NP-hard today.
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!
So if legalese can be considered a precise, formal language, it must be considered one with an extraordinary amount of undefined behavior.
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.
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.
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.
However, Everything depends on the purpose of the code.
Programming is equally an insanely large topic now, so I must should temper this orignal statement somewhat
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.
When learning to code through, it helps to have experience with functions and math procedures, even if it is only for the sake of analogies...
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?
http://en.wikipedia.org/wiki/Best_coding_practices
I.e., for most programmers in the world (they're mostly applications programmers, right?), how does knowing math help them make better programs?
And what kinds of math helps them make better programs?
I think a good balance makes a good developer. Even more than that, it makes a good software creator - designer, developer, project manager, etc.
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.
There _is_ prejudice against women in IT. This isn't helping.
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.
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...
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.
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.
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.
Is anyone talking about post-graduate education requirements for the FE?
Symposia/conferences:
http://www.sigcse.org/events/iticse http://www.sigcse.org/events/icer http://www.sigcse.org/events/symposia
On top of that there there's a great talk from David Patterson about how they are approaching their software engineering courses at Berkeley.
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?