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.

Thursday, June 26, 2014

Software development 003

Right - it's been a couple of days while I tried to sort out my next step...I've been doing a lot of reading.

I recognise a pattern here, a period of intense frustration trying to work out how to do something new without adequate documentation, and also with a great deal of scepticism about documentation. There are plenty of books &/or websites about writing HTML5 apps; but they each take a lot - a different lot - for granted. Without a deep knowledge of the field - so that you don't actually need to read the book - it's almost impossible to say whether the author is presenting some quick-and-dirty methodology for churning out rubbish so as to get their next book to press, or whether the methodology is out-of-date, or over-simplified. Very, very few writers bother to place their material in context. That annoys me.

I reckon this pattern has occurred pretty much every time I've explored some technology in the past 10 or 12 years. The kind of book I personally want isn't being published. Now, that isn't necessarily the fault of the publishers; after all, I may be an audience of one and that's not likely to be a very rewarding market. It's more likely that, actually, this situation is inevitable given the speed of development, the fragmentation of technologies, the plethora of platforms, the general overwhelmingness of it all. (How come "overwhelmingness" isn't in the dictionary? Ultimately, I've got through the frustration, worked out a tenable hypothesis for going forward, but to do it I've read (OK, skimmed) five books and about twelve websites. Plus, I've accepted that I'm going to have make the answer anyway - all that reading has got me is a decent foundation for personal research. That's this next weekend taken care of. That plus the European championships. And do you know who won the World Cup? Right, Australia, 6-1 over the Netherlands. Strangely it's gone unreported.

I enjoy this kind of thing, in a masochistic way. It's epistemologically challenging as well as being a puzzle with practical rewards for solution. Knowledge, after all, is contingent, fragmentary, constructed. The definitive encyclopaedia is a fantasy of the past. Mind you, this type of work reminds me what an attractive fantasy it is and was.

However, this blog is dual-themed; I'm trying to write an app, that's true, but I'm also thinking about other people writing apps, and in particular I'm thinking about non-specialists writing apps, be they mobile or web, as adjuncts to their non-programming job. To what extent, and how, is that possible? These are very interdependent questions. If it's very very difficult, then its being widely necessary is going to be a disaster, because it won't be possible. Maybe it can be made easy - but then (as alluded to in a previous post) we're in tool territory and that raises more layers of questions.

By analogy - Presentation managers (like Powerpoint) and spreadsheets (like Visicalc - or Excel) are tools that let people accomplish quite complex things in a more-or-less adequate-for-their-purposes kind of way. Some people, with no/little programming knowledge and less (if possible) experience write some quite startlingly complex applications in spreadsheets. Undeniably, for an IT department they're a nightmare, and when your accountant leaves and you find the entire business is documented in a miasma of incomprehensible functions, formulas and cell references you're likely to curse at least mildly, but for all that vast chunks of the business world survive on these things. And presentation managers - most presentations are terrible from an "expert" point of view, but most of them are adequate-for-purpose, and most of their creators were self-taught. Inelegant as it is - like conceding that Macdonalds is actually better than La Madeleine - good enough is actually more than good enough.

And the point of all that is - the fragmentation and dynamism of computing technology means that only extremely gifted people can be generalists covering that field. Without some intermediary tools, HTML, CSS and Javascript knowledge are of no earthly use to 99.9% of the people who aren't using them every day as core tools of their job. I can sit down and knock out a multi-user application in Excel in a couple of days, if it's reasonably simple (and it usually is). To implement the same functionality with the unholy trinity would take a month.

So, I wonder what tools there are? None that have caught the attention like the Microsoft juggernaut did in the 80's, that's for sure. And, what's the organisational cost/benefit analysis for those tools going to be?

Friday, June 20, 2014

Software development 002

What decided me to plunge back into app coding was that I saw a couple of articles on Firefox OS (which, as a person partially - yet strongly - committed to standards, I have been keeping a lazy eye on) saying that it was now possible to code an app for Firefox OS - which means using CSS, HTML5 & Javascript: see previous blog entry - and INSTALL and RUN that app on Android so long as at least Firefox 29 was installed in the same Android context. That's not perfect, because assuming the whole shebang works, I'm still going to have to tell students to install TWO things, but it's a psychological hurdle mounted in a couple of ways because:

  1. Firefox has mindshare, not like Frink, so I can avoid the "what is it?" conversations
  2. Some people will already have Firefox installed
  3. There are plenty of Firefox selling points separately
  4. It's a big step in the right direct; and Mozilla may manage to make a couple more, leaving Firefox out of the process altogether.
  5. No-one has to explicitly deal with Firefox post the installation; the app-runner is a background process
So, this is as close as I think I need. There's always a reason to keep on waiting for perfection, and I suspect that to an engineer, you only ever get P - delta 

I started by downloading the sample app "battery charger", and it works as a web page (i.e. by pointing a browser at the index.html file. It also works in the simulator which Mozilla provide as an add-on to Firefox; that's a new process to me and two things strike me immediately - one is that no set of instruction that can be written in finite time is ever going to be comprehensive (installing & running the App Manager / OS Simulator) but it will likely be close enough for a bit of fumbling to get you there. NB. Second is that this simulator works about a factor of 10 times faster than my Android simulator used to run a couple of years ago when I was trying to learn *Java-for-Android-in-Eclipse*

NB - this is not trivial, something that developers routinely forget. Non-experts get anxious, and if/when you are delivering - tools/courses/training/whatever - anxiety breeds resistance. The anxiety can't be avoided, but it can't be resented and it needs to be pre-empted if possible & managed if not.

The next step was to try to install this app to an actual Android environment, and get that working. It hasn't yet, although I've not spent more than 5 minutes and three different attempts. It's going to need more than fumbling; it's going to need thought. Anyway, I'll come back to that, because I'm sure it will be possible and although it's the main game conceptually, the biggest hurdle for me personally is app design and coding.

There's some helpful advice about app design and coding on the MDN - this M stands for Mozilla in Mozilla Development Network. It's helpful, but it (will) illustrate(s) a problem with crowdsourced materials because this advice is very simple; it assumes you know practically nothing (which is exactly my case) but other advice elsewhere is written for a much more knowledgeable coder. Moving through the materials, people are likely to alternate between patronised, supported and bewildered. (Can you alternate through three things?) 

The good piece of advice is "Write down in one sentence what your app will do". OK. My app will illustrate various (user-chosen) textual features in authentic (user-chosen) texts. That is simple enough to design, although it hides a lot of potential complexity. (What is "authentic"? Unrestricted choice? What does illustrate mean here?) I have a raft of further ideas, but I've drowned in my own pools of complexity before, so that's it for now. I'll talk about the questions later, but for now, I want a home screen with 2 (or 3) buttons. One will say "Choose text" and open up a list of texts to choose from. The other will say "Choose feature" and likewise open up a list of predetermined features - things I've worked out *how* to illustrate. The third button is just there for existential reasons.

The home screen will also have a header and some boilerplate text to explain what, where & how. Later on I'll add navigation and control features...maybe.

At this stage I know enough about Javascript to code a very simple program. I've read more about it that I've used. I think I understand the style  of the language. (I program by the simple expedient of writing speculative code and debugging it until it works. Usually after a couple of years per language the debugging is significantly decreased.) I understand HTML pretty well, and I've read up on HTML5. I grew up on markup languages (I was a proof reader once) so they don't phase me, plus I don't really think HTML is where the main problems lie in this architecture. For me, CSS is the big scary animal, on lots of levels.

Firstly, I'm not good at design. I'm a content-first animal; I'm not arguing for it, I'm just observing it in myself. I know how useful good design can be, and I know also that it is a sine qua non of the 21st century. If it's not competently designed, no-one will look at it. While this is a learning exercise for me predominantly, I'd also like the end product to be at least a little bit usable, even useful and used, perhaps. So I am really going to try and think about design. But it makes me anxious. Secondly, I hate the CSS syntax. Thirdly, I hate learning things which appear like a mass of details which I'm going to forever have to look up.

I think the final comment for today - I went looking for code to steal & modify in the "snippets" sections of the MDN. There's some useful stuff - but nothing I've found about designing home screens yet. Sure it may not be rocket science, but some mention of design & coding principles would be useful...???

Tuesday, June 17, 2014

Software development 001

I thought Software Development 101 was too grandiose a level for the project(s) I'm going to start documenting here. This is something which has been turning over slowly in my mind for about 2 years (call it procrastination, I usually do), but a few things have come together recently.

A while ago I decided that the need for schools (by which I mean, any persistent educational structure) to support the broadest possible range of students and devices meant that educational support software should be developed in HTML, CSS and Javascript. That's not rocket science of course, and I'm sure I wasn't alone. I certainly ran across a number of writers interested in the "generality" of that platform, if not specifically for educational purposes, and the whole "Open" ideology leans this way.

The problem at that time for me was that Javascript is a pig of a language for daily mucking around. I really didn't want to learn multiple languages at that time - and still don't WANT to - and I strongly suspect most non-programming professionals don't want to either, and my PRIMARY reason for wanting a programming tool was to support textual research, for personal edification and to some extent for materials design. I couldn't work out how to read/write files from Javascript without getting involved in Node, and Node wasn't/isn't the lightweight multi-platform  tool I was looking for either. I have my own PC, Windows-n at home, a different Windows at work (which is completely UNsupportive of the idea of personal computing), plus I use Android on my phone (and subsequently, tablet) as well as an old Netbook that limps along quite nicely running Linux.

So, to cut a long story short (Ruby - hostile community; Python - hate the syntax; Java - hate the syntax) I settled on Frink. Google it - the guy who writes/maintains it has produced something which suits me idiosyncratically & perfectly. Sort of.

Pretty much the first thing I did with it was write an app to support teaching pronunciation in accordance with the methodology my school uses. It was, thanks to Frink, extremely easy to knock together something perfectly functional and perfectly usable in a very reasonable amount of time. Plus, it was a project which taught me the language, and got me interested in programming again. Not that it made me a confident programmer, because I know my weaknesses, but it made me a confident-enough programmer.

The project also taught me more about software distribution & maintenance in an educational context. Firstly, students had to install Frink first - I couldn't produce native apps - and that was problematic. It's not the instant gratification that people are looking for. Secondly, text-to-speech is a can of worms as well, and every student environment (say, 3 flavours of Android * 20+ language origins, for Android alone) needed support to produce English-sounding models (don't try and get a French phone to speak English!). Again, no instant gratification. Thirdly, the pronunciation teachers weren't that interested; certainly not enough to support the student configuration process, and perhaps as a result of that complexity, not sufficiently motivated to work on an iterative development of the tool itself. Finally, the institution we all work for wasn't prepared to provide any support at all - and that goes right down to server-backed cloud-accessible storage. Nor were management prepared to invest in the project.

No matter; I learned a lot (and I have a nice alpha-level pronunciation architecture, if anyone's interested, along with a working demo *grins*). I understand institutional thinking; it is what it is. I spent a year or so using Frink to do some research. A somewhat surprising spin off of all that research was a renewed interest in Scheme & Prolog. I'll tell that story elsewhere. I can't see the use of that yet, but I like to prepare for future serendipity.


Sunday, February 23, 2014

Street Garden

Here is the result of my recent community activism. If the picture of the mayor and me turns up.... I'll probably burn it!