Dead Languages

Over on edu-sig we've been discussing the teaching of math as a language, or set of partially overlapping language games, including with more machines getting into the action, since Turing especially.

Glenn and I walked Sarah this morning, got her toe nails clipped, discussed Alan, working conditions at Bletchley Park, the UK's Navy Department's resistance to this new kind of intelligence and so on -- Glenn is perusing a new biography of the guy, plus we're both Neal Stephenson fans.

Computer programming has been around long enough, since Ada Byron's groundbreaking speculations, to give us "dead languages" already, but that's a somewhat misleading term, as a "dead language" may be very much alive in terms of continuing to run.

It's more just that brand new or so-called greenfield projects tend to go with more contemporary offerings, given ongoing advances in our tools of the trade. You don't start new COBOL projects, but may tend an inherited code pile, keep it "well oiled" so to speak, i.e. in running condition.

Some of the best matrix manipulations still happen in FORTRAN, and there are ways to wrap code in other code, such that a Python coder might hand off to FORTRAN and receive back -- so again, being a dead language doesn't get you off the hook from being in a responsible position necessarily.

So how shall we go about recruiting new talent into maintenance jobs? Aren't those too unglamorous, isn't the danger that dead languages will have no new students? In answer I say, look at ancient Sumerian, how people still study it, even in the 21st century. To be a serious-minded computer programmer might mean knowing two or three dead languages and a few contemporary new ones. It's not either / or.

That being said, some dinosaur operating systems and / or applications run too inefficiently or ineffectively or have otherwise exceeded their warranties, their maintainability.

Especially in light of how open source philosophies have driven down costs, lowering barriers to entry, those with the right skills have many more realistic pathways into the future to choose from, if anything have too many options rather than too few (I'm not complaining).

So whereas I think it's safe to envision some classical FORTRAN packages continuing in operation for decades to come, a lot of the vertical market stuff, especially if aimed at specific hardware, will find (has maybe already found) it has a shorter active duty cycle.

I'm sure many of my peers have come to similar conclusions, although usually in connection with a more specific company, silo, brand or project.