Page 1
A VISUAL INTERACTIVE PROGRAMMING ENVIRONMENT
ht tp : / / s i t e s .goog le . com/s i t e / l a r chenv
G. FRENCHJ. R . KENNAWAY
A. M. DAY
EUROPYTHON 2011
The Larch Environment
Image by alcomm, flickr.com
Page 3
We look at three problems
Page 4
Textual output in a Python console can be difficult to understand
(DEMO)
Page 5
Source code in a text editor is not interactive enough
Consoles are only good for a few lines at a time
Page 6
Textual source code can be difficult to understand and comprehend
(think the vertices of a polygon in code form)
Page 7
What is‘The Larch Environment’?
Page 8
A visual interactive programming environment
Page 9
The goal is:To make programming more visual
Page 10
How do we do that?
• Visual object presentation• Programming environment– Visual console–Worksheets
• Visual programming via embedded objects
Page 11
Visual object presentation
Page 12
“Pictures are pretty”
DEMOVisual console
Page 13
What design pattern do we commonly use for developing GUI
apps?
Page 14
Model
View Controller
MVC Architecture
Page 15
MVC requires:Model class, View class, Controller
class
Page 16
Our approach:Type coercion
Type coercion: coerce an object to another type.
Page 17
Type coercion used throughout Python
Page 18
Examples:
repr(), str()
__index__()
etc
Page 20
The Larch Environment:Use type coercion for visual
presentation
Page 21
Coerce objects to something visual(a Pres)
Page 22
HOWTO:The simplified version
Page 23
Define the following method:def __present__(self, fragment,
inherited_state)
Page 24
For Java objects:Implement Presentable interface
Page 25
Presentations constructed using a combinatorial API
Page 26
Label( ‘Hello’ ) Hello
Button.buttonWithLabel( ‘Button’ )
Button
a = Label( ‘A’ )b = Label( ‘B’ )c = Label( ‘C’ )d = Label( ‘D’ )
Row( [ a, b, c, d ] ) ABCD
Column( [ a, b, c, d ] ) ABCD
Page 27
Presentation combinators:Many more
Flow layouts, mathematical fractions, superscript
Rich text, other utilitiesWrite your own by combining existing ones!
P.S. Appearance controlled with style sheets
Page 28
“Type coercion is easy”
DEMO:__present__()
Page 29
Can also handle objects in the Java or Python standard libraries
Page 30
Create an ‘object presenter’.Register it for the relevant class.
When asked to present an instance of the class, Larch finds the
appropriate presenter and uses it.(no monkeypatching required)
Page 31
Thats how the images were shown;they are java.awt.BufferedImage
objects
Page 33
Different perspectives present an object in different ways
Page 34
Like different views in MVC
Page 35
The one I have talked about (__present__, Presentable, etc) is the
‘Default perspective’
Page 36
There are other perspectives
Page 37
E.g. The inspector perspectives
Page 38
“Visual Introspection”
DEMO: INSPECTOR PERSPECTIVE
Page 39
Programming Environment-
Visual console
Page 40
You’ve seen most of it
Page 41
So lets look at some of the more ‘esoteric’ features
Page 43
Everything in Larch is an object being presented (via type coercion)
Page 44
The home page
Projects
The console itself!
Page 45
What if we want to manipulate an object that we can see?
Page 46
CTRL+ALT +drag it!
Page 47
“I see something: how does it work?”
DEMO: inspect a project
Page 48
An interesting side fact!
Page 49
Our source code editor does not edit text
Page 50
Its a structured editor
Code is represented as an abstract syntax tree (AST)
Page 51
A perspective is used to present is as something that looks and behaves (mostly) like text
Page 52
It means our code is in tree form
Page 53
We can write our own refactorings!
Page 54
“Change your code fast!”
DEMO:Refactoring
Page 55
Programming Environment-
Worksheets
Page 56
Interactive consoles are great.
Caveat: gets difficult when working with more than a few lines of code at a time
E.g. Whole modules
Page 57
For complete programs we turn to a text editor
We lose the interactivity
Page 58
What if we could blend the two?
Page 59
“Python modules. With pictures.”
DEMO: WORKSHEET(with cellular automata)
Page 60
Act as modulesCan import code from other
worksheets within the project
Page 61
You can divide your module code into a number of blocks
Page 62
Each block can show a result – a step along the path of a
computation
Page 63
To refresh results: hit F5
Page 64
Rapid Edit-Run-Debug cycle:
Alter codeF5
Repeat
Page 65
“Code faster!”
DEMO: Edit-Run-Debug cycle(cellular automata)
Page 66
Visual Programming
Page 67
Quite a rich history in the research community
Page 68
Circuit diagrams, data-flow diagrams, etc
Page 69
Nice for small simple programs
Page 70
Large programs look like rat’s nests
Not practical
Page 71
Text remains the dominant medium for source code
Page 72
Diagrams are still appropriate in certain circumstances
Page 73
Lets use diagrams (or visual layout) where we need them!
Page 74
“Play God.”
DEMO: OrrerySub-demos:
Table editorsEmbedded table
Page 75
“Drawings. Inside code.”
DEMO: Polygon
Page 76
Embedded objects can use a protocol to customise their
behaviour
Page 77
__py_eval__ Act like an expression - return the result of evaluating
__py_evalmodel__ Act like an expression - return an AST
__py_exec__ Act like a statement – called at runtime
__py_execmodel__ Act like a statement – return an AST
Page 78
AST Generation
What does this sound like?
Page 79
AST Generation
~=
Visual LISP macros
Page 80
Crosses compile-time / run-time barrier
Page 81
Compile-time (edit-time) objects available at run time
Page 82
Run-time objects / values can modify or be modified by compile-
time objects
Page 83
“LISPy Smalltalky goodness”
DEMO: LZW compressor
Page 85
Visual object presentation by type-coercion
Page 86
Encourages a functional approach to UI composition
Page 87
State changes:Just throw UI elements away
andre-create.
DON’T MUTATE
Page 88
Visual representation of values is a BIG EPIC WIN
Page 89
Even if you use only visual cues (e.g. borders around text)
Page 90
Visual console and worksheets
Page 91
Worksheets expand on the rapid edit-run cycle of the console
Page 92
Allow for rapid development of visual interactive applications
Page 93
Visual programming by embedded objects
Page 94
Visual programming
where you need it
Page 95
Allows you to visually extend the syntax of the language
Page 96
No need to alter the compiler – its just embedded object references
Page 97
References to objects you implement
yourself
Page 98
Embedded object referencesCan cross compile-time / run-time
barrier
Page 99
LISPy / Smalltalky stuff
IN PYTHON
Page 101
Research Prototype
(not ready for real use )
Page 102
TODOs:
DocumentationBug fixes
Too much more........
Page 103
Acknowledgements
Page 104
Academic supervisory team
Dr. Richard KennawayProf. Andy Day
University of East Anglia, Norwich, UK
Page 105
The Jython team
Developing The Larch would have been very difficult
without Jython
Page 106
IF TIME ALLOWS:DEMO: KD-Tree
Page 107
IF TIME ALLOWS:DEMO: SIMPLE COMPILER
Page 108
G. FRENCHJ. R . KENNAWAY
A. M. DAY
ht tp : / / s i t e s .goog le . com/s i t e / l a r chenv
THANK YOU!
Image by alcomm, flickr.com