Differences

This shows you the differences between two versions of the page.

--- project_qfwfq_notes [2011-11-10 12:14] – 213.243.162.31
+++ project_qfwfq_notes [2011-11-10 16:13] (current) – davegriffiths
@@ Line 1: / Line 1: @@
-====Brainstorming space====
+======Recycling from the original FET proposal======
+In general (as a FET proposal) much more specific and product centred than we have been discussing - seems like it is a subset of what we want to do, mostly specific to VPLs.
+==Feature list for a language==
+Important VPL features (”Simple things should be simple. Complex things should be possible.” -A.
+Kay)
+  * multiparadigm VPL (eg. capable of dataflow, message passing, onion skinning, grids)
+  * introspection (eg. language level inspection of active constructs)
+  * metaprogramming (eg. programs that write programs)
+  * distributed (eg. cluster or GRID based)
+  * high level as well as low level constructs
+Important editor features (“Things should be as simple as possible, but no simpler.” - A. Einstein)
+  * uses graphical metaphors and tools
+  * supports interactive, incremental development
+  * uses language features for debugging and testing
+  * capable of editing textual representations if required
+  * multiple views / resolutions
+  * automatic layout / presentation (n<10^6 nodes)
+  * flexible / extensible
+Perhaps it's useful to minimise the distinction between language and IDE?
+This is stuff which we haven't focused/elaborated on:
+==Scalability==
+"One of the major reasons for the lack of adoption has been the scalability of visual programs, as there
+has been little (if any) successful work in scaling the well documented benefits achievable with small
+systems (on the level of 1000s of lines of C code), to systems on the scale of a kernel (Linux is
+approx. 2x10^6 lines of C) or an operating system (Redhat 7 is approx. 3x10^7 lines of text based
+code). While ‘lines of code’ is not necessarily an effective measure of a program (or system’s)
+complexity it does give an indication as to the relative scale of such code-bases."
+==(Automatic) Interfaces with external libraries==
+"For any language to be of general use currently (and in the future), it requires interfaces to enable
+interoperation with commonly used libraries and hardware in heterogeneous computer systems."
+"This design would incorporate ideas from existing, large scale networked software distribution projects, such as CPAN, (the Comprehensive Perl Archive Network), CTAN (for TeX), Debian (with over 100,000 software packages running on 11 architectures). While it is beyond the scope of the project to establish or administer such a network, it
+is a necessary step for future adoption of the language, so warrants some investigation. We anticipate that extending existing software would provide the required features."
+==Different application areas==
+  * Prototyping: "The major strengths that the Qfwfq system has over existing software systems are in rapid
+prototyping and design. Currently RAD (rapid application development) and RSP (rapid systems
+prototyping) tools are in use in every major industry and are becoming a more important part of the
+workflow."
+  * Media industry
+  * Distributed computing
+  * Sensor networks
+  * GIS (geographical information systems)
+  * HEP (high energy physics)
+======Brainstorming======
 ===Range of interesting technologies===
-* Tangible interface
+  * Tangible interface
-* Haptic feedback
+  * Haptic feedback
-* Touchscreens
+  * Touchscreens
-* Keyboard/Mouse
+  * Keyboard/Mouse
 ===Towards Potential concreteness===
@@ Line 14: / Line 70: @@
 ==Tangible programming for searching open data==
-* Human augmented realtime search (over batch mode search)
+  * Human augmented realtime search (over batch mode search)
-* Is a change in emphasis (human interaction over raw speed) worth the trade off?
+  * Is a change in emphasis (human interaction over raw speed) worth the trade off?
-* How can this be realised?
+  * How can this be realised?
-  - Interfaces
+    * Interfaces
-  - Suitible algorithms
+    * Suitible algorithms
-  - Suitible visualisations
+    * Suitible visualisations
-* Going further - realtime modification of (eg. search) algorithms while they are running
+  * Going further - realtime modification of (eg. search) algorithms while they are running
-  - Human shaping/adapting an algorithm as it searches
+    * Human shaping/adapting an algorithm as it searches
-  - Connection to livecoding
+    * Connection to livecoding
-  - Collaboration - allowing new levels of engagement with massive datasets by multiple parties
+    * Collaboration - allowing new levels of engagement with massive datasets by multiple parties
-  - Conflict resolution
+    * As a form of conflict resolution
-  - Performative aspect - Hans Rosling style, but where the algorithms are open to criticism/flexible, more compatible with spirit of open data
+    * Performative aspect - Hans Rosling style, but where the algorithms are open to criticism/flexible, more compatible with spirit of open data
-  - Public access to data and interpretation
+    * Public access to data and interpretation
-  - Fiddle with the interpretations for yourself?
+    * Fiddle with the interpretations for yourself?
-  - Online/accessible/cheap tech very important here
+    * Online/accessible/cheap tech very important here
 =="Getting a feel" for large datasets==
-* Often cited as a problem by many professionals in different areas
+  * Often cited as a problem by many professionals in different areas
-  - "Used to be able to look at the numbers in a text editor/excel, now I can't"
+    * "Used to be able to look at the numbers in a text editor/excel, now I can't"
-* Already have an intimate knowledge of their data, this is lost with size/"when it goes into the computer"
+  * Already have an intimate knowledge of their data, this is lost with size/"when it goes into the computer"
-* Why is this a problem?
+  * Why is this a problem?
-  - Leads to a loss of control/understanding
+    * Leads to a loss of control/understanding
-  - Need to understand implications of algorithms - perhaps before data is collected
+    * Need to understand implications of algorithms - perhaps before data is collected
-* How can it be solved?
+  * How can it be solved?
-  - Psychologically (what is missing?)
+    * Psychologically (what is missing?)
-  - Technically
+    * Technically
-* How domain specific does the solution need to be, is it generalisable?
+  * How domain specific does the solution need to be, is it generalisable?
 ==Understanding of time==
-* A problem in social networks
+  * A problem in social networks
-* Implications in other areas
+  * Implications in other areas
-* Use of music
+  * Use of music
+  * Human time vs computer time
+    * Moving between these for tangibility
 ==Finding appropriate ways of programming with a limited interface==
-* Making phones/tablets hackable
+  * Making phones/tablets hackable
-  - Lack of tools in this area is a fundamental problem
+    * Lack of tools in this area is a fundamental problem
-  - Leads to specialisation of programming, reduces accessibility massively
+    * Leads to specialisation of programming, reduces accessibility massively
-  - Focus on Aakash for example
+    * Focus on Aakash for example
-* Text editors (even with nice features) suck on touch screens
+  * Text editors (even with nice features) suck on touch screens
-  - Perhaps "making text geometric" (scratch) is not enough either
+    * Perhaps "making text geometric" (scratch) is not enough either
-* Does this actually require rethink of programming down to language level?
+  * Does this actually require rethink of programming down to language level?
-  - New language axioms or just representations of eg map/reduce/filter/for
+    * New language axioms or just representations of eg map/reduce/filter/for
-  - Amorphous programming, focus on parallel, spatially arranged small programs robust to fuzziness
+    * Amorphous programming, focus on parallel, spatially arranged small programs robust to fuzziness
-    - Is this more suitable framework for less discrete interfaces?
+      * Is this more suitable framework for less discrete/"gestural" interfaces?
-    - Multiple levels
+      * Multiple levels of process resolution (parallel with overall marshaling - scatter/gather approach?)
+==Novel approaches to creativity==
+  * Games as learning environments - well researched area
+    * Game world as "safe space" for experimentation/creativity
+    * Games as ways for people to see things from different perspectives
+  * "Game programming" as solid existing basis for creative learning
+  * Current examples lack integration of programming into the game world itself - treated as separate "layer"
+    * When programming "invades" gameworld currently, it's a hack - minecraft/little big planet CPUs
+    * We can make this hack a feature - designed in from the start
+  * Algorithms as world, processes as agents = very visible/tangible programming model
+    * As a solution to algorithmic malleability
+      * Easy to see whats going wrong and where
+      * It's realtime
+  * Games as environments filled with interacting agents (incl humans)
+    * Human level of understanding, rather than machine
+    * Current languages abstract machine process into human level metaphor (for/while loops etc -> assembler)
+    * Next languages need to also abstract machine time to human understanding?
+    * Remove the write, compile, run cycle - programming as interaction (see above)
+    * Debugging techniques
-====Initial 2011 reset====
+======Initial 2011 reset======
 ===Core motivations===