Cognitive load

jbv jbv at souslelogo.com
Sun Apr 23 11:35:59 EDT 2017


sorry I didn't have the time to go into details in my previous post,
but as for "a well-known fact" I was referring to decades of studies
in psychology and ergonomics.
This approach has nothing to with "reducing the human brain/mind to the
level of a binary computer", but rather with very specific and carefully
designed & reproductible tasks in which the amount of information processed
can be precisely measured.
Of course, individuals differ in their processing capacity, but (from the
top of my head) according to the above mentioned studies, the upper limit
seemed to be 7 bits/sec (again this doesn't mean that human brain = fancy
computer).
I also have several years of experience teaching programing to newbies of
very different ages & backgrounds (starting in 1980/81 with a Logo machine
and a class of kids aged 12/13), and the 3 "steps" I mentioned previously
(perhaps a better word could be used) were constantly present during my
teachings. These are not really successive "steps", as newbies have to
apprehend all of them simultaneously.
Last but not least, the concept of "workload" has been widely studied for
decades in psychology & ergonomics, as well as (long story short) the best
ways to organize & display information so that processing is reduced as
much as possible.
Several studies also showed that newbies tend to memorize algorithms in
a very specific language (the one they used), while experienced coders
tend to memorize algorithms "outside" of any specific language.
That's why a programing language close to the natural language is a huge
improvement, especially for newbies, for whom the necessary "workload" to
apprehend the language (the first "step") is reduced, saving some processing
capacity for the rest of the task.

On Sun, April 23, 2017 4:14 pm, Richmond Mathewson via use-livecode wrote:
> "a well-known fact"
>
>
> Actually this is a fairly subjective finding, and it is not
> a bad idea to work out the difference between a 'fact' (as in "this
> concrete is hard, as you will see if you hit it with your first") and
> widely held beliefs which may later prove to be erroneous.
>
> "Cognitive Load" is a theory, and NOT a collection of facts.
>
>
> https://en.wikipedia.org/wiki/Cognitive_load
>
>
> " Evidence has been found that individuals systematically differ in
> their processing capacity."
>
> So, while one might have a modal workload the categorical boundaries are
> had to define and largely unquantifiable.
>
> Smaller MAY, generally be better, but NOT always; this very much depends
> on the person who is working with something.
>
> There is a tendency to treat the human brain as a super-computer, but
> this is, in all probability, a confusion of kinds which may lead to a
> complete misreading of both how minds work and how computers work.
>
> "7 bits/sec"
>
>
> So, you would reduce the human brain/mind to the level of a binary
> computer: I wonder how those
> "bits" were measured.
>
>
> "so the less cognitive load is needed by step 1 above, the more remains
> available for the other steps..."
>
> Well that rests on an unproven presupposition that the human brain/mid
> works in steps (again because of the odd equation brain= fancy computer);
> while it may not; it may work holistically, assessing a whole situation
> all at once.
>
> I find that teaching children (7-14) LiveCode produces rapid results, as
> does teaching them BBC BASIC (they love my BBC Micro computer). Supposedly
> LiveCode should present less of a cognitive load
> than BASIC: well it would if the two methods of GETTING COMPUTERS TO DO
> SOMETHING allowed one to GET THE COMPUTERS TO DO
> THE SAME THING, but they don't,
> they are two totally different ways of interacting with computers that were
> developed at different historical periods for rather different jobs, so
> comparing them is probably a waste of time.
>
> Oddly enough, children generally find this exercise:
>
>
> Get the computer to produce a table of the first 10 digits, their
> squares and their cubes on-screen.
>
> considerably easier in BBC BASIC than in LiveCode. It generally takes them
> 5 to 10 minutes with BASIC,
> with LiveCode they find that the GUI "gets in the way".
>
> While (not oddly at all) they wouldn't know how to begin (and nor would
> I) how to do this with BASIC:
>
>
> Produce a blue square, 200 x 200 pixels, with a button titled "Press Me"
> in the middle.
>
> Mason, Cooper, et al. attempt 'Assessing Cognitive Load in Mobile App
> Development Environments' which is,
> after all, very much a subset of computer-programming.
>
> They compare 5 programming "environments" (I'm using those quotation
> marks to point out that they are NOT comparing GUI-based IDEs with more
> 'traditional' programming
> methods, such as BASIC) that all, to a lesser or greater extent provide the
> programmer with a toolbox of premade objects, thereby cutting out a very
> large part of any cognitive apprenticeship that has, historically been
> required to attain competence in programming.
>
> I would argue that LiveCode, at least, does require quite a bit of
> cognitive effort, at least at the start, for programmers to understand how
> each of the premade controls/objects functions, and how each of them can be
> addressed to do what the end-user wants them to do. While LiveCode allows
> programmers to bypass a lot of 'stuff' that PASCAL. C++ and so on require
> a programmer to know, it presents them with another lot of 'stuff' which
> they have to know instead. The only thing that may make LiveCode easier to
> acquire some initial level of competence in is that the object-oriented
> visual metaphor adopted by LiveCode is, in some ways, nearer to the real
> world that what other, more traditional programming languages present.
>
> However, you will notice that I "argue", I don't present my subjective
> experience working with school children as 'facts'.
>
>
> Until about 1600 is was a "well-known fact" that the world was flat: but
> I have a funny feeling that it wasn't and
> that the world did not suddenly change shape when people started believing
> it was vaguely spherical. Now that people have gone up into space with
> rockets and taken photos of the earth the argument seems to be over
> whether the world "is" a sphere or an "oblate spheroid", and only nutty
> fruitcakes believe otherwise:
>
> https://www.tfes.org/
>
>
> "So, Listen, I drive from coast to coast, and this shit is flat to me."
> Dr. Shaquille O'Neal.
>
>
> Anyone else wanting a doctorate can mail me $100 to the usual address
> and with a week they will recieve a doctoral diploma lovingly printed out
> from my laser printer :)
>
> Well, I enjoyed myself this weeked; hope you all did :)
>
>
> Richmond.
>
>
> On 4/23/17 3:36 pm, jbv via use-livecode wrote:
>
>> On Sun, April 23, 2017 9:55 am, Richmond Mathewson via use-livecode
>> wrote:
>>
>>> I'm not sure why smaller should necessarily be better.
>>>
>>>
>> It is actually, and the cognitive load approach, especially for
>> programmers newbies, is quite relevant. Newbies have to deal with 2 or 3
>> things simultaneously : 1- the language itself
>> 2- the programming "rules" (variables, loops...)
>> 3- the program itself they're attempting to write.
>>
>>
>> It is a well-known fact that the workload that human minds can
>> process per unit of time is limited (AFAIR 7 bits/sec), so the less
>> cognitive load is needed by step 1 above, the more remains available for
>> the other steps...
>>
>>
>> _______________________________________________
>> use-livecode mailing list use-livecode at lists.runrev.com Please visit this
>> url to subscribe, unsubscribe and manage your subscription preferences:
>>  http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
> _______________________________________________
> use-livecode mailing list use-livecode at lists.runrev.com Please visit this
> url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>






More information about the use-livecode mailing list