
Seymour: Live Programming for the Classroom - indescions_2017
https://harc.github.io/seymour-live2017/
======
taliesinb
This seems like great, quality work. Teaching is an ideal laboratory to
explore these ideas, because you're helping students to build mental models
with these interfaces, rather than merely aiding developers who already have
mental models. Building the models in the first place is the hard thing. But
having production tools that would allow experienced developers to more
efficiently do this kind of thing is also a great boon.

Introspecting into how I prototype new ideas and algorithms, the kinds of
intricate tracing and exploration that are automatically done by Seymour are
things I often do "manually", using a cobbled-together set of tools (one of
which made it into Mathematica [1]).

Sometimes, because its fairly easy to do in the language, I quickly code up
once-off tools to help me verify solutions. For example, I recently finished a
new type inference system for neural network layers that allows very flexible
'backwards' and 'sideways' inference of tensor rank and dimensions. Surveying
its behavior on all the possible inputs on the various kinds of layers is not
feasible via manually typing REPL examples or unit tests. So I ran the
inferencer against all possible cases of a certain form, and by visualizing
the results as little squares (with various other info behind tooltips and
mouseovers), I checked each result very rapidly [2] and soon found cases I
hadn't thought of.

One thing I wonder from my experience of doing this kind of thing (I've
written various visual debugging and logging frameworks, and code visualizers
of all kinds), is whether a prescribed framework and set of workflows is
actually preferable to flexible tooling that you can inject in precisely the
way you want.

I've often abandoned my visual tools because they are too hard to customize
into the exact thing I need to answer a specific, scientific question that
comes up during debugging or implementation. Also, when you are already
overloaded with thoughts and ideas about what might be going wrong, you kind
of want to be able to ask and answer extremely precise questions, rather than
swamp yourself in visual data that you have to interpret in light of your
hypothesis. Clever presentation can only help the overload so much.

I wonder if what is needed is a kind of "side program" that one could use to
annotate the main program in very precise ways and ask questions of its
execution, or to produce maps or timelines of aspects of its behavior. But not
via interactions with a GUI, although those are useful too, but as actual code
that lives alongside the real code, using the same language. Something a bit
like a souped-up, visual dtrace, perhaps. I don't know what is already out
there like that, but I would love to see work in that direction.

[1]
[http://reference.wolfram.com/language/ref/Echo.html](http://reference.wolfram.com/language/ref/Echo.html)

It's not really shown well in this documentation (I didn't write the docs),
but Echo is very easy to insert because you can just write "Echo @" as a
prefix, anywhere in ordinary code, and it basically a no-op. I have a macro
system that makes it even easier: the single quote character (which normally
means Derivative) can be put next to any expression and does the equivalent of
an Echo. Being able to inject and remove these little probes anywhere in the
codebase with a single keystroke makes the good old "print debugging" actually
pretty effective in a lot of situations. And various forms of cleverness make
it more useful, like putting it next to an assignment will also print the
variable being assigned.

[2] [https://imgur.com/l7XwbCQ](https://imgur.com/l7XwbCQ)

The first two lines of each grid represent the inputs to a CatenateLayer, the
last line is the output. Red indicates an invalid shape. Gray is "unknown".
The other colors are fixed dimensions like 2 or 3, or dynamic dimensions (used
for var-length sequence inputs). This display is from a buggy version of the
inference system, don't try to check it!

~~~
shalabhc
> I wonder if what is needed is a kind of "side program" that one could use to
> annotate the main program in very precise ways and ask questions of its
> execution, or to produce maps or timelines of aspects of its behavior. But
> not via interactions with a GUI, although those are useful too, but as
> actual code that lives alongside the real code, using the same language.
> Something a bit like a souped-up, visual dtrace, perhaps. I don't know what
> is already out there like that, but I would love to see work in that
> direction.

This is a great idea. I find it ironic that so much of programming consists of
'simulating the computer' in one's head while sitting in front of a computer.

I would love to be able to visualize many things that a compiler does
internally, for instance, to see how generic code looks when specialized in a
certain context.

------
seanmcdirmid
This will be presented at the Live programming '17 workshop next Tuesday
(10/24 in Vancouver @ Splash). For a complete program see:
[https://2017.splashcon.org/track/live-2017#program](https://2017.splashcon.org/track/live-2017#program)

~~~
indescions_2017
This is quite impressive Sean. Live programming is just getting started ;)

------
yorwba
If you want to try the interactivity in Firefox, run

    
    
      $$('.controls').forEach(controls => controls.style.display = 'inline')
    

in the console. I didn't see any breakage and I have no idea why the browser
sniffing was deemed necessary in the first place. If it had been broken, the
disclaimer would have been warning enough; no need to disable features.

It didn't work anyway: hovering over the videos toggles the visibility of
controls, which fires the mouseover event again, which toggles the controls
off, which leads to really annoying flickering. Of course nobody thought to
sniff for that.

------
edtechdev
Here's the code

[https://github.com/harc/seymour](https://github.com/harc/seymour)

[https://github.com/harc/seymour-live2017](https://github.com/harc/seymour-
live2017)

------
neves
I can't appraisal the quality of the work, but I really liked the homage to
Seymour Papert :
[https://en.wikipedia.org/wiki/Seymour_Papert](https://en.wikipedia.org/wiki/Seymour_Papert)

