What do you think about AI supporting a text-based programming language (e.g. Python) in addition to code blocks?

389 views
Skip to first unread message

eap...@gmail.com

unread,
Feb 17, 2014, 6:37:39 PM2/17/14
to mitappinv...@googlegroups.com
Hi,

I recently used AI1 to teach a basic game-building programming class to middle schoolers. I'm excited for AI2 (from what little I've seen, it's so much better!), and I think that code blocks represent a wonderful way to teach programming (especially when each child has access to a computer). I really like the AI platform and plan to continue using it to teach beginning programming.

The problem I've had with code blocks is that, even though they're intuitive, I've found them difficult to use in a classroom setting. Here are some of the difficulties I've run in to:
0) In my classroom, some students don't have a computer, and I can't count on them having one at home. So I lack a simple way of engaging all my students simultaneously with code-blocks. This means in-class and out-of-class exercises are harder, and evening having a discussion seems to require presenting the code blocks on my computer or having already created a tutorial with screenshots. I've thought about using paper cutouts for in-class exercises, but there are difficulties with this (cutouts require time to create, and cutouts don't auto-expand).
1) Though the thinking skills from AI carry on after the course, all the external educational resources I'm comfortable recommending use a text-based programming language (often Python). Using the text-based programming language from the beginning would ease this transition. My course is too short to divide it into separate "code blocks" and "text-based programming language" sections.
2) If each student / group is creating a unique project, I can't easily add library code to all the projects once they've started working on them (I have to recreate it for each project). The XML format I've seen in the block ZIP files seems like it might help address this.
3) The GUI exposes many named items (e.g. parameter names for "private" methods to abstractions I'd like the students to use) that must be scrolled through to find the right pieces. Even if I adopt some convention (e.g. prefix all private methods/parameters with "zzz_" in order to move them to the bottom of the alphabetized list), I find that I have to provide significant guidance for the students to discover the "real" code blocks.

Since I don't know AI2 well, some of those issues, particularly #2 and #3, might now be solved.

So I'm interested in a text-based programming language frontend to AI. I think the right thing for me to do is to send you a pull request (unless you're already planning this feature :) ), and I wanted to see if you had any strong feelings about it up front. I think Python is the right language for the task, given that it seems to match closely with the AI control blocks, it's used in many external educational resources, and its syntax is, I think, light-weight enough. I'm also partial to using Scheme in an attempt to minimize the pain of learning syntax, but I think Python is a more natural fit.

Any thoughts?

-Ethan

fturbak

unread,
Feb 18, 2014, 6:06:35 PM2/18/14
to mitappinv...@googlegroups.com, eap...@gmail.com, Karishma Chadha
Hi, Ethan --

Wellesley senior Karishma Chadha is currently working with me on a text-based language that's isomorphic to AI2, along with mechanisms to convert from text to blocks and back again. The isomorphism is important: converting blocks to text and back again yields the original blocks; and converting text to blocks and back again yields the original text. 

Our current language, name TAIL (for Textual App Inventor Language), is intended to "look like" the blocks in textual syntax. So you can represent the blocks

in TAIL as 

(when Button1.Click do:
   [if {{Label1.Text} = {10}} 
    then: [set Label1.Text to: {0}]
    else: [set Label1.Text to: {{1} + {Label1.Text}}]])

(where indentation and multiple lines are allowed but irrelevant). Every expression (block with a plug) is delimited by braces, every statement is delimited by brackets, and top-level constructs (like event handlers, global variable declarations, and procedure declarations) are delimited by parens. 

Existing languages like Python don't satisfy the isomorphism goal. The semantics of Python just doesn't match up with the semantics of App Inventor. For example, Python functions return values via a return statement, but App Inventor currently does not have any construct to immediately exit from a procedure. And Python's limited form of local variable scoping isn't expressive enough to match what AI2 can do. 

We have experimented with a Python-like syntax we call Venthon, but we're first going to finish with TAIL before doing more work on Venthon.  But Venthon most definitely *not* Python, just TAIL dressed up in a Pythonesque syntax. We also have plans for a Venti language that's a Java/C/JavaScripty-like syntax for AI2. 

Note that the goal of having a textual representation for App Inventor is different from the goal of providing a transition to a "real" textual language. We are working on the first goal, not the second. 

Other blocks language designers have different philosophies on this. Neil Fraser, the creator of Blockly, considers it to be a graphical syntax that can be translated into languages like JavaScript and Python -- see https://blockly-demo.appspot.com/static/apps/code/index.html?lang=en. However, the translation is one-directional. You can go from Blockly to JavaScript or Python, but not back again. So this satisfies the second goal, but not the first. 

For what it's worth: 
  • Your #2: In TAIL, you can easily add any library code you want. It's also easy to share and reuse any blocks code by converting it to text and then back to blocks later. 
  • Your #3: AI2 has a much more sensible approach to variables/parameters than AI1, including support for local variables and allowing the same name to be used in different contexts. So AI2 eliminates the name pollution that plagues AI1. 
- lyn -

codexplorer

unread,
Aug 8, 2014, 12:01:48 PM8/8/14
to mitappinv...@googlegroups.com
@Lyn: I found the thesis of your student online (http://cs.wellesley.edu/~tinkerblocks/chadha-thesis.pdf). Does this mean your development of TAIL is complete? It sounds that we are quite a few who could immediately take advantage of it as is...
Thanks!

fturbak

unread,
Aug 8, 2014, 1:00:56 PM8/8/14
to mitappinv...@googlegroups.com, Karishma Chadha
TAIL as it currently stands is incomplete, but Karishma and I are actively working to complete it, with the goal of integrating it into the released App Inventor system.  However, this is likely to take several months.

Along the way, we will be posting test versions of App Inventor with the TAIL extension. Please post here if you would like to be one of the testers of this extension. 

It's great to know that folks are interested in this!  

- lyn -

Gareth Haylings

unread,
Aug 8, 2014, 3:47:41 PM8/8/14
to mitappinv...@googlegroups.com, kch...@wellesley.edu
Hi Lyn

This sounds great I would love to help test it.

codexplorer

unread,
Aug 8, 2014, 4:15:42 PM8/8/14
to mitappinv...@googlegroups.com, kch...@wellesley.edu
Please sign me up. I'd be happy to help.

Peter Mathijssen

unread,
Aug 9, 2014, 8:06:37 AM8/9/14
to mitappinv...@googlegroups.com, eap...@gmail.com, kch...@wellesley.edu
Hi, i would also like to test the TAILS plugin.

Miguel Murillo

unread,
Aug 27, 2014, 2:25:17 PM8/27/14
to mitappinv...@googlegroups.com
Yes, please... I'd like also test TAILS...

Regards
Reply all
Reply to author
Forward
0 new messages