A lot of the tools I build for my own use are command-line-based (the various perl Shell modules are pretty useful and very quick to put together), so lately, since REST APIs seem to be a really nice way to build new functionality, I'm thinking, how can I do a command line in the browser?
Seems I'm not the first. Blue Sky on Mars posted on this topic in 2011 and even started a Google Group (which unfortunately didn't last too long). These were more focused on shell replacements, though, which is more than I want or need.
But hey - Josh.js is perfect. And the examples are easy to understand. Add this to a Mojolicious backend and I think I've got a pretty snazzy way to organize functionality.
Tuesday, October 22, 2013
Sunday, October 20, 2013
Sunday, October 6, 2013
LDSR
While sleuthing around with the Trados thing day before yesterday, since the key for Studio is "LDSRClient" (which brings back no Google hits), I naturally tried to figure out what language-related thing "LDSR" might be, and found the Linked Data Semantic Repository (now renamed as "FactForge" - the "fast track to the center of the Data Web"), which appears to be a collection of various, well, linked data from the Internet, in the form of semantic chunks of some kind.
Anyway, it's interesting stuff.
It's been used to (kind of) respond to something called the Modigliani test, which is essentially, "Given the fact that there is an artist named Modigliani, tell me where all his paintings are located using public data". That's actually impossible right now, but the guys responsible for FactForge tried their hand at it using their repository, and found six of the paintings in public data - which is really impressive! - but as they say, it took a trained expert an hour to assemble the query.
So: the Semantic Web, or the Data Web - interesting stuff.
Anyway, it's interesting stuff.
It's been used to (kind of) respond to something called the Modigliani test, which is essentially, "Given the fact that there is an artist named Modigliani, tell me where all his paintings are located using public data". That's actually impossible right now, but the guys responsible for FactForge tried their hand at it using their repository, and found six of the paintings in public data - which is really impressive! - but as they say, it took a trained expert an hour to assemble the query.
So: the Semantic Web, or the Data Web - interesting stuff.
Saturday, October 5, 2013
Semantics and the Windows Registry
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.
In a semantic programming paradigm, they wouldn't be. You'd be working at the level above the architecture, and simply "compile" the specification into specific code in different languages on different architectures with different choices made in terms of protocols, storage locations, Web server back end, database, JavaScript front end, and so on.
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.
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.
In a semantic programming paradigm, they wouldn't be. You'd be working at the level above the architecture, and simply "compile" the specification into specific code in different languages on different architectures with different choices made in terms of protocols, storage locations, Web server back end, database, JavaScript front end, and so on.
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.
Thursday, October 3, 2013
Subscribe to:
Posts (Atom)