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