In the paying work, as you know, I am a technical translator these days, and that means I work with CAT tools (computer-aided translation - keeps track of stuff you've already done so you don't have to do it twice). The main CAT tool on the market is TRADOS - a name that dates it, as it sounded modern (like DOS!) when it originated in Germany in the 80's. At any rate, TRADOS has some odd ideas about rent-seeking versus more modern openness, because back then, you had to code things down to the metal without any help from anybody and by golly you felt you deserved some money for that. The upshot is that the TRADOS Freelancer version restricts a freelancer to working with five installed languages.
My problem is that I relatively frequently work with seven: English, German, French, Spanish, Italian, Hungarian, and Portuguese.
The TRADOS solution for changing the languages you currently have installed is easy: uninstall the entire tool, then reinstall from scratch; during the reinstallation process the language wizard asks you for your five languages.
Since the TRADOS install process takes twenty minutes, this means considerable effort when switching the cards you have in your hand (in Yugi-Oh terms).
I've been working with a lot of Portuguese and Italian lately for some reason, so this has really been a bother this week - and finally I decided to hit Google and figure it out. Sure enough, those languages are stored in a Registry key (the translation industry runs on Windows). In the older pre-2009 version of the software, the key is relatively understandable, while in post-2009 versions there is an opaque lengthy binary value that I haven't figured out yet, but the key is this:
You can change your language selections by diddling with the Registry.
Well. In Perl, of course, we use Win32::TieRegistry to work with the Registry; it allows you to treat Registry keys as hashes and do the obvious things to modify them. But if I want to distribute a convenient tool to make this available to the unwashed masses - and I do! - then I should probably write that tool in C/C++ with a bog-standard resource-file GUI, because distribution of Perl is not trivial enough to make it worthwhile for a simple utility.
But the model of the Registry, and therefore the model of actions I take against it, should be shared between those two approaches. At a semantic level, we are talking about the same thing. But without a semantic language, I can't really realistically do this. And so in a certain sense, what we're talking about here is defining a model of the Registry, and then a model of the actions I want to take against it (in some abstract form, like a template or something). The model of the Registry maps onto either Win32::TieRegistry and Perl, or it maps onto some library code and template-y stuff and C/C++, and the actions then can be expressed in either language in some as-yet-unexamined way.
That's what I'm talking about when I talk about semantic programming.
Now let's take that as a given, OK? Because I want to address an even more abstract concept along these lines. At a higher level, the Registry falls into a "value store" bucket that could include e.g. XML in an initialization file or other kinds of configuration files. At that higher level, the choice of a specific form of storage is an architectural decision; in other words, the architecture of a program is in a sense independent of the actual program - in that we could take a given implementation of an algorithm and "translate" it from reading an XML config file into reading the Windows Registry, and everyone would agree that is the same program (in a sense). The problem is that this kind of port is essentially a fork; changes made to the syntactic-level program on one branch are very difficult to translate back into the other branch.
And that's also what I'm talking about when I talk about semantic programming.
Anyway, sometime soon I hope to build these little Registry tools. In general, it would be nice to think about the general set of all Registry value utilities and how they could be addressed by a semantic domain in this manner.