One of the upsides of working for a university are the stimulating academic discussions. Yesterday, a philosopher challenged me a question:
Beyond the fact that software is expressed in Mathematics artefacts (bits, algorithms), are Information Systems fundamentally Mathematical?
For my convenience, I temporarily rephrase the question to something simpler and more concrete:
How are Software Developers limited by their mathematical weaknesses?
I plan several blog posts around this question, but let me start with an example.
A common and powerful language to process XML is XPath. XPath is used within web applications, scripts, databases, and so on. I often ask students the following question about XPath. Are these two expressions equivalent?
$x="some string"
and
not($x!="some string").
(The symbol “!=” means “different from”.)
Invariably, most students conclude that they are equivalent. Wrong!
Let us examine the semantics.
- The expression $x="some string" means that at least one element of $x is equal to "some string".
- The expression $x!="some string" means that some element of $x is different from "some string".
- The negation of $x!="some string" is that all elements of $x are equal to "some string". (Sorry if it sounds confusing.)
Thus, the expression not($x!="some string") is a  more restrictive condition than the expression $x="some string".
Great software developers routinely think through far more complex mathematical problems. Yet, they do not think of them as being Mathematics.
not sure I follow this example. Isn’t the confusion stemming from the fact that you’re treating $x as a set of objects rather than as a single object, and you’re interpreting the operator ‘=’ really as ‘contains’, and the operator != as something different from “not contains” ?
@Suresh
Expressions in XPath return sequences of values.
In XPath, two sequences are “equal” if you can find one element from the first sequence which is “equal” to one element of the other sequence.
My claim is that thinking through this sort of definition is what good XML developers need to do routinely.
And equality between two objects does not imply that they are the “same” object, so we are not in set theory. For example, an attribute value containing the string “Suresh” and the string “Suresh” are “equal”.
And yes, of course, if $x is a sequence of one object, then $x=a and not($x!=a) are the same thing.
For extra points, is equality transitive in XPath? That is, if $a=$b and $b=$c, does $a=$c? Hint: this may help Itman’s claim that XPath is a lame language.
ok. I understand the semantics now. I guess what I don’t understand is what this has to do with the understanding of mathematics, or whether students should be confused or not. My feeling is one should not use the term “=” to describe the relation you mention, because the relation is not an equivalence relation,(since transitivity is violated). This is confusing because ‘=’ traditionally refers to some kind of equivalence relation.
In other words, it’s actually the use of bad mathematical notation that’s causing confusion here, imo.
@Suresh Well. The notation is what confused you, but my students go through 135 hours of XML.
@Carr I think we need to sell t-shirts with this joke on them. Perfect nerd humor.
Well, once great computer scientists like Adriaan Wijngaarden, Alan Turing, Andrey Kolmogorov, Donald Knuth, Edsger Dijkstra (although a theoretical physicist) and John von Neumann (among others) come from Mathematics (or have a mathematical background), my intuition guides me to believe that excellent programmers have some math skill above the average.
If we think that all computer science (CS) formalism is a kind of mathematical formalism — actually, CS is a subset of Math —, the answer to the title question is “Yes!”
And if you believe that outstanding software developers (that I “translate” as those that deliver codes with almost no error) have a kind of “internal methods for software validation” and relate it with Formal Methods (from Software Engineer), I think you are sure about the answer: “yes”!
Well, my two cents about the subject.
@Suresh me neither. To me, this is yet another example why XSLT/XPATH is a lame language.
The notation is confusing, yes.
Pointy-haired boss: “Your salary equals $100K per year.”
Recent hire: “Then why is my monthly gross only $1000?”
PHB: “Because we hired you to work with XML, and in 135 years from now, you will be making $100K per year. This should all be obvious.”
Is it not the other way around?
“A logician trying to explain logic to a programmer is like a cat trying to explain to a fish what it’s like to get wet.”
Writing not($x!=”some string”) in real code is a fireable offence.
I’d venture that great programmers today are likely to be great writers. Clarity is paramount. Avoiding double negatives isn’t unlikely to make your code less difficult to read. See? That’s shit.
Great mathematicians tend to value elegant proofs. Great software craftspeople value clear code. Math and writing are two disciplines that help; which is more important depends mostly on the problem domain you are facing.
I believe there are underlying qualities that can make people great at math, writing and software development. Being great in one domain implies you can do well in another.
While I’d have trouble vouching for mathematics’ utility when it comes to subtleties in syntactical parsing vis a vis xml transformations, one argument that seems stronger is RDBMSs as a whole, which are founded soundly on set theory. alternatives may have their place, but RDBMS’s still rule the roost. bonus points would be that they are more relevant to the information systems’ question.
In general I agree with the point that this post is trying to make. However, the code example used is sub-par. As previously pointed out, it has little to do with mathematics and everything to do with XPath being a poor language.
I think a better example would be the Haskell programming language which has deep ties to math.
I think so. Because a good developer need a good logistic brain. Mathematics can make your mind very clear on each logic step. So i think it’s right.