4 ms·

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 neve

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?

jerf 12y ago
"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.

jerf 12y ago

"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.