Programming is Math, apparently.

Having a background in programming language design, I have acquired a professional obsession about syntax and semantics of words — not just pertaining to programming languages but also pertaining to natural language. If you want to get me all  bitchy in a meeting, stretch the use of common words beyond reason in order to get your ideas accepted (this is called marketing, and there is a science to it, it’s called Psychology); if you want to see me go off in a rant, present me with an API that uses the wrong words to denote its concepts, like calling a getter method RequestSomething(). So, yeah, I’m obsessive compulsive about naming things and using words — ask my colleagues in the OpenSimulator project about my incursions into renaming things… Words are the main means with which we, humans, communicate with each other. If we get those wrong, we are either being deceitful on purpose or we are creating the context for misunderstandings. Which brings me to the word “programming.”



Recently, I had an interesting experience with the students in ICS. As part of the student-organized ICS Day, there was a Programming Competition that was supposed to be a “Beat the Professor” gig, i.e. students competing against a professor. In the past, this had been done with one of the ICS lecturers as “the Professor”. This year, the lecturer got sick and couldn’t come, so the students asked me at the very last minute if I was willing to act as “the Professor” in that competition. Not knowing any better, I accepted.

I had no idea what the competition was about, but if it was called “Programming Competition” I was game. I always love to explore an unexplored API, use a programming language that I haven’t seen before, build running systems from scratch out of pre-existing components, design efficient data structures for hairy modeling situations, etc.

To my complete surprise, the programming challenges in the competition were… math! Math and algorithms. More precisely in this particular instance, the first challenge was trigonometry, and the second was an optimization problem. I was utterly confused. In my infinite naivety, I ask the main organizer “Why are you calling this a programming competition, when the programming part is completely uninteresting once you figure out the Math?” The student, feeling equally confused with my question, explained that this is how Programming Competitions go, and that they had gotten the challenges, literally or figuratively, from the ACM International Collegiate Programming Competition.

So I took a closer look at that competition. It seems like a fantastic initiative, with participation skyrocketing over the years. Kudos to the organizers! Having young people all over the world coming together over the common drive of solving algorithmically-rich problems is… inspirational. Look at the list of participating Universities in that factsheet, and it reads like a United Nations of sorts. Fantastic!

There’s only one problem with this competition: it is using the word programming to denote math and algorithm development.

An outsider who doesn’t know what programming is will look at this set of challenges and conclude that programming — the thing that hundreds of thousands of professionals do in their daily lives, and that the vast majority of Computer Science students will do once they graduate — amounts to… solving Math riddles! Imagine! Under this syntax-semantics association, your university’s IT department’s staff is, supposedly, solving optimization problems (maybe budget related, these days?); the Apache web server, the software that powers modern society, is, supposedly, full of complicated algorithms. The WordPress software that I’m using to write this post is, supposedly, a wonder of algorithmic thinking. … Really???

While I respect the role that Math and algorithm development play in the advancement of knowledge, and their role in important areas (heck, I recently got a paper accepted at SIGIR 2011), I believe we’re doing a gigantic mistake by associating the word Programming with that concept. It doesn’t do justice to either the actual practice of programming or the actual practice of solving algorithmically-rich problems. They’re not the same thing! Saying that they are the same thing is a classical error in logic: algorithm development usually ends up expressed in the form of a program; but the reverse is not true: not all programs are about solving algorithmically-rich problems. By a long stretch!

As Barbie said, Math is hard, indeed. Programming is also hard in its own way, but not in the way that Math is hard. A myriad of things can be done with programs that involve no Math and no fancy algorithms whatsoever. Moreover, a whole other group of challenges emerges when the programs are to be used by people other than their developers, when they get put out to use in the wild by hundreds, thousands or even millions of people.

In seeing the ACM ICPC, I asked myself how I would design a real Programming Competition. What would the challenges be? How would we determine the winner? Feel free to leave your thoughts.

This entry was posted in commentary and tagged . Bookmark the permalink.

17 Responses to Programming is Math, apparently.

  1. Hannes says:

    I consider the annual ICFP programming contest to be a real-world contest. 72 hours of time, any ressources you have at your hand – take a look at earlier contests, they’re all fun – http://www.icfpcontest.org/

  2. The Benelux variant of the ACM ICPC is aptly called Benelux Algorithmic Programming Contest.

    For a real Programming, I think the term is both too wide (e.g., already in the Algorithmic Programming contests the issue which languages to include is a bit of a problem) and too difficult/vague to judge objectively (how would you judge architecture, SE or following a sensible development methodology?).

  3. Programming is more synonymous with ‘Managing complexity while getting figuring out how to accomplish specific goals or tasks and keeping the project nimble as the specifications invariably change in the middle of the project’. This is why a word-smith, such as yourself, is highly valued.

    Can I get a:

    bool bHighFiveResult = HighFiveFriend(Dan, Crista);
    If (bHighFiveResult)
    {
    PlaySound("clap.wav");
    Shout("That's what I'm talking about!");
    }
    else
    {
    Shout("Whoops, Missed!");
    }

  4. crista says:

    @Hanes, indeed, the ICFP Programming Competition looks a lot more fun! — and with a whole lot more components that resemble what programmers actually do in practice. Those must be 72 hours of pure craze! I’ll point our students to it, since I promised to help them with the next one.

    @Meinte, I also have a hard time envisioning interesting programming challenges that can be solved in 1 hour and that can be assessed for their programming component. The ICFP one comes close, but it’s 72 hours… Maybe there’s no fast way to assess programming skills competency. Unlike Math.

    @Dan :-)

  5. gousiosg says:

    Very nice post, totally agree with your points. For a real programming contest, I would have students build a distributed architecture that does non-trivial data processing and presentation (e.g. some combination of a web frontend with a scalable data aggregation backend) in the first 48 hours and then have them adapt it to a different raw data format in the next 6 hours.

  6. Depends where you consider programming to start:
    1) at elicitating requirements? just give them some arbitrary text and let them find out what it means.
    2) at deciding on an architecture? give them crisp requirements, but change them a few times during the process
    3) or ‘just’ at programming? no idea … perhaps a well known problem in a language they don’t already know?

  7. Markus J. Q. Roberts says:

    As someone who also loves words, and even more the concepts behind them, I hope you will reconsider your position.

    You appear to have fallen into the trap of confusing the parts of fields which you are familiar with (mathematics and programming) with the entirety of those fields. Because there is not much apparent similarity between the parts you know, you are concluding that there can not be similarity between the parts you do not.

    In the specific case of programming and mathematics, this error is very common, but no less of an error for all its currency.

    Coding and arithmetic, while not clearly related, are both parts of larger conceptual structures which share deep and beautiful symmetries and are ultimately unified if you progress far enough. Programming and mathematics are actually two different ways of looking at the same thing.

    Imagine you found a room containing a seemingly random assortment of things; a rock swinging on a string, a stone disk with a stick protruding from the center, a grid of squares drawn on a piece of paper, a leaky bucket, a candle & a ruler, a digital display, an analog clock…and then it hit you that these things weren’t unrelated at all. That sort of deeply satisfying insight is what you are dismissing when you say that programming isn’t mathematics.

    — MarkusQ

  8. crista says:

    @MarkusQ While I understand the idea, and the appeal that all-things-conceptual map back to Mathematics, I’m afraid I can’t take that idea beyond the abstract beauty of it. It’s too narrow to be useful in practice. Next thing we know, we’ll be testing how competent Musicians are by testing their ability to solve Math riddles — after all, Music and Math are related too, even more so than Programming and Math. That kind of reductionist approach, while appealing in a poetic sense, doesn’t capture the diversity of human activities — the operational semantics, if you will.

  9. Markus J. Q. Roberts says:

    So I really like the music example, because it brings out some key distinctions that may not be apparent in the case of programming.

    First, the distinction between performance and composition. Programmers, like musicians, divide their time between two distinct activities, one fundamentally about design and the other about execution. In each field (in fact, in all branches of mathematics) initiates spend most of their time and effort on the execution aspects. This is likely unavoidable, since at least some mastery of execution is needed/assumed to make headway on design.

    But it unfortunately obscures the relationships between the sub-disciplines. Playing a harp doesn’t feel anything like playing a flute. If we couldn’t hear the results (and process them through complex mental signal processing systems) even the notationally similar scoring wouldn’t be enough to convince us that they were at all related without years of study.

    Sadly, we have no such innate perceptual augmentation for most branches of mathematics; we can’t see/hear how they relate until we pass through the performance stage and obtain a fair mastery of the design. All of the performance level skills share this property; the how-details of execution make it all but impossible to see the why-details of design.

    Secondly, the subject mater of execution (notes, numbers, classes and methods, etc.) are generally only a small subset of the objects of interest in the field, but they loom large in the mind of the initiate until they seem to be the whole field. Mathematics has very little to do with numbers and calculations, though that part occupies most of the introductory curriculum, just as dealing with spit valves and dotted quarter notes do in music class.

    But as much as I like the example, I must take issue with the conclusion you draw from it. Far from advocating a “reductionist approach” as you claim, I am saying the opposite: that real skill in a field relies on seeing past the reductionist details to the structure beyond.

    Judging a pianist by their ability to solve arithmetic problems makes no more sense than judging them on their circular breathing skills, and I am not advocating that. But expecting great things of a composer who understood group theory, had an intuitive grasp of catastrophe theory, or had deep thoughts on the frame problem…those sorts of things seem to me quite reasonable.

    Likewise, if all a programmer is expected to do is call other people’s APIs and fill in the blanks provided by a web framework, then no, they don’t need much math. But if they are to design the frameworks, define the API, or break new ground in other ways, yes, they will be doing mathematics, whether they realize it or not.

    — MarkusQ

  10. crista says:

    Thought some more about what a Programming contest would be. I don’t think anything quick can get to the bottom of it. But if ‘quick’ is of the essence for a contest, as way of fast “proxy” challenges for determining people’s ability to program, instead of Math riddles, I would have them write essays and/or summarize, in writing, a story seen on video. That would get much better at the issue of how people choose to use words and how people choose to divide the story — critical components for writing code that can be understood by others.

  11. Karen Lopez says:

    Barbie actually said “Math class is tough”. As it should be.

  12. Phuong LeCong says:

    First, I’d like to say that I’m glad I found your insightful blog. I wish you were around when I was back in ICS.

    Second, I completely agree with your assessment and would extend it to the various job interviews that pervade the programming industry. While there is value in figuring out the algorithms required to get something done, a programmer’s value can be so much more than that.

    For instance, I was recently in an interview where I had to implement a RegEx parser and since I don’t really ever need to do that in my day to day job, I was not able to do it. Granted, I was able to figure out that I needed some kind of state machine and get most of it, I was not able to complete that task in the time allotted.

    Your post also reminded me of a genius I knew in college who could probably figure out any algorithm, but I’d never want to use or maintain his code. To me, programming is about modeling the world and how to organize things to get the job done. Going with a writing analogy, I find programming more like writing an essay; composing your ideas in a coherent, easily recognizable, manner.

    Obfuscation is not a desired attribute of programs. Besides, there’s an algorithm for that.

  13. Alec Benzer says:

    “if all a programmer is expected to do is call other people’s APIs and fill in the blanks provided by a web framework, then no, they don’t need much math. But if they are to design the frameworks, define the API, or break new ground in other ways, yes, they will be doing mathematics, whether they realize it or not.”

    Was looking for a way to say this but that does it pretty well. While it’s just as bad or worse when people try to trivialize computer science or any other field to “just math” (kind of like: http://xkcd.com/793/), computer science and (perhaps to a lesser extent) programming are absolutely related to math, and while you may be able to find work that can be classified as programming that doesn’t really need math or have anything to do with, I think the deeper, more interesting problems in the field are very closely tied with math (but they are distinct from it, at least imo). Using a programming language that you’ve never seen before may not, at least initially, require much math, but something like designing or implementing a compiler for that language does.

    I sort of feel like the lack or presence of math might be a good approximation at a dividing line between something like CS and IT.

  14. Sam Rose says:

    Math: if it was easy it would be your mom.

    I see a lot of Markus’s points. I think what he is trying to conclude is that math skills benefit a programmer. They aren’t necessarily a requirement, but knowing them will certainly help you become great.

    I also see Crista’s point. Building reliable systems isn’t a math exercise. Knowing how to sort a list on O(log n) time will not necessarily help you build orthogonal, error-safe and beautiful programs.

    There is perhaps a balance to be struck here. There are some areas of programming that require more advanced math ability, and there are other parts that demand a firm grasp of program architecture. Depending on where you want to work, you will need to know one better than the other. A grasp of both will definitely help, though :)

    As for programming contest ideas, one of my coursework pieces in University was to take a badly written piece of software and improve it. There were a few requirements for features that should be added but the implementation details were left entirely up to us. Maybe this style of task would make a good competition. I’m not sure how you would judge it, though.

  15. Oscar says:

    Good rant. I ri-key.

  16. Vic says:

    I’m afraid your naïveté is showing. ‘Programming’ (the term and correctly understood concept) has been around for longer than your idiosyncratic notion of programming (JavaScript and PHP or whatever) would allow. Cf. “linear/nonlinear programming”‘ for example.

  17. crista says:

    @Vic The use of the word “programming” to denote these kinds of activities precedes the concept of “linear programming” by at least one century and a half. The first “programming” activities, as such, pertained to looms. The word is also used pervasively in modern days to denote activities related to scheduling, such as TV and radio programming, independent of whether that scheduling is performed in some automated manner or not.

    Programming, in its more general sense, is the activity of making a detailed plan for execution. Computer programming uses computers as the execution environment. Those plans can be about mathematical concepts like solving systems of linear inequalities or about non-mathematical concepts like providing a “Like” button on your social network site.

    Mathematicians seem to have this concept right; their main symposium in that area is called International Symposium on Mathematical Programming. Some Computer Scientists, on the other hand, seem to have lost some bits of information along the way, and started conflating mathematical programming with programming in general.

Comments are closed.