[lmeyerov]

Sketching is a superset of programming by example. In examples, you only get input/output pairs, which as this thread shows, infers frustratingly close but wrong programs.

In sketching, the input and output can also includes partial programs (sketches), so you can mark what you like, tweak, etc, and it fills in the rest.

Increasing usability, the fragments can be in different languages. For example, input can be simple C and some test data, and output can be CUDA GPU code or pthread mutex locking schemes.

For Graphistry.com, we believe in these techniques for ETL and sketching visualizations.

(Also, sketching normally uses machine learning or SAT/SMT solvers: types are more typically used for input hints.)

[sitkack]

Cool. I have been mulling what it would be like to have a semigraphical tool to generate SQL queries (Spark,Hive,VoltDB,etc) where the user would drive a keyboard applying operators over columns, rows and relations for mapping, filtering, joining. Like VIM plus ZPL and the goal is a statistical result over some range. Why can't prolog programs generate our programs? One of my query visualizations is an origami like structure where data is joined across a relation, something like an Explain Plan on Hollywoolsd.

By analogous, I meant more generally, using some partial knowledge about a program or spec to fill in missing pieces, not types specifically.

Nice to know folks are using these techniques to do real world tasks, I always thought something like this would be first used for cleaning data. Types, properties, sketches and examples.

Three levels of relatedness, https://vimeo.com/22606387

[lmeyerov]

Indeed -- check out my strangeloop talk on places we did this :) http://www.infoq.com/presentations/dsl-visualization