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

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

11. Visual object presentation

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

18. Examples:repr(), str()__index__()etc

19. Its simple

20. The Larch Environment:Use type coercion for visual presentation

21. Coerce objects to something visual(a Pres )

22. HOWTO:The simplified version

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

39. Programming Environment-Visual console

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?

46. CTRL+ALT +drag it!

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

55. Programming Environment-Worksheets

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)

67. Visual Programming

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

86. Literate programmingRefresher

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