LtU Forum

Chocolate & Peanut-butter: Google Blockly & Behavior Threads

My day job involves GUI work on smartphones (pity me) so I like finding out about things like this:

Abstract
We combine visual programming using Google Blockly with a single-threaded implementation of behavioral programming (BP) in JavaScript, and propose design patterns for developing reactive systems such as client-side Web applications and smartphone customization applications as collections of independent cross-cutting scenarios that are interwoven at run time. We show that BP principles can be instrumental in addressing common software engineering issues such as separation of graphical representation from logic and the handling of inter-object scenarios. We also show that a BP infrastructure can be implemented with limited run-time resources in a single-threaded environment using coroutines. In addition to expanding the availability of BP capabilities, we hope that this work will contribute to the evolving directions of technologies and design patterns in developing interactive applications.

Future of Programming Videos, final program

The final program from the SPLASH Future of Programming workshop is up. A lot of great videos with a lot of great ideas for the future of our field!

Contents with brief one liners (see the program page for more detailed abstracts):

Antha programming system for Bioinformatics

Antha is a high-level language for biology, making it easy to rapidly compose reproducible work flows using individually testable and reusable Antha Elements.

Recently made open source, the programming system Antha uses flow based programming. They have set up a bioinformatics related set of types in said system.

(I have nothing to do with the project, haven't even used it, but sure wish I could get paid to do so. :-)

Whither compositionality: Declarative vs. imperative?

From the other thread, I read Relations as First-Class Citizen from which I wonder: If we are seeking good support for compositionality, how might a declarative/calculus approach go wrong? What is it about SQL or Make or whatever else (e.g. random thing IBM's Collage) that might contribute to compositional frustration?

While the declarative style of programming of SQL is very nice for solving very specific and well isolated sub-problems in your requirements & design space, it is of almost no aid for putting the architectural pieces together. Yet, putting the pieces together is something software engineers do every single day. And so is writing algorithms. Exposing a relational algebra therefore appears more natural when it comes to software development, and when it comes to manipulating data vs. querying database. To be fair, libraries such as ARel, Sequel, and jOOQ already show the way: they provide an API that is closer to relational algebra than relational calculus. Alf and Axiom simply go further this path by abstracting from SQL and choosing a sound algebra known as Tutorial D as a better inspiration than SQL towards the same objective.

An algebra is about providing operators for putting operands together, a calculus simply is not.

CFP: International Conference on Live Coding

International Conference on Live Coding
13-15th July 2015, University of Leeds, UK
http://www.livecodenetwork.org/iclc2015/

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 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://www.livecodenetwork.org/iclc2015/

Code Completion for Generic Programming

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

Lisps are fun

I think this paper is a really nice blast from the past.

L is a subset of Common Lisp with multi-processing extensions. It is ideal for use in embedded systems with small computers. The system has a minimal memory footprint and can run on small processors.

Too bad it doesn't seem to be available online anywhere. Might any LtU user have the social network to find it / obtain it / write an eulogy about it?

managing closed worlds of symbols via alpha-renaming in loosely coupled concurrent apps

I enjoyed discussion in Why do we need modules at all? (about Joe Armstrong's post on the same topic) more than anything else on LtU the last few years. Several comments reminded me of something I've been thinking about several years now. But describing it doesn't seem on topic in reply (or, I lack the objectivity to tell). The modules thread is already long, and I don't want to pollute it with junk.

This is mainly about transpiling, where you compile one source to generate another, with a goal of automated rewrite, where both syntax and complexity in the input and output are similar: compiling one language to itself, but re-organized. For example, you can use continuation passing style (CPS) to create fibers (lightweight threads) in a language without them natively, like C. Obviously this is language agnostic. You can add cooperative fibers to any language this way, from assembler to Lisp to Python, as long as you call only code similarly transformed. You're welcome to free associate about this or anything else mentioned, though. For the last year or so, almost all my thinking on the topic has been about environment structure, lightweight process management, and scripts effecting loose coupling relationships via mechanisms similar to Unix, such as piping streams, etc. Once you work out how a core kernel mechanism works, all the interesting parts are in the surrounding context, which grow in weirdly organic ways as you address sub-problems in ad hoc ways. Thematically, it's like a melange of crap sintered together, as opposed to being unified, or even vaguely determined by constraints stronger than personal taste.

Note I'm not working on this, thus far anyway, so treat anything I say as an armchair design. There's no code under way. But I probably put a couple thousand hours thinking into it the last seven years, and parts may have a realistic tone to them, in so far as they'd work. It started out as a train of thought beginning with "how do I make C behave like Erlang?" and grew from there. I've been trying to talk myself into wanting to code parts of it, sometime.

Several folks mentioned ideas in the other thread I want to talk about below, in the context of details in the armchair design problem. (I'll try to keep names of components to a minimum, but it gets confusing to talk about things with no names.) Most of the issues I want to touch deal with names, dependencies, modules, visibility, communication, and the like, in concurrent code where you want to keep insane levels of complexity in control if possible.

Impact of static type systems on productivity of actual programmers: first experiment I've seen documented.

It is disappointing that no particular results positive or negative were observed. But it is gratifying, and long overdue, that someone finally thought the question was important enough to perform an actual experiment to answer it.

http://courses.cs.washington.edu/courses/cse590n/10au/hanenberg-oopsla2010.pdf

DARPA funds $11 million tool that will make coding a lot easier

http://www.engadget.com/2014/11/09/darpa-pliny-coding/

That's a lot of money for a good idea (using large bodies of existing code to complete what the programmer write's) that everyone seems to be working on. Does Rice have some special advantage here that justifies the investment?

XML feed