Due to the unexpected size of the workshop, this had to be a dual-track affair, with talks allocated just 4 (!) minutes apiece. The rest of the time was allocated to discussion.
Discussions
In honesty, I wasn't an active participant so much as a dazed onlooker in the discussions; as they got more heated and lively I was struggling to keep up with what the hell was going on (probably unaided by a late Wednesday night and a rushed hotel check-out that morning). I still don't really know what happened in Sessions 1 and 3, maybe the coffee was drugged.
Session 2, New Features for Blocks Environments was particularly interesting to me, though, with the group discussion highlighting what new features could be incorporated.
- Community-based feedback was one such feature - how best to utilise growing online communities of users in block programming languages? Mentor/peer feedback and code/block sharing both arose, features I was originally considering from a meta-design POV.
- Good programming habits and how to foster them was also a key discussion topic. Given that the orientation of this year's conference was towards education, promoting good programming practice in block language users was an inevitable debate.
- The organisation and refactoring of code came up for discussion, too. A ubiquitous feature in textual IDEs, how can we support this in block-based languages?
Disillusionment
My own (silent) contribution to all this was reflecting upon the importance of good coding practice outside of education. Domain professionals (research scientists, businessman and the like) just want to get the job done, whether their solution is carefully planned and iteratively developed, or clumsily hacked together, surely has no bearing on the end result? I was starting to feel a bit left out, to be honest.
Debugging
A final discussion, and one that resonated more clearly with me, is the support for end-user debugging. I feel that coding with bad practice is like paying for a new BMW in 20p coins; it's ugly, inefficient, but it gets the job done.
Coding without testing is like paying for a new BMW that might turn out to be a Smart car, or a unicycle, or a goldfish. You don't buy before you try.
This is a horrible analogy but it's 1.15am and I'm not about to waste time making better ones. You can get by without refactoring or planned development, but no one gets their program right first time, least of all end-users!
Lyn addressed this in his keynote, suggesting that blocks languages are ideal for expressing dynamic semantics, that is, showing how a program is executing. In this section of his talk, he put forward the following research question:
What to do in cases (robotics, mobile apps) in which the program is running on a device other than the computer in which it’s been written?
A-HA! Now it's getting more relevant!
What to do in cases (robotics, mobile apps) in which the program is running on a device other than the computer in which it’s been written?
A-HA! Now it's getting more relevant!
Direction
This is a problem I'd really like to explore in my application. End-users can build these applications that might sample people under differing times and contexts, but how can they test and debug them? One way could be to run a pilot study, but this could be costly and time-consuming.
What if there was a testing and debugging tool built into Jeeves that let users rapidly try out their applications? What form would this take? I was inspired in this session by the presentation of PencilCode, a tool to help students debug their block-based programs that utilised a slider to step through the events in the program, displaying variable values and control flow as the user moves to different points.
One major difference for my case is that ESM applications don't 'flow' in the same way; rather, their execution is based on event-trigger-action sequences, executed sporadically based on the user's context. It's a niche problem, but it's my niche now, and I'm looking forward to seeing how it develops!
What if there was a testing and debugging tool built into Jeeves that let users rapidly try out their applications? What form would this take? I was inspired in this session by the presentation of PencilCode, a tool to help students debug their block-based programs that utilised a slider to step through the events in the program, displaying variable values and control flow as the user moves to different points.
One major difference for my case is that ESM applications don't 'flow' in the same way; rather, their execution is based on event-trigger-action sequences, executed sporadically based on the user's context. It's a niche problem, but it's my niche now, and I'm looking forward to seeing how it develops!
No comments:
Post a Comment