Date: Wed, 3 Jun 2015 11:48:13 +0300 From: Andrés Moreno To: Meurig Beynon Cc: Carolina Islas Sedano , Carolina Islas Sedano , sutinen@cs.uef.fi, ilkka.jormanainen@cs.uef.fi, alimisis@otenet.gr, Emmanouil , Rene Alimisi , Piet Kommers , H.A.Macleod@ed.ac.uk, jen.ross@ed.ac.uk, tomcsanyi@slovanet.sk, winczer@fmph.uniba.sk, Steve Russ Subject: Re: ITAG paper for June 15th Parts/Attachments: 1.1 OK ~52 lines Text 1.2 Shown ~43 lines Text 2 OK 730 KB Application 3 OK 501 KB Application ---------------------------------------- Hi Meurig, Elizabeth and Johny, I'd like to suggest as further reading my paper on Roles of Visualization Tools in Learning.  It can be used as mirror to the roles of the users, and it also highlights the role of confusion as path to learning. My paper on Conflictive Animations also has some background section for the error/mistake correction role on education. If the paper takes a around those topics, and if needed, I can contribute with some writing too. Cheers, Andrés Date: Wed, 8 Jul 2015 11:17:40 +0300 From: Andrés Moreno To: Meurig Beynon Cc: Meurig Beynon , MACLEOD Hamish , Elizabeth Hudnott , "carolina.islas@ubium.net" , "carolina.islas@uef.fi" , "sutinen@cs.uef.fi" , "ilkka.jormanainen@cs.uef.fi" , Dr Alimisis Dimitris , "ezoulias@teemail.gr" , "ralimisi@gmail.com" , ROSS Jen , "tomcsanyi@slovanet.sk" , "winczer@fmph.uniba.sk" , "sbr@dcs.warwick.ac.uk" , "pkommers@gmail.com" , Dr Piet Kommers , "Boyatt, Russell" , Jonathan Gregory Kenneth Foss , Emma King , Chris Hall Subject: Re: ITAG paper for July 6th (yes really!) Parts/Attachments: 1 OK ~450 lines Text 2 Shown ~498 lines Text ---------------------------------------- Thanks for your reply Meurig, What follows is just discussion for a future paper, don't take them as inputs for the current one!! Program visualization indeed fails to make the link with reality, as clear as construals. In that sense, construals are better suited for computational thinking teaching, as it applies certain computational principles to model reality. We could discuss the merits of algorithm visualization, where more concrete metaphors are used (though they are also called abstract data types). Queues, stacks, sorting, etc have some basis on reality, and help thinking in computational terms. The relationship I see among programming, program animation, and construals is where the "perfect" program is the reality we want to model. Student approximations (their own code) and the automatic visualizations are the observables. Dependencies are invariable, and defined by the programming language and machine that executes the program. How the program works could be represented as a construal, which is useful if you are learning programming (and not useful if you want to model your shopping experience as a program). Another point to make is the levels of student engagement for algorithm/program visualization conceptualized by Naps et al [1] and extended by Niko Myller [2]. Their making a visualization level is very close to construal making.  And finally, the observing nature of a program visualization was somehow hinted by Kumar et al[2] in their implementation of problets, where they used a "observer architecture". [1]http://dl.acm.org/citation.cfm?id=782998 [dl.acm.org]  [2]http://www.cs.joensuu.fi/pages/int/pub/myller09.pdf [www.cs.joensuu.fi] [3] http://www.sciencedirect.com/science/article/pii/S1571066107002885 [www.sciencedirect.com] Cheers, Andrés Date: Wed, 8 Jul 2015 08:04:01 +0100 (BST) From: Meurig Beynon To: Andrés Moreno Cc: Meurig Beynon , MACLEOD Hamish , Elizabeth Hudnott , "carolina.islas@ubium.net" , "carolina.islas@uef.fi" , "sutinen@cs.uef.fi" , "ilkka.jormanainen@cs.uef.fi" , Dr Alimisis Dimitris , "ezoulias@teemail.gr" , "ralimisi@gmail.com" , ROSS Jen , "tomcsanyi@slovanet.sk" , "winczer@fmph.uniba.sk" , "sbr@dcs.warwick.ac.uk" , "pkommers@gmail.com" , Dr Piet Kommers , "Boyatt, Russell" , Jonathan Gregory Kenneth Foss , Emma King , Chris Hall Subject: Re: ITAG paper for July 6th (yes really!) Dear Andres I don't know what is a good criterion for authorship here! - I had earlier tried to identify the specific team of people who had had input to / worked with the shopping construal / contributed ideas by email etc but felt that this didn't reflect the cloud of incidental input from across the project team. As far as your input is concerned, I think it has been really helpful in advancing my understanding of what's going on where the relationship between general procedural programming and making construals is concerned. To elaborate on the two concluding paragraphs in subsection IV.C would be a paper in itself I think when you consider that: - Peter rightly questions whether it makes sense to claim that you can teach making construals before you teach basic procedural programming - I don't know how to construe your work on animation of abstract procedural programs in terms of making construals, though I was surprised at this [I thought along the lines - let's focus on the states of the program execution and the animation, let's probe that state - as you might a construal by defining something (sounds promising, as this has the flavour of conflictive animation ...) - but hang on, where are the observables? - and, more to the point, the dependencies?] - surely there has to be *some way* of construing abstract procedural programs in ODA terms: what could it possibly mean that you *cannot* do this? but if I could, would I want to? [I don't want to construe / need to know how my spreadsheet does its updating for instance] - it's obviously conceptually difficult to explain what it would mean to allow the maker of a construal to put arbitrary procedural code into JS-EDEN [to be more direct, it would surely be absurd!] - the aspiration in making construals in JS-EDEN is to ensure that all procedural code in functions and actions is derived from making the construal (i.e. it must take the form of animation of an activity that can be carried out manually) ... ... and curiously, considering how head bending construal of abstract procedural programs seems to be ... - you can derive simple procedural code for functions and actions in this way, as has been illustrated over and over again in making construals. The key point here may be that the construal of procedural code sketched in the last paragraph of IV.C has quite as much to do with shopping as it does with writing a while loop. Your animation exercises, in contrast, have nothing to do with shopping - or anything else for that matter. So the construals of procedural programs that are of interest in CONSTRUIT! are ones that exploit the real meaning ("What the program is about"). This could also be linked to Granger's concern (in the blogpost 'coding is not the new literacy' you drew to my attention) about the 'irrelevance' at some level of pure coding skill ... and also why I think Ford's 'what is code?' is revealing. Sorry I didn't manage to do justice to this in the two paragraphs - I hope it doesn't sound as if I'm dismissing your invaluable input there! We can edit further if you prefer. Best wishes Meurig Date: Wed, 8 Jul 2015 09:07:36 +0100 (BST) From: Meurig Beynon To: Meurig Beynon Cc: Andrés Moreno , MACLEOD Hamish , Elizabeth Hudnott , "carolina.islas@ubium.net" , "carolina.islas@uef.fi" , "sutinen@cs.uef.fi" , "ilkka.jormanainen@cs.uef.fi" , Dr Alimisis Dimitris , "ezoulias@teemail.gr" , "ralimisi@gmail.com" , ROSS Jen , "tomcsanyi@slovanet.sk" , "winczer@fmph.uniba.sk" , "sbr@dcs.warwick.ac.uk" , "pkommers@gmail.com" , Dr Piet Kommers , "Boyatt, Russell" , Jonathan Gregory Kenneth Foss , Emma King , Chris Hall Subject: Re: ITAG paper for July 6th (yes really!) Dear Andres [Apologies if this seems to be a spamming exercise, but I think that the issues here are v relevant to the CONSTRUIT! project and of general interest when we're considering the significance of making construals] And there's more to be said ... - what changes of state actually occur in the execution of an abstract procedural program are not of course in general 'meaningful' (hence invariants to monitor relationships between variables at sensible points when the program state means something) ... ... but if you're making a construal of an abstract procedural program, you don't know this: maybe I explicitly want to draw attention to all the changes of state that occur to explain just how meaningless procedural programs can be ... - if you must construe procedural programs in this most general way without regard to 'meaningfulness of state', it's unclear whether there is a role for dependency. [Certainly dependencies are very much connected with maintaining invariants - instead of saying 'a is b+c', I've updated b, so now I must update a, as in {a is b+c} b := 3 ## a 'meaningless' state a := b+c {a is b+c} you say a is b+c; ## note the giveaway semi-colon :) here b = 3; and there isn't a 'meaningless' state in which a isn't b+c.] What can we conclude from this? Is it that no-one should be trying to interpret abstract procedural programs - least of all novice programmers - it's a task for computers? Or - even more daring - that we shouldn't be writing abstract procedural programs (cf. 'learning to code'!)? And does this have some bearing on the pedagogical problem that motivates your animation papers viz. that animation doesn't seem to have proved very helpful in helping students to understand programming constructs? Best wishes Meurig