[Idle-dev] some interesting ideas from 'DrRacket' programming environment

[Terry Jan Reedy]

On 5/31/2013 1:14 PM, Tom M wrote:

> there are some useful ideas that might be worth adopting from an IDE
> for Scheme - 'DrRacket', which is used to teach programming design.
>
> https://class.coursera.org/programdesign-001/class

My daughter took such a class as her first university CS class, but 
having learned Python first, from me, did not especially like it. 
However, I thought then it might be a source of ideas in spite of some 
problems.

Keep in mind that
a) Idle is intended to be less 'ambitious' than other IDEs, include some 
other Python IDEs like IPython (and Sage?).
b) We are currently focused on fixing bugs, making small enhancements, 
and adding tests to find more bugs and prevent regressions. Tests are 
necessary for any big changes that could break behavior. I expect much 
of this will be done in a year.

> The most interesting idea is that it highlights any code that wasn't
> executed during a unit/doctest.
> So a developer/student can easily spot deadcode or code that needs to
> have test cases created.

This should be an extension (assuming that there is not one already) 
that adds a 'run test with trace and visual coverage feedback' menu 
item. Perhaps the extension could look at the bottom of the file for a 
doctest or unittest call, parse it, run the test with tracing turned on, 
get the trace report, and mark lines not in the report with red.

> An idea that seeing this feature inspired (due to at first mistaking
> the purpose of the feature) was to add the arrows showing program flow
> as used in LLVM with Clang static debugging.  So the user can trace
> through visually how the program is executing.

I never saw this. The Idle debugger will let one follow program 
execution. It was recently fixed to work right on Windows. I found the 
equivalent Racket debugger to be harder to follow.

> Other useful features of the language/IDE for teaching purposes were
> having the file editor and evaluation window in single frame.  This is
> easier for many individuals than moving the file editor window
> to the foreground, then the evaluation window to the foreground and
> likely reduces 'context switching' mental overhead.

I already have the vision of Idle running in one OS window with 
side-by-side tabbed frames so one could look at two code files or code 
and shell simultaneously, side-by-side.

> Also something fairly unique, but quite interesting for simplifying
> teaching tasks, is the abilty to paste images into a variable
> definition, and able to output images to the evaluation window. i
> thought this was rather clever, pasting an actual image inline into
> your program file rather than path manipulation is likely drastically
> easier for new users, and visual results are both more interesting and
> often easier to understand.

I liked this feature. There are two issues: creating image objects by 
pasting; and displaying an image object as an graphics image instead of 
something semi-useless like the text string <class Image(xljdj) instance 
at 0X23a53de>. Unfortunately, Python is text, not image oriented. The 
stdlib does not have an image library and tk does not handle modern 
image formats. I do have the impression that tk text widgets can contain 
images.

Anything like this would take the Idle shell well beyond imitating the 
official console text shell. There might be issues with that.

> Along with the image pasting into variable definitons was the
> inclusion of a simple image manipulation library that allowed simple
> operations - enough to create toy games, and animations.  To me this
> is more kid friendly and appealing than turtle.

I agree. The big project of my daughter's class, after the classical 
algorithm exercises, was a simple game.

> Perhaps turtle could
> be extended to include the functions provided or a seperate module.

I think what is needed is a new tkinter subpackage for animated canvas 
sprites, with animation driven by the tkinter event loop. (Perhaps this 
exists somewhere already.)

The current turtle is actually turtle2 and has unsolved bugs. It was 
written (and not too well in my reading) to potentially run in any 
graphics framework. So turtles are isolated from a tkinter canvas by 
multiple layers that slow performance. Turtle is also single-sprite 
(turtle) oriented, while most games need multiple sprites (at least a 
ball and paddle or monkey and punching glove ;-).

> It allows for simple examples that are likely more readily graspable
> for beginners.  Ie one of the early examples in the course is a
> stoplight and turning the 3 colors off and on.

Animated graphics are also useful for showing algorithms in actions. I 
have seen some on Youtube for sorting algorithms.

> Have a look at these videos for the course
>
> 8 minutes onward in 01d
> 3:50 onward in 01e
> https://class.coursera.org/programdesign-001/wiki/view?page=AllLectures
>
> (might require free registration to view the videos)
>
> Thanks for your great work, hope you find these suggestions of interest.

Are there any ideas you are willing to work further on?

Terry