Ask those maintaining COBOL applications inherited straight from the 70s :) There are even people selling toolkits to convert 5250/3270 applications to web apps through "terminal scraping" (uuugh). No doubt in 20 years we'll have some equivalent windows+VB monstrosity :)
Terminal scraping is "universal" (it is language agnostic; it's much easier to get a system emulator working perfectly than multiple compilers/language environments).
a.c: int a;
$ cc -c -o a.o a.c; nm a.o
0000000000000004 C _a <-- "common"
a.c: int a = 1;
$ cc -c -o a.o a.c; nm a.o
0000000100001040 D _a
FORTRAN functions can be called from and call into C or C++ (extern "C"'d) without any issue. Simplified example: foo.f:SUBROUTINE FOO
foo.f:CHARACTER*80 LINE
foo.f:INTEGER*4 NUM
foo.f:CALL BAR(LINE, NUM)
foo.f:END
bar.c:void bar_(const char *line, int *num, int len) {
bar.c: /* implicit length for string arguments, values as pointers */
bar.c:}
foo.f:SUBROUTINE FOO
foo.f:END
bar.c:extern void foo_(void);
bar.c:void bar(void) { foo_(); }[And Fortran does have scary aspects: from the 25 year old hacker's test: "Did you ever change the value of 4? In a language other than Fortran?" - numeric literals in fortran aren't constant!]
Most fortran floating around is cross-platform fortran, and that is quite easy to port. However, legacy systems are usually very much platform dependent. I was once hired to port something in Fortran from a System 3090 (or was it 390? That would be more than 20 years ago now) to an SGI workstation, and it took several weeks of full time work.
And you're ignoring the subject under discussion: Porting a working system comprised of multiple parts in multiple languages (COBOL, Fortran, ASM, REXX, ....) is a much harder than the sum of porting individual programs - which is why emulation + terminal scraping is the cheaper, more robust solution.
It's works better than expected. You avoid the costs and risks of re-writing the application and re-training your personnel.
This pretty much sums up my experience with legacy VB6 code. I've re-written a fairly large system that was entirely in VB6 and some of the code I encountered there was astoundingly bad.
I only say this because the story is pretty analogous to PHP's. And I'm not saying that to bitch about the language; it's just the way it's gone.
Now don't get me wrong, everything new is all web based product, but these older apps keep running and we keep updating them. Until they _need_ to be replaced entirely, well, there just isn't a business case for the expense. No doubt it'll happen... I've been mentally preparing clients for years... but most of them dodged expense of a .NET rewrite and will move right into Web apps when that day comes.