Although common algorithms like that for N! (N factorial) can be expressed in most of the more widely used computer programs it is not true that these all produce roughly the same object code for the same processors or have similar properties when executed.
Even something as simple as the hello_world.c program produces different code when compiled with the Sun and Gnu compilers for Solaris/SPARC, while equivalents written in other programming languages or for other processors produce quite different binaries; even when, as in the Gnu case, the compilers share the same infrastructure.
Since whether you write in C, Perl, or Lisp doesn't make the slightest difference to the outcome - the computer prints "Hello World" somewhere - you'd think these internal processing differences wouldn't matter, but there are cases where they do.
Some of those are traditional: in code written for something like the Mars landers every bit you don't send is a bit that can't go wrong; more prosaically, early block releases for many embedded products have very limited processor and memory capabilities - meaning that if you want the Harris RTX2010 to print "Hello World" somewhere you're going to learn Forth and discover the joys of binary debugging.
Others are futuristic: the current Sun CMT/SMP series and Freescale's future e700 both offer developers the option of relying on hardware for guaranteed multi-thread syncronization with no software overhead for parallelism at all.
Either way, however, differences associated with "the same code" at the binary end are, and will continue to be, important to some people for some purposes.
Thus functionally equivalent programs aren't equivalent at the bit level - but what about the more global or conceptual level? Surely hello_word = HelloWorld regardless of programming language?
No.
At the global level the big differences aren't in the code, but in what you use the code to express; i.e. the algorithms selected.
This doesn't matter if you're just printing "Hello World", but consider something more realistic in scale and the degree to which your choice of a programming language dictates not what you do but how you do it expands considerably.
Consider, for example, the core of a claims processing system. You have some group of authorised providers, some group of people to whom your providers provide services, rates for every service provided, and an agreement under which providers get paid for their services if they file a claim with you and everything checks out: the recipient is eligible, the provider is legit, no limits are being exceeded, and the rate claimed is right.
Do this with COBOL and the edit verification, eligibility verification, payment processing, and the actual check cutting all become separate processes handled via a loop like this:
In the late seventies these processes took about 850,000 lines of COBOL/370 and maxed out a 370/168 on I/O at somewhere around 100,000 claims a day.
In Perl today you'd treat each set of records as an array, and build your verification processes through the creation of an associative array for each output case - with survivors getting a check. I haven't done it, and suspect it would get messy because of all the limit rules, but the overall process is conceptually simple - probably under a hundred lines of code all in, and it's hard to imagine that loading and processing an array of 100,000 claims would tie up a 64GB Sun 890 for more than a couple of minutes.
The point, of course, is that you don't imagine a million row associative array when working with COBOL, while Perl programmers don't instinctively do repetitive record at a time processing. In other words, the programming language you think in shapes the algorithm choice and therefore affects both how you think about a problem and how you solve it - that's why COBOL programmers working in Perl usually just write COBOL using Perl notation.
So, bottom line, languages aren't equivalent at either the bit or global levels.
A special note:
I'm outta here for a week: not holidays, a family wedding in Portland (OR) - but actually, rather than just intellectually, out of touch until next Wednesday because all comm gear is staying home with the dog - and he's not authorised to answer e-mail.
Meanwhile Mr. Editor Person will be posting some blogs I wrote in advance, and next Monday Roger Ramjet will kick off a week of job hunting discussions with an essay on his experiences with the dubious joys of job hunting.