Well, I'm a pretty big fan of formal semantics, but at the risk of saying something controversial, I think pushing too far in this direction may be a red herring, Controversial? Just the opposite I would say, as hardly anyone actually wants to apply formal semantics to real problems. It is my strong feeling that programming is, and will always be, at some level, a social undertaking. First, are you making a prediction, or simply expressing a desire? Do you want to see formal semantics put to good use, or are you happier with it just being a game for pointy-headed people to occupy their time with? Second, I think that if you ask mathematicians about their work, many of them will say it has a strong social element. Formal methods and social interaction are not an either-or proposition: that's why, for example, people organize conferences on formal methods, coauthor papers with others on formal methods, and generally work together in groups on formal methods just as they do on software development projects or even, say, -cough- quilt-making. Third, please pretend you have journeyed back in time to 1950. Eager to impress people with the development of future technology only you are aware of, you tell an acquaintance: "In half a century, things called `computers' will make our lives much easier." "Golly," your friend says---because they said things like that back then---"you mean you just tell them what to do and they do it for you, like everyone has their own robot servant or something? That sounds wonderful! I would have him write all my school papers for me, and do my laundry and take out the trash, and answer all the questions about the universe which I could never figure out myself." You reply, "Well, uh, actually you would have to employ a specially trained person called a `programmers' to tell the computer how to do specialized stuff like that (and it can't answer all your questions for you anyhow)." "Gee whiz, `programmer'? That sounds awfully cold and intimidating. What do they do, exactly, these `programmer'-types, and how do they get the computer to do stuff?" "Well, they sit all day in front of a keyboard, typing in text written in a special, technical, formal language, which eventually translates into numbers, which the computer processes by arithmetic." Your friend starts looking queasy, so you hurriedly add: "Actually, it's not as bad as you think, though: almost everyone in 2003 spends hours in front of a computer, reading mail messages, communicating via instant messengers, surfing the Internet, chatting electronically, and so on." "That sounds horrible!" he says. "Why, it's the most inhuman thing I've ever heard. If I wanna talk to a friend, why, I'll go over an' pay him a call personal-like, so he knows I really wanna see him. Or, if he's too far away, I'll write him a letter, in my own handwritin', so he can see I spent some time on him. And the prospect of sittin' in front of a machine every day for hours on end, why, it just sounds like the most lonely, isolatin' thin' I ever did hear. An' these `programmers' sound like automatons, slave laborers in the most horribly repetitive and mind-numbin' factory I can imagine! Pushin' numbers all day, prolly speakin' in numbers too. Are they even human?" "No, no! It's not like that," you insist, "you can still see friends in person and still write real letters. But that takes so long, and if you can do things more quickly via your computer, it just lets you communicate more (and more often), so the upshot is mostly positive. And, really, programmers are actually quite social. Although they create things which are formal and technical in nature, the way they interact to get those results is organic and creative, though admittedly they have to follow some rules which are unavoidable and imposed by logic, or the computer, or the programming language itself." "Bah, I don' believe you!" says your friend. "`Computers', `programs', `programmers'... It all sounds like in your future them Russkies already done come over an' turned our wonderful nation into some kinda authoritarian nightmare. When'd you say you came from? 1984? Cough it up, you're a commie, ain't ya, boy? Tryin' ta pervert our beautiful way of life with your ungodly ways. Lemme tell you something, and lemme tell you so it's crystal clear: we ain't never gonna let something like that happen in this here country, by God." OK, I got a bit carried away there at the end... :) The entire idea of name overloading is to take operations that are not, in the formal sense, precisely the same and draw an analogy between them. At a very fundamental level, this involves a social convention, an understanding (or guess, or theory, or whatever) of who the other readers of the program will be (including yourself at later times), the greater context of the code fragment in question (language idiom, project idiom, stylistic choices...), and so on. I disagree. Semantics often give more than one equivalence on things: in one sense they are different, but in another, coarser sense, they may be the same. So I would restate your claim as: The entire idea of name overloading is to take distinct operations that are in some formal sense the same and draw an analogy between them by giving them the same name. For example, we use the same symbol for addition of integers and reals because the addition operation obeys the some of the same properties in both cases. Are these two additions the same operation? Certainly not: they don't even operate on the same sets. But they are equivalent in the sense that they're both commutative, associative, etc. It would be pointless to identify operations (in the same scope) if there were no formal basis for the identification*, because the whole point of using symbols for things which are themselves not symbols (the denotations of those symbols) is to do formal manipulation. *(There is one reason for doing this: when you don't want to manufacture a new name.) The social aspect here is the choice of name or symbol itself, for example whether you write addition as + or * or & or what-have-you, and, only in cases when it is sensible to do so, the choice of when to identify things rather than treat them distinctly. In any case, I'd like to state unequivocally that I'm a strong believer in semantics for programming languages, and I'm a strong believer in elegant language design. I'm just convinced that it's not a silver bullet, It's not a silver bullet, but why does it have to be? Formal semantics won't do your cooking and cleaning or keep you company late at night. So what? But in this case, it is not only applicable, but also far more successful at giving answers to questions than---well, what is your alternative, anyway? Group discussion? Long, hard thinking? Prayer and finger-crossing? Those are approaches, not methods: isn't software development supposed to be an engineering discipline? I believe that sooner or later these issues of convention and interpretation will show up, because I think they're basically built into the kinds of abstraction that programmers love so much. Convention is one thing, but problems of interpretation are exactly what formal methods and semantics are designed to solve, and have been successful at solving in all other scientific and engineering fields.