Lambda the Ultimate

Continuity is implausible at the macro level but is sometimes plausible at the micro level; I wonder if we can just push that level up a bit more than it is today, given that we know the property is very useful.

Instrumentablity seems to be a new word, but I get what you mean. There is obviously huge value in being able to add (and remove!) pieces to a program without breaking it and allowing it to continue executing. Functional programming would appear to have an advantage in this regard (functions compose, imperative code requires setup).

We've done a bunch of work in Eve recently on resilient compiling/executing. Rather than blow up on compiler errors we freeze the state of views which have errors and continue executing everything else. Once we have the IO controls fleshed out we will probably also suspend IO on errors too to avoid accidentally firing the missiles. I can link to code/docs tomorrow but there isn't actually much too it - it's much easier to repair data-flow than control-flow.

I've been doing this since 2007, at least. You are right: data-flow is easier, which is why I did it for SuperGlue first (see this video from 2007). But control flow is not impossible to deal with, nor is it particularly very hard. APX is a good example of that: it is resilient to parse, type, and execution errors; it does not roll back side effects when an error state is detected, it handles IO relatively well, we can compare features at FpW StrangeLoop :)

But technology isn't really the problem, it requires work for sure, but it is not our blocker. To quote Hancock again:

And yet, if making a live programming environment were simply a matter of adding “continuous feedback,” there would surely be many more live programming languages than we now have. As a thought experiment, imagine taking Logo (or Java, or BASIC, or LISP) as is, and attempting to build a live programming environment around it. Some parts of the problem are hard but solvable, e.g. keeping track of which pieces of code have been successfully parsed and are ready to run, and which ones haven’t. Others just don’t make sense: what does it mean for a line of Java or C, say a = a + 1, to start working as soon as I put it in? Perhaps I could test the line right away—many programming environments allow that. But the line doesn’t make much sense in isolation, and in the context of the whole program, it probably isn’t time to run it. In a sense, even if the programming environment is live, the code itself is not.

Your languages semantics have to support continuous feedback, which is why data-flow languages are commonly used: its not really a technical problem...there are plenty of smart programmers out there, but it is a design problem. So live environments are almost always data-flow based, but there are problems with expressiveness with that. The hacky abstractions that we often come up with to make data flow more expressive often ruin its live programmability feature: they allow you to encode more, but you lose the feedback, the ability to water hose your code to the desired result, that comes with live programming.

and most days I would sign a blank cheque for a live programming environment.

I should start a kickstarter then :)

I would read your comments overall that "continuous" is a property that is close to "the thing that makes live programming work", but not an exact match.

True, it is not an exact match, but a useful approximation. It is sort of the "ah-ha" moment when figuring out how to generalize live programming to a wider set of problems. Right now it is very narrow.

"x" doesn't have to be continuous. It just has to be scrubbable. So if there are only 10 choices for "x", even if they are very discrete, that is fine; I can just try them all! But if there are a 100 or 1000 choices for x, you want some kind of ordering for them based on behavior that is reflected in the output.

At the end of the end, I just want to figure out how to build a type checker via scrubbing. I know its cliche, but its totally non-obvious how that could be done but it seems achievable (since as you mention, we can visualize graphs at least, we just can't write them very well).

I like the goal of building a type checker via scrubbing, it seems to be quite a juicy and tempting fruit, although maybe not one that hangs very low.

What kind of dials and knobs do you see the user twisting? One that seems kind of easy in this case is time: judgements as a series of reduxes that the user can play back and forth in. There seems to be at least one more difficult dial that would explore "bits of source code like this one". The "like this one" part being the property that needs to be quite smooth : small deltas on the input parse tree.

I'm not sure what the dials are yet. Obviously they aren't numbers and are more like selected functions.

Perhaps another way of phrasing it is that a hypothetical search would need to examine no more than 10 values to find an input close enough to the one we want? Ordered "x"s can be binary searched and continuous ones have a range of values that are close enough.

This sounds right.

After reading "Real-Time Programming and the Big Ideas of Computational Literacy" several months ago I got excited to the point where I pondered how dead programming is possible.

Naur's idea of programming as theory building is that when someone wishes to modify a program they need to a theory of how it will respond to various changes.

If programming is theory building, then anything that makes it easier to develop a theory makes it faster to develop the program. To me the central cool part of live programming is learnability. Qualities that enhance learnability are continuity, lack of delay and simplicity of relationship between input and output. By pairing a programmer's action immediately with its result, the programmer can develop a theory of changes much more quickly. With time a person learns the shape of the output-space and how to move through it with their actions, reducing the need for feedback. (I think "steady frames" are the same idea as more learnable relationships)

So much of my time programming is spent trying to understand what is going on, that a language optimized for learnability would be a godsend. Maybe computational learning theory has a way to measure learning effort.

"Learnability" is a tricky word, as recent hackernews discussions (on Come Alive, I think) can attest to. I think timely feedback benefits learnability, but it benefits other things also. Bret tweeted something about wanting to reinvent the programming experience, I definitely can agree with that.

Theory is also one of those words I can't grock very well. How do people develop and manipulate theories in their head? Do we really mean hypotheses? And really, I have no idea what goes on in people's heads, I'm just looking for an experience that increases efficiency, and creates that good adrenaline rush in your head (the blue happy fluid feeling vs. the red stressful lost feeling). There are definitely experimental cognitive psychologists who understand this better than me...I would love to frame this in terms of a law like Fitts' or Hick's law.

With time, a driver can learn how to navigate a city without GPS, but it is sure useful to still have it! I see live feedback as a fundamental augmentation of the programming experience that goes beyond learning, it shouldn't just be used as training wheels, though I guess that is a perfectly valid use case. But really, you are just training your head to do what the computer does for you during the learning process; i.e. you are learning how to do mental gymnastics when we really should be getting rid of that.

Bad analogy, I think.

With time, a driver can learn how to navigate a city without GPS, but it is sure useful to still have it!

Maybe it's just me, but I find GPS an active block to learning anything. With a map, one discovers where things are in relation to one another, with a GPS one follows instructions. Turn Left. Turn Right. Bear Left (Grrrr). Turn Around, You've Done It Wrong.

For me, the GPS is the "Wizard" of navigation. Fine if you only want to do it once, or you can't be bothered to think about it, but ultimately counter-productive and more expensive in terms of time sent learning to use the tool.

Live programming, to me, is more like fiddling with routes in with Google Maps; an aid to visualisation.

Not meant as an analogy. It was just an example...new technologies are never seen as training wheels to perfect the old way, they change the old way forever.

I agree that feedback isn't just training wheels and the goal isn't to do without it. The goal is to understand the structure of the state-space so that I can move though it intelligently.

As an example of what I mean by learning, suppose that I am designing an ecosystem for a simulationist game like Dwarf Fortress. I would like to understand the choices enough to make an interesting one. I start by making a plant and letting it spread across the landscape. Scrubbing the propagation rate variable lets me see how different rates of spread look. I can add an herbivore and now I can vary consumption rate, birth rate, starvation rate. I can scrub through them until I find a setting that is stable. Or better yet I can can work with the difference between propagation rate and consumption rate and the difference between birth rate and starvation rate, because these have a more direct relationship with the population dynamics. Since an ecosystem with only two species is boring I add a predator, but after playing around I see that it is too easy for it to either starve faster than it can catch prey, or to hunt the prey to extinction and then starve. Does limiting their maximum population density by making them very territorial help? No because when there are too few prey they still hunt them to extinction, and when there are more they only reduce the population by a constant factor. What if I made territoriality proportional to hunger?
As I add species it gets more and more complex; some species associations are stable (like grass and an herbivore that suppresses woody shrubs) and some are unstable.

What I mean by theory, is an understanding of the dynamics of this ecosystem and how each species changes them that is good enough that I can move it towards dynamics I like. It is more like a mental model than a hypothesis.

The reason I focus on learnability is because I want a way to quantify effort.
People unavoidably get expectations about what is going to happen next and learning is the process of making those expectations match reality. Every time I am surprised and those expectations are broken that indicates something that I don't understand. Broken expectations are unpleasant and stressful, so when something behaves in a way that it easier to learn I feel much less lost and more relaxed.

There is more to PL than just modularity. Think of editability as being orthogonal to and an unappreciated step sister of modularity and even composability.

Also, if we do figure out how to do this really well, where the code is even differentiable, then machine learning can more easily take over... We are really far away from that, so code modularity is still quite important. But its interesting to note what could make coding easier for humans would also make it easier for machines to code.

As for visualizing execution from a module perspective, that is a good idea, and is where Gilad Brach is going with his liveness work. But I think this makes state really difficult to work with, I mean, module execution is difficult to factor from program execution, and we spend much of our time at the top anyways debugging inter module interactions. To me, unit debugging is just testing a module with a smaller program. I wish there was a better story than that.

I've been revisiting Eros lately, and quite agree about tangible functional programming. As for type providers, code completion provides a different related type-directed search experience that I haven't been able to combine with scrubbing yet. But Repinning's conversational programming work definitely goes in that direction.