Programming without math, part 2

Continuing the thread from yesterday…

There is a reason that programming necessarily started out being very math-centered. It had no choice. Back in the 1950s when FORTRAN (essentially the first high level programming language) burst upon the scene, there was no interactive graphics, virtual reality, or real-time graphics acceleration. There were no high resolution LCD monitors and there certainly was no computer mouse. The very idea of interacting with “objects” in real-time on a computer screen – or any nascent glimmering of such an idea – was still the stuff of science fiction.

In such a world, math became central to programming because math is the great recourse when all else fails. You may not be able to see a world, to touch it or sense it, but you can indeed use mathematics to describe it. In the absence of being able to see, say, a round spherical ball on my computer screen, I can always type in the mathematical description of a sphere, and use that description to help me program my computer to make the ball roll, or bounce, or do anything else.

This was the world faced by the early computer programmers. They were literally working blind. All they had were their mathematical descriptions of things, and so naturally computer programming grew around that central, highly empowering way to describe everything. It’s no wonder that the concepts and methods of mathematical description became deeply embedded into the DNA of programming culture and practice.

Even something as seemingly fundamental to programmers as the “=” assignment operator is a math concept, not a programming concept. It basically says “give this thing a new identity.” In the real world, we rarely do such a thing. Rather, we impart new properties to things that already exist. We paint a wall, or we drive ourselves to work, or we make another person smile. Yet we take it for granted that programmers are supposed to write things like “a = b”, because we are so used to seeing the math embedded in the programming that we forget it’s math, not programming.

Programming without math would be much more likely to have operations like “make John smile”, or “drive to work” than such an abstraction as “a = b”. And that would make it much more interesting to a lot more people.

4 Responses to “Programming without math, part 2”

  1. Dean says:

    I think about this a lot, from time to time, I’ve yet to solve the problem. These two posts have given me a new train of thought. If I can expand your title, “Programming without math to solve problems that don’t need programming with math”. The range of domains that can be helped with programming solutions is broad, some need Programming With Math and some need Programming Without Math.

    I have a sense you are headed somewhere a little more specific with this discussion, am curious to see where you go.

  2. Douglas says:

    One of the things that I like about C++ is that it’s really universal. You could do anything with it that can be done by a computer. I’m not sure one could preserve that universality with the sort of programming language you are hinting at. Would it still be possible to write a raytracer in your language, or a device driver? Of course not everyone needs that. But you may run into a wall eventually.

  3. Andras Kanegson says:

    Me != person w/ math ability

    increased programming ability + me = me ( smiling )

    Ken / figuring out a less math focused approach for programming = 7 billion (me * smiling)

    + | –


  4. Andras Kanegson says:

    Even pidgin math is challenging!

    I totally get what you’re saying and I think you’re right to anticipate possible limitations in the kind of programming Ken’s thinking about. But your response also illustrates the predicament wonderfully.

    I’m going to go out on a limb here and posit that mathematicians are universalist by nature in that their logical mind space requires the rigorous consistency of math for every task no matter how trivial. Indeed, triviality doesn’t exist in math. (right?)

    Thankfully, most non-programming procedural functions like Ken’s example of cooking, can work perfectly well in a less codified and rigorous, but still logical, mind space.

    I like to think of it as being okay with 1+1+1 = 3 as opposed to requiring 1 * 3 = 3 if the former is sufficient to the task and increases accessibility. This approach may not have the elegance or functionality necessary to cook a ray tracer, but then having the skills of a 4 star French chef is not the qualifying price of entry to making a yummy and nourishing meal. Also, it’s possible that facility and understanding can grow over time as the threshold of difficulty diminishes.

    Unfortunately, as it stands, programming demands pretty elite cooking (math) ability and as a result, far too many are just going hungry.

    I can understand that the idea of taking programming to a more accessible and less math-focused place might be hard for some programmers to stomach. But in the spirit of a healthy symbiosis, as computing is drastically transforming our society, I think great minds need to look at transforming ‘programming’ to be more engageable and useful to a wider audience.

    In other words, I’m rooting for you Ken.

Leave a Reply