Lambda the Ultimate

I want generics, in particular polymorphic functions as well as function overloading based on type-classes. For the moment think about Haskell type-classes and C++ Concepts. I also want code completion. Code completion works for OO languages because they are polymorphic on the object type, which prefixes the function call, and hence the type is known when code completion lookup occurs. Generic functions can be polymorphic on any argument. This suggests that all the arguments need to go before the operator in postfix format. This way code completion can operate on the argument types, and only offer valid generic functions. It can also offer all generic functions that take those arguments in alphabetic order. I want to discuss whether this idea has any merit, and second I want to discuss syntax:

So, a reverse lisp style (likely to confuse people as no clear difference from lisp function first format):

(list comparator sort)

or perhaps reverse C:

(list, comparator) sort

Or perhaps a template C++ like syntax:

<list,comparator>.sort

Or:

list,comparator.sort

International Conference on Live Coding
13-15th July 2015, University of Leeds, UK
http://iclc.github.io

With pleasure we announce the initial call for papers and performances for the first International Conference on Live Coding, hosted by ICSRiM in the School of Music, University of Leeds, UK.

This conference follows a long line of international events on liveness in computer programming; the Changing Grammars live audio programming symposium in Hamburg 2004, the LOSS Livecode festival in Sheffield 2007, the annual Vivo festivals in Mexico City from 2012, the live.code.festival in Karlsruhe, the LIVE workshop at ICSE on live programming, and Dagstuhl Seminar 13382 on Collaboration and Learning through Live Coding in 2013, as well as numerous workshops, concerts, algoraves and conference special sessions. It also follows a series of Live Coding Research Network symposia on diverse topics, and the activities of the TOPLAP community since 2004. We hope that this conference will act as a confluence for all this work, helping establish live coding as an interdisciplinary field, exploring liveness in symbolic abstractions, and understanding the perceptual, creative, productive, philosophical and cultural consequences.

The proceedings will be published with ISSN, and there will also be an follow-on opportunity to contribute to a special issue of the Journal on Performance Arts and Digital Media; details will be announced soon.

Timeline

* Templates available and submissions system open: 8th December 2014
* Performance submissions deadline: 16th February 2015
* Paper submissions deadline: 1st March 2015
* Notification of results: 10th April 2015
* Camera ready deadline: 10th May 2015
* Conference: 13-15th July 2015

Submission categories

* Long papers (6-12 pages)
* Short papers (4-6 pages)
* Poster/demo papers (2-4 pages)
* Performances (1-2 page abstract and technical rider)

ICLC is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognise that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to Live Coding research, cite relevant previous work, and apply appropriate research methods.

The following long list of topics, contributed by early career researchers in the field, are indicative of the breadth of research we wish to include:

* Live coding and the body; tangibility, gesture, embodiment
* Creative collaboration through live code
* Live coding in education, teaching and learning
* Live coding terminology and the cognitive dimensions of notation
* Live language and interface design
* CUIs: Code as live user interface
* Domain specific languages, and the live coding ecosystem
* Programming language experience design: visualising live process and state in code interfaces
* Virtuosity, flow, aesthetics and phenomenology of live code
* Live coding: composition, improvisation or something else?
* Time in notation, process, and perception
* Live coding of and inside computer games and virtual reality
* Live programming languages as art: esoteric and idiosyncratic systems
* Bugfixing in/as performance
* Individual expression in shared live coding environments
* Live coding across the senses and algorithmic synaesthesia
* Audience research and ethnographies of live coding
* Live coding without computers
* Live coding before Live Coding; historical perspectives on live programming languages
* Heritage, vintage and nostalgia – bringing the past to life with code
* Live coding in public and in private
* Cultural processes of live programming language design
* General purpose live programming languages and live coding operating systems
* Connecting live coding with ancient arts or crafts practice
* Live coding and the hacker/maker movement: DIY and hacker aesthetics
* Critical reflections; diversity in the live coding community
* The freedom of liveness, and free/open source software

Submissions which work beyond the above are encouraged, but all should have live coding research or practice at their core. Please contact us if you have any questions about remit.

Please email feedback and/or questions to livecodenet@gmail.com

http://iclc.github.io

The goal of Flow is to find errors in JavaScript code with little programmer effort. Flow relies heavily on type inference to find type errors even when the program has not been annotated - it precisely tracks the types of variables as they flow through the program.

At the same time, Flow is a gradual type system. Any parts of your program that are dynamic in nature can easily bypass the type checker, so you can mix statically typed code with dynamic code.

Flow also supports a highly expressive type language. Flow types can express much more fine-grained distinctions than traditional type systems. For example, Flow helps you catch errors involving null, unlike most type systems.

Read more here.
Here's the announcement from Facebook.