
Bret Victor – Inventing on Principle (2012) [video] - DyslexicAtheist
https://vimeo.com/36579366
======
Dangeranger
For those who want to see where Bret continued with these ideas, make sure to
check out his presentation "The Humane Representation of Thought"[0] and his
current research based on that talk "Dynamicland"[1] which is an in-person
programmable physical classroom based in Oakland, CA.

[0]
[http://worrydream.com/TheHumaneRepresentationOfThought/note....](http://worrydream.com/TheHumaneRepresentationOfThought/note.html)

[1] [https://dynamicland.org/](https://dynamicland.org/)

~~~
evv
DynamicLand seems awesome, but I'm afraid it will be forever irrelevant if
it's not open-sourced or launched as a consumer product.

Are there any open source implementations of DynamicLand, that I could
contribute to? If not, maybe I'll hack something together with JS and put it
on Github.

Brett Victor has been inspiring me with his talks for years, but I can't help
but wonder- when is he going to ship any of this awesome work!? His
innovations would be profound for our industry, its a shame to see them locked
away in closed research.

~~~
masukomi
Brett's a R&D guy. R&D guys don't ship consumer products. They find the future
paths and test if they're viable. Developing and maintaining a consumer
product is a completely different skillset and one that would greatly hamper
what he is best at if he tried to follow it. He's shown us what's possible and
much of what he's shown _has_ been shipped by other people. Look at the
playgrounds in Swift + XCode Those are totally based on ideas he put out in
his talks.

Don't ask our best creative thinkers to be slaves to retail viability, and
customer support. There are plenty of us who can manage that, but there are
very few Brett Victors in the world.

~~~
evv
I'm glad he has a research budget, I just wish his work was open source. The
fact that its not means that there is a huge barrier for anybody to actually
use these ideas. Most of us don't have a team of engineers that we can task
for a year to build something like Xcode playgrounds.

A fun opposite example, of somebody who hasn't invented anything in
particular, but solves real user's problems in an open-source, practical way?
Matt Mullenweg. Wordpress powers ~30% of sites on internet.

I'm not saying that Brett should be more like Matt. I'm saying that a little
bit of openness goes a long way.

~~~
jarmitage
To understand why Bret does not open source, you need to watch this talk from
his lab's ethnographer:
[https://www.youtube.com/watch?v=dweVuJBoK6o](https://www.youtube.com/watch?v=dweVuJBoK6o)

Money quote:

"In the CDG, prototypes work decidedly against usefulness. That's the mantra,
against usefulness. To be very clear, this being against usefulness is not the
being against usefulness of artists, who like to do their autonomy. It's also
not the grumbling hate of engineers who hate users, stupid users who don't
understand their products. The paradoxical reason for the need to avoid
usefulness is the experience that usefulness can stop the overall longer
process of bootstrapping. Yes, at the end of the process of bootstrapping,
products need to be shipped. But before this happened, usefulness is feared,
at least for many researchers in the CDG, as a trap. Once you produce useful
tools, they reify. Usefulness reacts to present users, and present users are
not the future users that the lab is working towards. Useful prototypes stop
being pointers of something larger, more long-term than what the prototype
achieves. Useful prototypes become a means to an end demand, too much
attention, become solutions, and maybe even are in danger of being turned into
opportunities."

Now whether you think your understanding of open source differs from Bret's is
an interesting question. But it seems like his is "throwing shit at the wall
to see what sticks is no way to reinvent a civilisation."

~~~
lomnakkus
A less charitable interpretation might be that many of these ideas are
actually not workable -- and never will be -- in the real world where you
can't just insert special cases whenever you need to. (I've seen this _sooooo_
often in research code.) It's also _not_ just a question of computing
resources.

<rant incoming, be warned>

I'll use the Mario example from one of his first widely disseminated talks as
an example: In the Mario example you see him run time backwards. That's
actually reasonably achievable by just recording all previous states or (more
plausibly) all state changes and then "just" replaying backwards. Then he runs
time forwards again after having changed a setting (or some such). This is,
again achievable within limits, see e.g. "rr".

The problem comes when he shows a _projected_ future path of Mario. Because of
a) Turing Completeness (TC) + the Halting problem, and b) the fact that much
code actually interacts with other systems which are _not_ able to just rewind
(and/or themselves interact with systems that ...).

The only plausible scenario in which this is even remotely possible in
practice is if the _programs_ adhere to strict rules about side effects, have
built-in "project into the future" (or have no side effects so that we can run
them to see what the results are _without affecting anything external_.). That
is, it's not about fancy IDEs -- it's about programming languages and turning
_away_ from Turing Completeness and/or non-abstract/non-formalized effects.
FRP/(React+Flux) _sort_ of work for this if you adhere strictly to purity, but
then again break down when it comes to things like "what is the focused
element" if the user clicks around when you're replaying.

I don't want to be a party-pooper, but good luck changing the programming
paradigm of _everyone_ to achieve this vision. For it to work _everything_ has
to work in this FRPish way, and that's just never going to happen -- for
example, networks (for real-world reasons) cannot behave this way, etc. etc. I
_WISH_ we could have everything behave this way, but we can't -- billions of
e.g. browser installations which have to have backward-compatible DOM
implementations and millions (billions?) of installations of C/C++-based
operating systems say so.

Now, I'm not against Imagining Things How They Could Be, but if there's
mathematical proof that "thing X" is not possible one either needs to explain
how you are not doing "thing X" (perhaps not using a TC language, or
disallowing non-pure state) or shut up. Brett Victor and many "visionaries"
like him are just very bad at stating their fundamental assumptions up front
(which is perhaps part of the reason we don't get to see the code, it's
probably just simple pure FRP-like code) so that we can evaluate the vision
_against_ the assumptions. (Light Table just seemed to assume that the
assumptions were plausible and see where that got them. Funded but with very
little actual technological advancement to show for it.)

... and also don't get me started on the whole "Kill Math" thing. Ugh.

(Sorry about the rantish nature of this -- I should probably just write this
up properly somewhere so I could properly flesh it out. I just get tired of
this "What A Genius!" and "Well, it would take too much time away from
_inspiration_ to actually _make_ the thing!" credulous nonsense.)

~~~
cmontella
I worked with Chris on Eve, which was the project he started after he hit a
wall with Light Table, that wall being the limitations of programming
languages you outline here. Eve did have strict no side effects requirements,
and did have the ability to log and rewind programs. The bulk of our work was
in nailing down a good set of semantics, and also in figuring out a good way
to present those semantics to users (syntax, UI, etc.).

After writing countless programs in this style, which is very different from
conventional programming, I have to say the Mario example is a nice demo, but
in reality we didn't find time-travel useful in scenarios like that. What was
infinitely useful though, was being able to trace the provenance of different
values in your program for debugging. Since we kept information around that
the compiler usually throws away, we could tell you exactly how a value or UI
element was calculated, and give you tools for interacting with that history
that just aren't possible in other languages. For instance, you could
encounter a bug, pack up the state of your session, send that over to another
dev, and he/she would see exactly the environment in which your code was
executing.

You bring up the good point that not everything is written in this way, and so
interacting with external code can be tricky. For example, you might have some
code that sends out an email every time the system memory reaches a threshold.
Now, you might get an e-mail you didn't expect, but you could go back and see
exactly why that email was sent, and deduce the bug through the provenance
tree.

As I said earlier, after writing programs in this style for 3 years, I'm
utterly convinced we won't be programming in the future the way we program
today. There were versions of Eve where we wrote very complex applications,
from webapps to robotics, that didn't even feel like programming -- it felt
more like forming a shape out of clay, where the clay in this case is a
digital "material".

In the end, Eve couldn't get more funding because it wasn't a venture that was
really set up to fit into the VC mold (and I'm still not sure how Chris and
Rob convinced VCs to fund them in the first place), but I'm absolutely sure
the current way of doing things will fade with time. It's going to take a lot
more research and a lot more convincing, because there are a lot of people out
there that for some reason don't want to see projects like this work, but as
someone who went down the rabbit hole and gotten a glimpse of this future, I
really just can't fathom how humans could be working with languages held back
with so much baggage from the early days of computing in the year 2100 for
example.

I'm curious though, why you suggest for a language to work like this you have
to abandon Turing Completeness. This wasn't my experience at all, and we
implemented a Turing Machine in Eve just to prove we were TC
([http://incidentalcomplexity.com/2014/12/01/nov/](http://incidentalcomplexity.com/2014/12/01/nov/)).

~~~
lomnakkus
I think we agree that FRP-ish is the way of most of the future, but it _must_
integrate well into the existing ecosystem. Which basically means no
"projection into the future" and no "fast-forward". I think side effects are
unavoidable for all practical purposes -- the trick is how to integrate them
cleanly, if that's even possible. Even being able to trace backward would be a
huge achievement for most of the programming world. To be clear, it's about
80% achievable right now by just programming your whole application in the FRP
style until you reach the "transactional" or "IO" boundary.... Btw, it's not a
coincidence that this sounds similar to CQRS/Event Sourcing and Bounded
Contexts from DDD. I think CQRS/ES approach has an advantage in that it
"realizes" that there's such a thing as "oops, I wrongly charged customer X
for item Y, let's refund that". Plus, it's it's basically what we do in the
real world, e.g. in banking.

It's obviously not enough to be able to "project into the future", but it's
pretty awesome for looking at what happened. It's also a great way to maintain
discipline for your code -- we're already off on a wild tangent here, so I
won't elaborate.

> I'm curious though, why you suggest for a language to work like this you
> have to abandon Turing Completeness

You don't necessarily have to, as long as you a) assume complete purity (as in
e.g. Haskell's ST monad), and b) are resigned to having to actually run _all_
the computations when running "forward".

Keep in mind that some of those computations may be EXPTIME... but as long as
you can interrupt them, then I suppose that's OK.

I think the conclusion is that anything TC that doesn't do side-effects would
basically be OK (as in: not actively wrong), but not necessarily practical in
our lifetime. Timeouts might work here, actually.

~~~
jecel
It isn't clear to me what the problem with projecting into the future is. You
just simulate the system or just let it execute normally (but under the
control of some kind of "harness"). This will give you the correct result up
to the point where some user input (missing in this simulation or execution)
would have changed the behaviour.

~~~
lomnakkus
> You just simulate the system or just let it execute normally (but under the
> control of some kind of "harness")

"Simulate the system" means "execute normally" for all practical purposes.
That's what TC + Halting Problem[1] essentially boils down to, absent other
knowledge about the program. Hence my suggestion to let the program itself do
"projection" because it could potentially be hugely more efficient, and
_possible_ (but perhaps with bad "fidelity" in the case of side-effecting
computation).

Anyway... to the larger point and to expound a little:

If everything is _pure_ , then there's basically no problem (except
computational cost), but imagine our Mario is taking part in a multiplayer
game.

What do you think should happen?

(Obviously, this is not realistic for the reason that you usally don't run
"debuggers" or "IDEs" in a 'multiplayer' scenario, but I think the analogy
holds in general. Imagine that the other players' actions are I/O operations
like "what's the current time?" or "talk to a REST service", etc.)

Most interesting programs do this kind of thing _all_ the time. Of course,
there _are_ interesting programs/functions which are purely algorithmic and
rewind/fast-forward should work for them, but they are mostly pretty niche
compared to most of the programming that currently happening.

A very interesting example that's somewhere "in between" is Haskell's STM
monad which does have _very_ controlled side effects and where you can just
"retry" and particular computation in case synchronization fails, but it still
doesn't allow you to "project".

[1] Alright, I suppose it's just undeciability for non-trivial properties of
TCs languages, but Halting Problem is a convenient shorthand.

------
rayalez
Relevant to this video, if you haven't heard, there's a new programming
language called Luna(currently in beta), designed based on these principles.

[http://www.luna-lang.org/](http://www.luna-lang.org/)

[https://www.reddit.com/r/LunaLang/](https://www.reddit.com/r/LunaLang/)

Really exciting stuff.

~~~
filoeleven
Oh, sweet, they finally released the beta! After the last time Luna appeared
on HN, I kept checking their site for activity since they said they’d be
updating soon, but forgot about them after a few months. Now there’s something
we can actually play with!

This is probably worth submitting to HN again in order to alert people of the
beta; there was a fair amount of interest before and I’m sure I’m not the only
one to have missed the announcement on their site.

------
vanderZwan
I often have moments where I go _" I can't believe that was N years old
already"_ \- where currently _N_ is usually around 15 +/\- 5 years for me.
This is the opposite: it feels weird that this video is only six years old! It
has had such an impact on my life, my way of thinking and also my career (I
studied IxD just around the same time), that it feels like it's been around
forever.

------
bramjans
Great stuff, like all of Bret Victor's talks. My favourite: is "The Future of
Programming (2013)": [https://vimeo.com/71278954](https://vimeo.com/71278954)

(I also liked this satirical blog post about that talk:
[http://alarmingdevelopment.org/?p=797](http://alarmingdevelopment.org/?p=797))

------
steveeq1
Bret Victor's reading list, for anyone that's interested:
[http://worrydream.com/#!/Links](http://worrydream.com/#!/Links)

------
0xcb0
In my opinion, this is an excellent presentation. I've watched this video in
2012 and have recommended it to a lot of people. Even though not many people
will be able to use these tips on a daily basis, it's a "must watch" in my
eyes. So inspiring and fun to watch. Watch it, when you have time! :)

------
ninjamayo
Wish we could see more software being developed like Bret does it. Been
looking for years and still haven’t encountered anything with that degree of
freedom and flexibility. His platform game demo is amazing!

------
beautifulfreak
Isn't it about time for Bret to be noticed by the MacArthur Foundation?

