20th November 2007, 08:54 pm
Earlier this month I gave a tech talk at Google, entitled “Tangible Functional Programming: a modern marriage of usability and composability”. Thanks to Google folks, the talk is now up on YouTube. I showed a way make functional programming “tangible” and visual, rather than abstract and syntactic and, in doing so, to fulfill the original Unix vision of simple, composable apps.
The key is to keep an app’s interface and functionality combined and separable. Combined yields usability, and separable yields composability. This principle applies not only to GUI-style interfaces, but to textual IO as well, and it applies to both direct composition and syntactic composition. See the TV page for examples of the latter. The common practice of mixing IO with functionality inhibits composability whether in C or in Haskell.
Edits:
Earlier this month I gave a tech talk at Google, entitled “Tangible Functional Programming: a modern marriage of usability and composability”. Thanks to Google folks, the talk is now up...
9th July 2007, 09:19 pm
I just submitted the camera-ready version of “Tangible Functional Programming”, for ICFP ’07. I’m happy with this version. It’s improved drastically since my first submission to ICFP ’06, thanks to many helpful comments. I’ve also been recreating the implementation on top of DeepArrow, Phooey, and TV, in preparation for a software release. It’s getting simpler, but it’s not as simple as I want.
I just submitted the camera-ready version of “Tangible Functional Programming”, for ICFP ’07. I’m happy with this version. It’s improved drastically since my first submission to ICFP ’06, thanks to...
Tags:
arrow,
DeepArrow,
Eros,
gestural composition,
icfp,
interactive programming,
interactive visualization,
library,
Phooey,
TV,
writing |
Comment
30th March 2007, 12:17 pm
Three related software releases. I am very interested in comments and contributions.
TypeCompose provides some classes & instances for forms of type composition. It also includes a very simple implementation of data-driven computation. I factored it out of a new implementation of Phooey.
Phooey is a library for functional user interfaces. Highlights in this 0.3 release:
- Uses new TypeCompose package, which includes a simple implementation of data-driven computation.
- New Applicative functor interface.
- Eliminated the catch-all Phooey.hs module. Now import any one of Graphics.UI.Phooey.{Monad ,Applicative,Arrow}.
- Phooey.Monad has two different styles of output widgets, made by owidget and owidget’. The latter is used to implement Phooey.Applicative.
- Self- and mutually-recursive widgets now work again in Phooey.Monad. They wedge in Phooey.Arrow and Phooey.Applicative.
Phooey is also used in GuiTV, a library for composable interfaces and “tangible values”. I’ve also just updated GuiTV to 0.3, to sync with Phooey 1.0.
Three related software releases. I am very interested in comments and contributions. TypeCompose provides some classes & instances for forms of type composition. It also includes a very simple implementation...
27th March 2007, 11:14 am
Warning: if you’re on the ICFP program committee and want to preserve double-blind reviewing, please ignore this post.
I’ve been working on an ICFP paper called “Tangible Functional Programming”, revising my last year’s submission on Eros. If you’re interested in taking a look, I’d greatly appreciate any comments, especially before the April 6 submission deadline.
Abstract
We present a user-friendly approach to unifying program creation and execution, based on a notion of “tangible values” (TVs), which are visible and interactive GUI manifestations of pure values. Programming happens by gestural composition of TVs. Our goal is to give end-users the ability to create parameterized, composable content without imposing the usual abstract and linguistic working style of programmers. We hope that such a system will put the essence of programming into the hands of many more people, and in particular people with artistic/visual creative style.
In realizing this vision, we develop algebras for visual presentation and for “deep” function application, where function and argument may both be nested within a structure of tuples, functions, etc. Composition gestures are translated into chains of combinators that act simultaneously on statically typed values and their visualizations.
Here is a figure from the paper, showing one stage of an interactively composed interactive 2D region. The user selects compatibly-typed input and output widgets, typically in different TVs. The result is a new TV that merges the source TVs, except for the connected input and output, which vanish. The sliders control the disk and checker sizes and the checker’s rotation angle.
Edit on March 28:I just added two relevant pointers to the paper’s web page:
Warning: if you’re on the ICFP program committee and want to preserve double-blind reviewing, please ignore this post. I’ve been working on an ICFP paper called “Tangible Functional Programming”, revising...
12th February 2007, 06:04 pm
This post is a teaser for an article in my TiddlyWiki-based journal. The article illustrates an approach to separating logic and IO using the TV library. The TV approach clarifies the pure logic part and the IO part and is more conveniently composable than the mixed logic/IO formulation.
I’ve just released TV-0.2, which omits GUI functionality. That functionality is now present in the small new package GuiTV. The reason for this split is that the GUI support depends on wxHaskell, which currently can be difficult to install. Only TV (not GuiTV) is needed for this example.
See the article here.
Edit of Feb 13: If you tried the TiddlyWiki article in Opera and got an error, please try again. Problem fixed. (Slight difference in regexp handling in Opera vs FF & IE.)
Edit of March 5: This article was inspired by an example in Don Stewart’s “Programming Haskell” post.
This post is a teaser for an article in my TiddlyWiki-based journal. The article illustrates an approach to separating logic and IO using the TV library. The TV approach clarifies...
22nd January 2007, 10:09 pm
Last week I released three Haskell libraries: DeepArrow 0.0, Phooey 0.1, and TV 0.0.
These libraries came from Eros, which aims at creating a right-brain-friendly (concrete, non-linguistic) “programming” process. I’ve had a growing intuition over the last fifteen years that media authoring tools can be usefully looked at as environments for functional programming. I’d been wondering how to map a user’s gestures into operations on a functional program. Lots of noodling led to ideas of composable interfaces and “tangible values” (term thanks to Sean Seefried) and gestural composition in Eros.
Eros is more complicated than I like, so I started splitting it into pieces:
- Phooey is a functional GUI library that has much of Eros’s GUI implementation techniques, but much more carefully structured than in the Eros paper.
- DeepArrow has the general notion of “deep application”
- TV has the algebra of composable interfaces, or visualizations of pure values, and it has tangible values, which are separable combinations of interface and value. It uses Phooey to generate GUIs very simply from interfaces
Although these libraries came from Eros, I’d like to see other applications as well.
Where am I going with library development?
- Figure out how to support simple GUIs and Eros’s gesturally composable GUIs, without code/library replication.
- Re-implement Eros on top of simpler pieces.
- Refactor Pajama into reusable libraries and release.
- Building and optimizing “expressions”
- Common sub-expression elimination
- Generation of Java code
- Perhaps other back-ends besides Java
- Pajama, on top of these pieces
Edit of March 5, 2007: TV is now split into a core TV package, with no GUI functionality, and GuiTV, with Phooey-based GUI creation. The reason for the split is that Phooey depends on wxHaskell, which can be difficult to install.
Last week I released three Haskell libraries: DeepArrow 0.0, Phooey 0.1, and TV 0.0. These libraries came from Eros, which aims at creating a right-brain-friendly (concrete, non-linguistic) “programming” process. I’ve...