Looking Glass
| Краткое описание языка | |
|---|---|
| Компетенции в каких сферах формирует | Empowered Learner, Knowledge Constructor, Innovative Designer, Computational Thinker, Creative Communicator, Global Collaborator |
| Парадигмы программирования | |
| Возрастная категория | |
| Назначение языка (Общее / Учебное) | Мини-язык для обучения |
| Visual_Text_Blocks | Блоки-Иконки |
| Измерение (2D/3D/Tangible) | 3D |
| Область знаний | |
| Открытость продукта | Открытый |
| Address | https://lookingglass.wustl.edu/ |
| Предки (Ancestors) | Alice |
| Потомки (Descendants) | |
| Активность в данный момент | Project is active |
| Доступны ремиксы? | |
| Год создания | |
| Создатели | |
| Поясняющее видео | |
| Используется для создания мобильных приложений? |
- Looking Glass упоминается в свойствах следующих страниц
Looking Glass is a programming environment for ages 10 and up. With Looking Glass, you can create and share animated stories, simple games, and even virtual pets.
Alice with special feature for remix
Reuse & Remix
Gross, P.A. et al.: A Code Reuse Interface for Non-programmer Middle School Students
- In: Proceedings of the 15th International Conference on Intelligent User Interfaces. pp. 219–228 ACM, New York, NY, USA (2010).
Users (1) record a feature to reuse, (2) find code responsible for the feature, (3) abstract the code into a reusable Actionscript by describing object “roles,” and (4) integrate the Actionscript into another program. An exploratory study with middle school students indicates they can successfully reuse code.
Prior research on programming environments demonstrated that storytelling can provide a compelling context to learn computer programming, particularly for middle school girls. A formal study of girls’ programming behavior found that users of Storytelling Alice were more than three times as likely to sneak extra time to program than users of a nonstory based version of the same environment. While encouraging, this study focused solely on users’ first two to three hours of programming.
To enable this, our code reuse tool guides users through the processes of selecting and integrating code. Specifically users:
- Record the execution of the program containing the functionality of interest.
- Identify the beginning and ending of the functionality of interest.
- Abstract the code responsible for the functionality by describing the roles that each character in the functionality plays. We save the abstracted version of the code as an intermediate code representation called an Actionscript. To use the Actionscript, the user selects characters from a new program to act out the roles in the Actionscript
Enabling users to reuse functionality from programs created by others requires supporting them in three basic activities: 1. Finding the code responsible for the target functionality. 2. Extracting the responsible code from its original program. 3. Integrating the responsible code into a new context.
For experienced programmers, an intelligent copy and paste system might be sufficient to enable code reuse. However, our goal is to enable new programmers to reuse code without requiring that they understand how that code works. In an educational system, this may seem strange. Our eventual goal is to have users select functionality they want to reuse and then complete a tutorial guiding them through building that functionality in their own program.
Allowing any object to fill any Actionscript’s role can violate type safety during integration and cause run-time errors later. For instance, assume a user creates the role ‘walker’ from a person, like the agent, and the role invokes the walk method on the object filling the role. Then a user can only safely fill the ‘walker’ role with objects inheriting from the class implementing the walk method (i.e., the Person class). For example, an object like a table cannot fill the ‘walker’ role because a table does not extend the Person class. If we assigned table to the ‘walker’ role, this would violate type safety and cause a run-time error.
Differences in the body structure of different graphical objects create another potential source of integration problems. Because 3D objects can have different subparts, type safety does not prevent all possible errors. Suppose a user creates a role from a Samurai which turns the Samurai’s helmet subpart. The user may later assign a Coach to safely fill this role, but the Coach does not have a helmet subpart to turn.
