Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| project_qfwfq_notes [2011-11-10 12:23] – davegriffiths | project_qfwfq_notes [2011-11-10 16:13] (current) – davegriffiths | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====Brainstorming | + | ======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, | ||
| + | * 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' | ||
| + | |||
| + | ==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: | ||
| + | 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=== | ===Range of interesting technologies=== | ||
| Line 48: | Line 104: | ||
| * 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== | ==Finding appropriate ways of programming with a limited interface== | ||
| Line 61: | Line 119: | ||
| * Amorphous programming, | * Amorphous programming, | ||
| * Is this more suitable framework for less discrete/" | * Is this more suitable framework for less discrete/" | ||
| - | * Multiple levels | + | * Multiple levels |
| + | |||
| + | ==Novel approaches to creativity== | ||
| + | * Games as learning environments - well researched area | ||
| + | * Game world as "safe space" for experimentation/ | ||
| + | * Games as ways for people to see things from different perspectives | ||
| + | * "Game programming" | ||
| + | * Current examples lack integration of programming into the game world itself - treated as separate " | ||
| + | * When programming " | ||
| + | * We can make this hack a feature - designed in from the start | ||
| + | * Algorithms as world, processes as agents = very visible/ | ||
| + | * 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, | ||
| + | * 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=== | ===Core motivations=== | ||
davegriffiths