Describing LiveCode

Mick Collins mickclns at
Thu Aug 13 10:38:28 CEST 2015

Just my 2 cents worth:

When I was studying math as an undergraduate and as a graduate student, many of the classes were taught by the (R. L.) Moore Method. In this method the professor gives axioms, definitions and just the statements of the theorems. The students have to prove the theorems themselves. The class time is nearly all spent with students presenting their proofs (lower (higher) ability students present the more easy (difficult) theorems, sometimes more than one proof presented so students see them from different angles). The students get a very deep understanding of the ideas involved because they’ve had to look at them from a lot of different angles and see what will work. It can be easily seen who is working at it and who not (thus providing some kind of evidence for a grade, although in our classes, very few slacked off AT ALL).

My suggestion is a variation on this method for “teaching" Livecode. Students would be assigned several tiny projects at a time with maybe one or two new mini-concepts per project, having been given what the GUI for the project looks/operates like and a few words to look up in the dictionary and other places. In the Moore method, there are no textbooks nor outward-directed research of any kind — that, of course, wouldn’t work here because of the difference between computers and mathematics, but limits can be set so that they are largely doing it on their own. There are many variations that could add to the utility, for instance working in pairs, where one works on researching the new ideas, the other constructing the GUI and scripting, alternating from project to project.

More information about the use-livecode mailing list