thinking in diagrams, flows or partial processes (notes to be gradually merged with Visual Programming)

is it possible to create an environment which facilitates prototyping, yet enables optimisation for high performance 'production'? in which a number of representations which are not mutually exclusive are able to be accomodated. thus enabling different ways of expressing similar ideas, in a compatible/possibly complimetnry manner.

editing/running programms should be tightly linked. the editing environment should enhance the method of expressing the ideas. eg. emacs/vi for text, illustrator/gimp for graphics.

sketching solutions + filling in the details

demos and finished 'applications' should be equally possible

understandable by a range of people, programmers (familiar with the env, and unfamiliar), technical ppl who are not computer specialiasts (doctor, woodworker, civil engineer, etc) , creative ppl, who often use a computer as a tool (eg. video editing, graphic design, music,. etc). others (with some encouragement)

problems of representations, primacy of text or graphic rep.?

• is it possible to edit a text rep. and still maintain a readable graphic version?
• and vice versa. (graphic editing shouldnt corrupt a text rep. beyond recognition/ usability)
  • layout info in comments?
  • automatic generation of visual layout from text (eg. graphviz)
  • text from graphic
  • 1:1 relation between algorithm as img + text (possible? runtime expansions??)

static vs. dynamic display

• what happens to a visual programme when its running?
  • static: max/pd/labview in which solid lumps have data flowing thru them,.
  • dynamic: boxes are 'expanded', created, destroyed + computational result is substituted (eg. graph rewriting langauge(s))
  • onion like: more apropriate for functional lang. in that continuations are passed out the edge of the onion
• how to debug visually?
• trace as graph rewriting/redrawing?
  • static rep. with option to display rewriting for debugging.

semantics

• how necesary is a formal spec of the visual layout.
• depends on approach.. .
• almost definately requires explanation of the evaluation/runtime cycle (R-L or L-R prioritizing, threading, ambigutities between text + img. rep. etc+ )

approaches

• new lang. spec which fits all the requirements
• adapt an existing langauge / toolchain
• extend an existing langauge / toolchain

examples

• max/pd/etc+
• labview
• graph rewriting langs. (see Visual Programming)
• dataflow 'scripting' in 3d tools (eg. houdini, blender)

a good prototying environment enables rapidly testing of ideas, which usually involves throwing away a lot of test code and making many modifications to a range of more-or-less working programs. getting something working easily is more important than it working efficiently and/or accurately and/or elegantly. not that this is inherently the case; prototyping can help reveal an effcient, elegant acurate algorithm. the level of detail is at the algoritm/process rather than the level of machine detail (malloc, memcopy, etc+)

lots of interfaces to other things helps; either other code libs (filesystems, databases, protocols etc.) or interface to the real world (eg. servo control, instrument interfacing (sci/med instruments or music/synthesisers)) this saves time re.implementing the 'known' aspects of a problem.

custom hardware interfaceing; low level interupts, memory maps etc. data packing, os interface possibly. it should be possible to test an interface with some indication of performance, or interface with an interface that interfaces with the hardware. a test program should be able to be rewritten in asm or c (high level asm) or optimised to compile for target platform. usually cannot include the dev. environment /interpreter /whatever, req. specific binary format, and often minimal (if any) libs. sbcl compiler backend vs gcc compiler backend. ffigen from gcc. generating compiler backends from ABIs

schemix is a demonstration of using scheme in the linux kernel for prototyping kernel modules

mimise rewrites from working prototype → working production system. typically this cycle may involve several langauges, which are not nec. compatible thru the cycle.

prototyping?

• +ve
  • quick
  • easy to modify
  • often nec. to understand problem domain
• -ve
  • can be messy
  • can be inefficient

visual languages?

• +ve
  • very good prototyping support
  • readable/editable (to a degree) by non-programmers
  • encourage abstraction by reducing visual clutter
• -ve
  • slow
  • low level interface often required a language shift (to a lower level language)
  • proficient text based programmers can feel restrained

asm/c?

• +ve
  • speed
  • efficiency
  • size
  • close to hardware
• -ve
  • lots of details
  • changes are costly
  • close to hardware

as a possible candidate for a visual language based on extending an existing lang.., (either CL, scheme or a future dialect).

why LISP?

• good for prototyping as well as being good for low level optimisation/interfacing
• code for writing code that writes code (that writes code)
• one of the better languages for writing languages in
• flexible, adaptable, modifyable
• modern lisps perform well on modern hardware.
• existing infrastructure for many extensions/ interfaces/ compilers /etc+

“its been done” to a degree, look at OpenMusic from ircam, as an example. why does this include non-deterministic features? (see 'dataflow process network ' paper). there are a few links, but not much activity. there seem to have been a few attempts to do this.

“accelerating hindsight” http://www.nhplace.com/kent/PS/Hindsight.html

“The Transition of Context-free Textual Languages into a Visual Programming Notation via Graph Techniques and a Meta Tool” Frank B�hler, Mike Callaghan and Paul Luker Copyright 1998 IEEE. Published in the Proceedings of Compsac'98, 17-21 August, 1998 at Vienna, Austria.

VLCC is an example of a graphical parser and programming language compiler generator. http://www.dmi.unisa.it/people/costagliola/www/home/ricerca/vlcc/vlcc.htm