[Haskell-cafe] Up and Down the Latter of Abstraction

Ertugrul Soeylemez es at ertes.de
Wed Oct 12 11:28:37 CEST 2011


Lyndon Maydwell <maydwell at gmail.com> wrote:

> I came across an interesting page about interactive abstraction called
> "Up and Down the Latter of Abstraction" [1] while browsing
> hacker-news.
>
> Under the appendix "Tools & Implementation" Bret Victor ponders:
>
>   "Perhaps language theorists will stop messing around with arrows and
> dependent types, and start inventing languages suitable for
> interactive development and discovery."
>
> I don't subscribe to the idea that static guarantees and functional
> characteristics are mutually exclusive to interactive development and
> discovery and I think they may actually complement each other
> extremely well, but this page certainly does sell the interactive
> aspect very effectively.
>
> The closest I've seen to this proces from Haskell seems to have come
> from "luite" and co (correct me if I'm wrong) and their work on the
> Diagrams package and its surrounding infrastructure [2], however,
> their interactive demonstrations no longer seem to be online. Still,
> the dominant interface seems to be web-based, and I feel that a native
> environment for this kind of explorative interactive programming would
> be more effective.
>
> Other languages that seem to be especially effective at this kind of
> development are Processing [3] and Mathematica [4].
>
> Has anyone had experience with interactive development in Haskell?

I wouldn't say that the author is entirely wrong in that there is a need
for such tools.  I just don't like the way he presents us statically
typed functional programmers.  There is absolutely no reason to believe
that this kind of programming is difficult or even impossible in
Haskell.

Quite the contrary:  As we like to write our algorithms purely,
interactive visualization becomes almost trivial, once you have a useful
library for doing it.  The Gloss library is a good start for visualizing
pure algorithms.  Unfortunately you cannot write GUIs with sliders and
input fields very well, and you cannot control the parameters via the
console, because Gloss forces your entire application into the pure
framework.  You can only write pure keyboard and mouse handlers, so
Gloss is generally very limited for real world applications, unless you
abuse laziness to deal with it.

I think the true source code solution to this problem is an FRP-based
graphics library with some simple controllable UI elements.  This is
very well possible in Haskell.  We have powerful abstractions with
powerful implementations ready to use.

You could go further by writing an editor with a builtin interpreter,
which can visualize pure Haskell functions automatically, as long as the
types are in certain type classes.  As a programmer you wouldn't have to
do anything other than perhaps specifying parameter bounds for the
sliders.

In other words:  In contrast to Bret Victor I think the statically
typed, pure Haskell with arrows and a lot of theoretic background is the
best language for this way of programming.  It's just that apparently
nobody has written the tools yet.  The editor-builtin visualizer would
indeed be a great feature.

As an amusing fact (regarding the author's call you quoted) arrows are
exactly the one abstraction, which would make this also accessible to
impure or automaton-style computations.  A type class ArrowAnimation
could enable visualization of nonstatic computations like automata, FRP
systems, impure operations, nondeterministic computations, etc.


Greets,
Ertugrul


-- 
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/





More information about the Haskell-Cafe mailing list