A VISUAL INTERACTIVE PROGRAMMING ENVIRONMENT FOR PYTHON http://sites.google.com/site/larchenv G. FRENCH J. R. KENNAWAY A. ...
Motivation
We look at three problems
Textual output in a Python console can be difficult to understand(DEMO)
Source code in a text editor is not interactive enoughConsoles are only good for a few lines at a time
Textual source code can be difficult to understand and comprehend(think the vertices of a polygon in code form)
What is‘The Larch Environment’?
A visual interactive programming environment
The goal is:To make programming more visual
How do we do that? <ul><ul><li>Visual object presentation </li></ul></ul><ul><ul><li>Programming environment </li></ul></u...
Visual object presentation
“ Pictures are pretty”DEMOVisual console
What design pattern do we commonly use for developing GUI apps?
Model View Controller MVC Architecture
MVC requires:Model class, View class, Controller class
Our approach:Type coercionType coercion: coerce an object to another type.
Type coercion used throughout Python
Examples:repr(), str()__index__()etc
Its simple
The Larch Environment:Use type coercion for visual presentation
Coerce objects to something visual(a  Pres )
HOWTO:The simplified version
Define the following method:def __ present __(self, fragment, inherited_state)
For Java objects:Implement  Presentable  interface
Presentations constructed using a  combinatorial API
Label( ‘Hello’ ) Hello Button.buttonWithLabel( ‘Button’ ) Button a = Label( ‘A’ ) b = Label( ‘B’ ) c = Label( ‘C’ ) d = La...
Presentation combinators:Many moreFlow layouts, mathematical fractions, superscriptRich text, other utilitiesWrite your ow...
“ Type coercion is easy”DEMO:__present__()
Can also handle objects in the Java or Python standard libraries
Create an ‘object presenter’.Register it for the relevant class.When asked to present an instance of the class, Larch find...
Thats how the images were shown;they are java.awt.BufferedImage objects
Perspectives
Different perspectives present an object in different ways
Like different views in MVC
The one I have talked about ( __present__ ,  Presentable , etc) is the ‘Default perspective’
There are other perspectives
E.g. The inspector perspectives
“ Visual Introspection”DEMO: INSPECTOR PERSPECTIVE
Programming Environment-Visual console
You’ve seen most of it
So lets look at some of the more ‘esoteric’ features
Model dragging
Everything in Larch is an object being presented (via type coercion)
The home pageProjectsThe console itself!
What if we want to manipulate an object that we can see?
CTRL+ALT +drag it!
“ I see something: how does it work?”DEMO: inspect a project
An interesting side fact!
Our source code editor does not edit text
Its a structured editorCode is represented as an abstract syntax tree (AST)
A perspective is used to present is as something that looks and behaves (mostly) like text
It means our code is in tree form
We can write our own refactorings!
“ Change your code fast!”DEMO:Refactoring
Programming Environment-Worksheets
Interactive consoles are great.Caveat: gets difficult when working with more than a few lines of code at a timeE.g. Whole ...
For complete programs we turn to a text editorWe lose the interactivity 
What if we could blend the two?(and add rich text to boot)
“ Python modules. With pictures.”DEMO: WORKSHEET(with cellular automata)
Worksheets are active documents
Act as modulesCan import code from other worksheets within the project
You can divide your module code into a number of blocks
Each block can show a result – a step along the path of a computation
To refresh results: hit F5
Rapid Edit-Run-Debug cycle:Alter code F5 Repeat
“ Code faster!”DEMO: Edit-Run-Debug cycle(cellular automata)
Visual Programming
Quite a rich history in the research community
Circuit diagrams (LabView), data-flow diagrams, draggable tiles (Scratch, Squeak tile view), etc
Nice for small simple programs
Large programs look like rat’s nestsNot practical 
Text remains the dominant medium for source code
Diagrams are still appropriate in certain circumstances
Lets use diagrams (or visual layout) where we need them!
“ Play God.”DEMO: OrrerySub-demos:Table editorsEmbedded table
“ Drawings. Inside code.”DEMO: Polygon
Embedded objects can use a protocol to customise their behaviour
__py_eval__ Act like an expression - return the result of  evaluating __py_evalmodel__ Act like an expression - return an ...
AST GenerationWhat does this sound like?
AST Generation~=Visual LISP macros 
Crosses compile-time / run-time barrier
Compile-time (edit-time) objects available at run time
Run-time objects / values can modify or be modified by compile-time objects
“ LISPy Smalltalky goodness”DEMO: LZW compressor
Literate programming style extensions
Literate programmingRefresher
Invented by Knuthcirca 1984
Basic idea
Present programs as documents suitable for reading by people
Break a program into sections, in the same way you do for a book
Each section consists of a natural language description, and the code that implements it
Present sections in the order of ‘human logic’*, not the order of the compiler * Wikipedia article on Literate Programming
Use the ‘weave’ tool to generate the human readable document, typeset with LATEX
Use the ‘tangle’ tool to generate compile code for compiler
Use the ‘tangle’ tool to generate compile code for compiler
Our approach
Use embedded objects to represent sections(Python expressions and suites)
Allow them to be references/used in multiple placed throughout the document
“ Interactive pretty docuemnts”DEMO: Literate extensions
Conclusions
Visual object presentation by type-coercion
Encourages a functional approach to UI composition Handling state changes:Re-create, DON’T MUTATE
Visual representation of values is a BIG  EPIC  WINEven if you use only visual cues (e.g. borders around text)
Worksheets are active documents. They also expand on the rapid edit-run cycle of the console
Allow for rapid development of visual interactive applications
Visual programming by embedded objects
Visual programming where you need it
Allows you to  visually  extend the syntax of the language
No need to alter the compiler – its just embedded object references
References to objects you implement yourself
Embedded object referencesCan cross compile-time / run-time barrier
LISPy / Smalltalky stuffIN PYTHON
PROJECT STATUS
Research Prototype(not ready for real use )
TODOs:DocumentationBug fixesToo much more........
Related Work
MathematicaMathematica CDFIntentional Software Domain WorkbenchJetbrains Meta Programming System
Acknowledgements
Dr. Richard Kennaway Prof. Andy Day University of East Anglia, Norwich, UK Academic supervisory team
Developing The Larch would have been very difficult without Jython The Jython team
IF TIME ALLOWS:DEMO: KD-Tree
IF TIME ALLOWS:DEMO: SIMPLE COMPILER
<ul><li>G. FRENCH </li></ul><ul><li>J. R. KENNAWAY </li></ul><ul><ul><li>M. DAY </li></ul></ul><ul><li>http://sites.google...
Upcoming SlideShare
Loading in...5
×

The Larch - a visual interactive programming environment

617

Published on

The Larch Environment is a visual interactive programming environment for Jython/Python, that makes programming more visual. Its is designed for the creation of visual interactive programs, and programs that operate as interactive technical literature. To this end, protocols for presenting objects visually have been devised. An active document based programming environment builds on the edit-run-debug cycle of a standard console, allowing a programmer to experiment with ideas, and develop visual programs at the same time. Additionally, a way of embellishing source code with visual content is presented.
http://sites.google.com/site/larchenv

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
617
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Larch - a visual interactive programming environment

  1. 1. A VISUAL INTERACTIVE PROGRAMMING ENVIRONMENT FOR PYTHON http://sites.google.com/site/larchenv G. FRENCH J. R. KENNAWAY A. M. DAY PYCON IRELAND 2011 The Larch Environment Image by alcomm, flickr.com
  2. 2. Motivation
  3. 3. We look at three problems
  4. 4. Textual output in a Python console can be difficult to understand(DEMO)
  5. 5. Source code in a text editor is not interactive enoughConsoles are only good for a few lines at a time
  6. 6. Textual source code can be difficult to understand and comprehend(think the vertices of a polygon in code form)
  7. 7. What is‘The Larch Environment’?
  8. 8. A visual interactive programming environment
  9. 9. The goal is:To make programming more visual
  10. 10. How do we do that? <ul><ul><li>Visual object presentation </li></ul></ul><ul><ul><li>Programming environment </li></ul></ul><ul><ul><ul><li>Visual console </li></ul></ul></ul><ul><ul><ul><li>Worksheets </li></ul></ul></ul><ul><ul><li>Visual programming via embedded objects </li></ul></ul>
  11. 11. Visual object presentation
  12. 12. “ Pictures are pretty”DEMOVisual console
  13. 13. What design pattern do we commonly use for developing GUI apps?
  14. 14. Model View Controller MVC Architecture
  15. 15. MVC requires:Model class, View class, Controller class
  16. 16. Our approach:Type coercionType coercion: coerce an object to another type.
  17. 17. Type coercion used throughout Python
  18. 18. Examples:repr(), str()__index__()etc
  19. 19. Its simple
  20. 20. The Larch Environment:Use type coercion for visual presentation
  21. 21. Coerce objects to something visual(a Pres )
  22. 22. HOWTO:The simplified version
  23. 23. Define the following method:def __ present __(self, fragment, inherited_state)
  24. 24. For Java objects:Implement Presentable interface
  25. 25. Presentations constructed using a combinatorial API
  26. 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 ] ) A B C D
  27. 27. Presentation combinators:Many moreFlow layouts, mathematical fractions, superscriptRich text, other utilitiesWrite your own by combining existing ones!P.S. Appearance controlled with style sheets
  28. 28. “ Type coercion is easy”DEMO:__present__()
  29. 29. Can also handle objects in the Java or Python standard libraries
  30. 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)
  31. 31. Thats how the images were shown;they are java.awt.BufferedImage objects
  32. 32. Perspectives
  33. 33. Different perspectives present an object in different ways
  34. 34. Like different views in MVC
  35. 35. The one I have talked about ( __present__ , Presentable , etc) is the ‘Default perspective’
  36. 36. There are other perspectives
  37. 37. E.g. The inspector perspectives
  38. 38. “ Visual Introspection”DEMO: INSPECTOR PERSPECTIVE
  39. 39. Programming Environment-Visual console
  40. 40. You’ve seen most of it
  41. 41. So lets look at some of the more ‘esoteric’ features
  42. 42. Model dragging
  43. 43. Everything in Larch is an object being presented (via type coercion)
  44. 44. The home pageProjectsThe console itself!
  45. 45. What if we want to manipulate an object that we can see?
  46. 46. CTRL+ALT +drag it!
  47. 47. “ I see something: how does it work?”DEMO: inspect a project
  48. 48. An interesting side fact!
  49. 49. Our source code editor does not edit text
  50. 50. Its a structured editorCode is represented as an abstract syntax tree (AST)
  51. 51. A perspective is used to present is as something that looks and behaves (mostly) like text
  52. 52. It means our code is in tree form
  53. 53. We can write our own refactorings!
  54. 54. “ Change your code fast!”DEMO:Refactoring
  55. 55. Programming Environment-Worksheets
  56. 56. Interactive consoles are great.Caveat: gets difficult when working with more than a few lines of code at a timeE.g. Whole modules
  57. 57. For complete programs we turn to a text editorWe lose the interactivity 
  58. 58. What if we could blend the two?(and add rich text to boot)
  59. 59. “ Python modules. With pictures.”DEMO: WORKSHEET(with cellular automata)
  60. 60. Worksheets are active documents
  61. 61. Act as modulesCan import code from other worksheets within the project
  62. 62. You can divide your module code into a number of blocks
  63. 63. Each block can show a result – a step along the path of a computation
  64. 64. To refresh results: hit F5
  65. 65. Rapid Edit-Run-Debug cycle:Alter code F5 Repeat
  66. 66. “ Code faster!”DEMO: Edit-Run-Debug cycle(cellular automata)
  67. 67. Visual Programming
  68. 68. Quite a rich history in the research community
  69. 69. Circuit diagrams (LabView), data-flow diagrams, draggable tiles (Scratch, Squeak tile view), etc
  70. 70. Nice for small simple programs
  71. 71. Large programs look like rat’s nestsNot practical 
  72. 72. Text remains the dominant medium for source code
  73. 73. Diagrams are still appropriate in certain circumstances
  74. 74. Lets use diagrams (or visual layout) where we need them!
  75. 75. “ Play God.”DEMO: OrrerySub-demos:Table editorsEmbedded table
  76. 76. “ Drawings. Inside code.”DEMO: Polygon
  77. 77. Embedded objects can use a protocol to customise their behaviour
  78. 78. __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
  79. 79. AST GenerationWhat does this sound like?
  80. 80. AST Generation~=Visual LISP macros 
  81. 81. Crosses compile-time / run-time barrier
  82. 82. Compile-time (edit-time) objects available at run time
  83. 83. Run-time objects / values can modify or be modified by compile-time objects
  84. 84. “ LISPy Smalltalky goodness”DEMO: LZW compressor
  85. 85. Literate programming style extensions
  86. 86. Literate programmingRefresher
  87. 87. Invented by Knuthcirca 1984
  88. 88. Basic idea
  89. 89. Present programs as documents suitable for reading by people
  90. 90. Break a program into sections, in the same way you do for a book
  91. 91. Each section consists of a natural language description, and the code that implements it
  92. 92. Present sections in the order of ‘human logic’*, not the order of the compiler * Wikipedia article on Literate Programming
  93. 93. Use the ‘weave’ tool to generate the human readable document, typeset with LATEX
  94. 94. Use the ‘tangle’ tool to generate compile code for compiler
  95. 95. Use the ‘tangle’ tool to generate compile code for compiler
  96. 96. Our approach
  97. 97. Use embedded objects to represent sections(Python expressions and suites)
  98. 98. Allow them to be references/used in multiple placed throughout the document
  99. 99. “ Interactive pretty docuemnts”DEMO: Literate extensions
  100. 100. Conclusions
  101. 101. Visual object presentation by type-coercion
  102. 102. Encourages a functional approach to UI composition Handling state changes:Re-create, DON’T MUTATE
  103. 103. Visual representation of values is a BIG EPIC WINEven if you use only visual cues (e.g. borders around text)
  104. 104. Worksheets are active documents. They also expand on the rapid edit-run cycle of the console
  105. 105. Allow for rapid development of visual interactive applications
  106. 106. Visual programming by embedded objects
  107. 107. Visual programming where you need it
  108. 108. Allows you to visually extend the syntax of the language
  109. 109. No need to alter the compiler – its just embedded object references
  110. 110. References to objects you implement yourself
  111. 111. Embedded object referencesCan cross compile-time / run-time barrier
  112. 112. LISPy / Smalltalky stuffIN PYTHON
  113. 113. PROJECT STATUS
  114. 114. Research Prototype(not ready for real use )
  115. 115. TODOs:DocumentationBug fixesToo much more........
  116. 116. Related Work
  117. 117. MathematicaMathematica CDFIntentional Software Domain WorkbenchJetbrains Meta Programming System
  118. 118. Acknowledgements
  119. 119. Dr. Richard Kennaway Prof. Andy Day University of East Anglia, Norwich, UK Academic supervisory team
  120. 120. Developing The Larch would have been very difficult without Jython The Jython team
  121. 121. IF TIME ALLOWS:DEMO: KD-Tree
  122. 122. IF TIME ALLOWS:DEMO: SIMPLE COMPILER
  123. 123. <ul><li>G. FRENCH </li></ul><ul><li>J. R. KENNAWAY </li></ul><ul><ul><li>M. DAY </li></ul></ul><ul><li>http://sites.google.com/site/larchenv </li></ul>THANK YOU! Image by alcomm, flickr.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×