Make Way for the Interpreters
The dream of the universal speaking/translating interlocutor will not die. In some ways, you can see Siri as the latest civilian incarnation, in a line that extends through Schema, Rosetta, XML, back to X.500: the committee that convened to sort out who and how all communications ought be connected (only to be whipped by a college student). When the nerd engages in hubris, it‘s usually with a quaint smile on his face, and the demeanor not of a conqueror, but a catacomb-dwelling, light-starved goblin. I think we could all agree that of that long and tortured lot, only Siri can be said to have achieved much of her original promise.
One of the jokes I tend to carry around about software design is all models eventually become conduits between Interpreters. I would be willing to bet (here I go again) that I could take 10 developers into a room and ask them to go to the whiteboard and sketch out the implementation of an Interpreter and maybe one or two could do it. And yet, the other 8 are swimming around in interpreters as users every day of their lives. Generally, what tends to happen is that projects eventually find the only way to expose their burgeoning semantic tree is through an interpreter. The rage over DSLs? You guessed it, just a quicker, slapdash route to Interpreter.
For all of its obvious importance, it‘s constantly remarkable how much pain must be endured with most software before the makers will embrace the need for a real interpreter and make a good one. Many never do. The program I mentioned in my last post, Identify, is basically a data scraper. It gets a little information from the actual source (a video file), runs off with it to a database (themoviedb.org) and scrapes out the other data and comes back and puts it into the tags of the file. Great! When you start to see it in action, though, you realize that this was done as a rapid rise loaf of white bread, not a fermented dough. Not here to bash it, I think the app is great, and frankly, could easily argue the other side of the equation, which is always haunting all tech undertakings: if full automation is not possible, is it not better to start with something that embraces and eases the required human assistance? Of course it is.
That said, as a mental exercise, let‘s consider how this model could be improved:
- The app uses themoviedb.com, but that in turn uses imdb, so if you have the imdb number, you get all your data for sure. Looking it up is not terribly hard, you simply search (btw, imdb is another great example of a really poor implementation of interpreter, as you can be super specific and still almost always end up being asked to pinpoint exactly what you were looking for). Anyway, once you get to the detail page on imdb, you clip the number out of the URL. So in this case, we are basically just getting scraping services from this app ($10 in the store, btw).
- If you give it some additional information, it says it can be more accurate. I found this to be false. I scraped a film last night called White Nights. Actually I started with the Italian title, and gave it the year: 1957. Identify picked the Hackford/Baryshnikov film. Interpreters must be able to do stepwise refinement of selections, e.g. given this much information, here‘s your answer. Of course, this requires that the interpreter is able to parse what it is given. Dude, it‘s a bloody form! I put the 1957 into a field labeled year!
- What would make a lot of sense, though, would be to do something where you also potentially LEARNED!! This problem has machine learning written all over it. For instance, the filenames are going to be the same in every ripping experience. The first time someone tags that, next time you see that filename, that should be your first guess. This application decided to go the route of just passing database duties through.
Ultimately, Interpreter + machine learning is one of the powder key combinations of the next decade. Look at the crazy, raving reviews the calendar app Fantastical has gotten. I have written three apps for the iPhone/ipad that functionally are immensely more complex than that app. What it does is interpret what you want it to add to the calendar, and yes, it does it better than Siri and iCalendar. The other differences would have to be deemed slight to say the least. Flicking through days and using a gesture to move between views is great, but is that really all it takes to get a reception like Dick Cavett welcoming John and Yoko?
Learning interpreters… they may not be poised yet to take over the world, but they are finally going to break out the fungibility of software and release it from nerd captivity.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)