Thursday, August 28, 2014

Thinking out loud meets programming

So, I may have mentioned elsewhere that I've settled on Frink, for now at least, as a handy prototyping language, mainly because I can do it relatively easily, and anywhere. OF course I'm probably going to have to convert it all to Javascript at some stage in the future (there ARE alternatives, but that seems like the most likely path) because I want to create this functionality as a web app or a mobile app, but I can't seem to set up a handy coding environment for JS. I'm not saying it can't be done - just that I can't see my way to doing it easily with the knowledge I have. Whereas Frink and Dropbox and I'm done.

When I started out on this project a while ago I thought I'd end up using Prolog, because of its history in language processing. So I detoured for about 6 months teaching myself Prolog. Then I decided not to use Prolog.

Now I'm well into the prototyping stage. I'm a shocking programmer, I van never plan anything. I just right crappy little programs, see a problem, re-write them, and iterate. After a certain point, the rewrite load becomes very onerous, and I always think, if only I'd planned this. But bluntly, if I had planned it, nothing would have happened at all. At least this way I have dozens of half finished projects.

One of the problems is, as discussed previously, knowing the intention of the writer, so as to provide appropriate feedback. One equally obvious solution is to ask the writer their intentions. However, for a couple of different reasons, it's not such a good idea to use technical language in asking the question; at the very least you might be assuming that the learner knows what you're trying to teach them. So I don;t want to ask, What's the subject of this sentence? because if the student knows what a subject is, there's a good chance I don't have much to teach them on that issue. So instead I ask, What's the main word in this sentence?

Yes, well, take a look at that red sentence fragment - I would think the most likely answer to the question about main nouns would be "chance". But the subject is "There" - to navigate from "chance" to "there" and keep my "unassuming" interface, I need a set of special rules to handle, what, clefts; existential there; empty it; plus anything else that comes along.

In fact, it occurs to me that a rule manager might be a really good idea, because there's an awful lot of rules. Gee, what about Prolog? It is built around rules... If only I were a competent programmer. Grrr.

I'm going to resist the temptation to take another 6 month detour into Prolog, because, even if it worked (and history suggests I'll get distracted), that isn't actually going to help my HTML5 application. (although I feel sure someone has implemented logic programming in Javascript).

I'll think about the rule manager later, anyway.

It may also be, of course that the "main word" question isn't such a good idea - but I'm going to stick with it for a time. It's non-trivial. Words like Noun and Verb do not denote universal constructs of the human brain; we very much understand them intuitively via the language in which we use them. What, exactly is a Subject? You may know, for your language, but it's not likely to be universal. There's a popular assumption that the Subject is the Agent of a transitive verb; that's certainly not true of all languages; it isn't really even true of all verbs in English. How about, the Subject is what the sentence is about? See note above... What about "grammaticalised topic", which I saw one in the linguistics literature? Some languages have "grammaticalised" topics and subjects...

Note also little conundrums (conundra?) like Subject-Verb-Object, and Noun-Verb-Noun; it's a concern to me that two quite different theoretical conceptions of a sentence use the same word for one part. If you're talking to technicians, you can use a jargon which avoids/acknowledges/minimises these problems, but when you're coaching a learner - they're not an expert.

Back to the bad programming...


Wednesday, August 20, 2014

thought for the day

The iconography of diagrams is not transparent. Discuss, with particular reference to language skill testing.

posted from Bloggeroid

Tuesday, August 5, 2014

Thinking out loud...

So...

If one of my students writes "One plus one equals three"(1) how should I respond? Or alternatively, "Colourless green ideas sleep furiously"(2)...

Obviously both sentences are syntactically correct, and I'd obviously be quite pleased with that. But is it fair to let them walk away thinking this is correct English? Is it correct English?

(1) is not good mathematics, I guess. But it'd be fine in a sentence like "It's possible to design a mathematics where 1+1=3", which I feel sure is the kind of things young mathematicians say to each other when they're a bit bored. So it might actually be excellent mathematics - it's just that it's not common mathematics; that is, it's not part of the common misconceptions about what constitutes mathematics. Alternatively, it might arise from a mistaken idea of what any one of "one", "plus", "equals" and "three" means. Or again, it might be intended as some kind of figure of speech. From all that, it appears that it may not be "wrong", and even if it is, it's not actually possible to say what the mistake is.

I can only comment 'Usually we write "1+1=2" or "1+1<3 p="">
As far as Chomsky's famous saw (2) goes, it amuses me that time has rendered it fairly easy to read this as "The unimaginative ideas of the environmental movement are ignored by the powerful despite acrimonious debate." I might deem it unlikely that one of my students has perpetrated such a monstrous wordplay, but it's a bit dismissive. A whole bunch of them are smarter than I am. Perhaps they've read Chomsky. Perhaps they enjoy puns.

These are extremes, sure. Extremes help cast ideas in relief, which can be a useful clarifying technique. Most of the sentences I correct are not, in fact, syntactically correct, so it looks like an easy business to document the errors. But actually, correcting the errors means assuming that I know what the meaning is that they wanted to express; by analogy, if I offer only "1+1=2" above, I've ignored the possibility that the required correction was "1+1<3 p="">
I'm thinking about these things because I'm thinking about software that provides feedback to students, to increase the volume of feedback they can receive from non-trivial texts (textbook drills are 99% trivial, and about equally useless). Purely rules-based software doesn't work - I guess it could provide a large list of broken rules, but it's not clear how helpful that would be - and software isn't that good at "meaning". No doubt it will get there, but it looks like quite a tricky journey. Right now, it relies largely on statistical evaluations of collocation, which it do quite successfully based on correct input - but we're talking about incorrect input.