mickclns at mac.com
Fri Aug 14 21:49:42 EDT 2015
Thanks for replying, Bill,
I expect there are more than a few caveats to consider.
As I implied, in the Moore method an average of maybe 1% of class time is spent by the professor speaking, 0% in lecture mode. I think it would be more in a programming class, but still not enough to nod one out. I very strongly acknowledge different learning styles — I am a full-time math tutor (and have been trained as an LD (which now stands for learning differences) tutor) and I see learning styles very detailed / close up. It is partly for the differences that I suggested tiny projects — I think an approach using tiny increments would tend to smooth out some of those differences due to learning style. Perhaps the teacher could also set up projects oriented towards different styles (the teacher, remember, has almost no lecture-type preparation time and would have more than the usual amount of time for designing the look and feel of many tiny projects and this feeds right into your idea of a variety of teaching methods for Livecode.
Thanks for your suggestions.
Bill Prothero wrote:
> This is a great way to learn programming, but there are a few caveats that might be considered.
> As I learned to program, i could never get thru more than one lecture (pascal). Ungodly boring! I needed a project and the docs. However, other folks may have different learning styles. Some may be very persistent, working until they get a solution. Others may need more motivation or self confidence to get to a solution. Some learn well from documents. Others may be more visual learners and need to be shown.
> Livecode seems to lend itself very well for a variety of learning styles, so perhaps a variety of teaching methods should be incorporated into a single course.
> William Prothero
>> On Aug 13, 2015, at 1:38 AM, Mick Collins <mickclns at mac.com> wrote:
>> 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.
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> Subject: Digest Footer
> use-livecode mailing list
> use-livecode at lists.runrev.com
> End of use-livecode Digest, Vol 143, Issue 26
More information about the Use-livecode