HN Theater

The best talks and videos of Hacker News.

Hacker News Comments on
Bret Victor - Inventing on Principle

CUSEC · Vimeo · 412 HN points · 153 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention CUSEC's video "Bret Victor - Inventing on Principle".
Vimeo Summary
Bio: Bret Victor invents tools that enable people to understand and create. He has designed experimental UI concepts at Apple, interactive data graphics for Al Gore, and musical instruments at Alesis.

For more on Bret, see

This talk was given at CUSEC 2012 (
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
Dec 25, 2020 · pasiaj on Working at Apple (2011)
Sure, but I recommend you take a closer look.

His articles, for me at least, are the most influential ones on how I think about creation and solving hard problems.

Here's a couple

Up & Down the Ladder of Abstraction

Inventing on Principle:

Damn straight. Good stuff. I have some reading to do...
He gives some amazing talks, too. The Future of Programming is well worth a watch.

That's only true if you don't consider the context that the code lives in. For example coloration in editors could be considered a visualization of additional dimensions of info (syntax, types) and autocompletes are like a branching "time-like" dimension. Besides that code mostly tries to solve problems that can be represented and show visually.

The need exists, how to turn that into a solution with a useable interface that I'd use for multiple hours a day is beyond me though.

For me Bret Victor's talks point to this problem where we treat code as something we only interact with as text but it can be so much more:

One of the last links, but probably most significant:

Inventing on Principle

> There are only a few code bases out there that are massive enough that compilation time on a modern machine is a major impediment to productivity.

Depends upon what you mean by "major impediment to productivity". I think someone like Bret Victor would argue that if your feedback loop is greater than a couple of seconds, you're toast.

From that perspective, _the majority_ of _all_ codebases are an impediment to productivity.

For me, the most life-changing idea I've been exposed to continues to be from Bret Victor's¹ 2012 talk titled "Inventing on Principle"². The idea is that in addition to the two well-known paths to live one's life, there is also a third, less well-known path.



Apr 10, 2020 · 2 points, 0 comments · submitted by sohlis
Feb 19, 2020 · mc3 on Larry Tesler Has Died
I'm bad at names, so I didn't know the name, but followed the Wikipedia link and saw he was the "modeless" advocate, and I learned about that from this awesome Bret Victor talk: Someone has commented to forward to 38 minutes to hear it.

That Bret Victor talk still influences me today, so please watch it I think it'll help you if you haven't watched it already.

Software development is the BTD loop; you can't eliminate it. I got my start with Logo[1], which has an amazing BTD loop! People like Bret Victor[2] have talked at length about it (although Victor doesn't use that term, IIRC). Even the trend toward "notebook programming" - Jupyter, Observable, etc are really about shortening that loop. A major reason to use an IDE is to potentially shorten the BTD loop. Lots and lots of tools exist specifically to shorten this loop.

And yet some organizations want to run all the linters, all the tests, for all the languages, orchestrated by Jenkins on a huge Amazon cluster. This is bad.

[1] This is very cool - an Apple IIe emulator running Logo in the browser.

[2] Inventing on Principle has improving the BTD loop at its core

Well, I don't see how linters/test on a final cluster is bad. This is why we have unit/integration/alpha/canary tests. The first 1 can happen on my laptop over 5 seconds while the second can happen on my personal instance over 20 minutes. Usually first means the second will pass and I just need to run it in the background without breaking any workflows.

i.e. It might not be a bad feedback loop, you just need more of them that are faster.

5 seconds is already painful, the point of the other poster is to delay that stuff until the end. When the BTD loop is long it's a looooooot harder to get into the flow, and you have difficult really thinking about the problem.

Imagine trying to read a novel but after every paragraph you had to stop and wait for 5-10 seconds.

This looks really great!

A somewhat related video that your docs reminded me of, "Bret Victor - Inventing on Principle" [], which I think is a really interesting take on inventing and learning. Perhaps some useful thoughts for your principles section.


Jan 18, 2020 · chrisweekly on Worrydream Refs
That seems pretty harsh. Some of his ideas have been hugely influential -- and practical. Like you, I'm unimpressed w an unencrypted page simply listing PDFs, but I do admire the "idea guy" himself - Bret Victor - for things like "Inventing on Principle" ^1 and "Up and down the ladder of abstraction" ^2



I think it was Inventing on Principle that got HN all wet in their knickers. Literally nothing of any practical value has come of it. Someone started a kickstarter/company for Lisp IDE (getting HN wet all again) based on some of these ideas. They failed. These ideas are not workable, sadly. (I really want a world where they are, but they aren't.)

(Btw, 'rr' was already a thing, at least AFAIK.)

EDIT: For the downvoters (not that I care): Name a single thing that came of it. Seriously.

EDIT#2: This whole argument could be over soo soon... give me an example. C'mon people! (I find it funny that I'm usually deemed too idealistic for choosing Haskell...)

The influence of “out there” thinking like this is pretty hard to spot if you’re looking for a direct descendent. His talk on interactive computing has affected the way that I personally design and build products, so there you go. I’m sure the same is true for many others.

This is like complaining that concept cars are bullshit because you haven’t seen a car that looks like one on Main St in Podunk, USA.

As a sidenote, the “wet in the knickers” language and overall tone of these comments is extremely juvenile if you’re actually trying to have a good faith conversation about this.

>I think it was Inventing on Principle that got HN all wet in their knickers. Literally nothing of any practical value has come of it. (...) EDIT: For the downvoters (not that I care): Name a single thing that came of it. Seriously.

Swift Playgrounds is obviously inspired by it, parts of which later made it into XCode proper [1]. Criss Lattner: "Playgrounds were heavily influenced by Bret Victor's ideas, by Light Table and by many other interactive systems."

Now, I guess, to not admit defeat (which was previously premised on nothing of any practical value having come out of Inventing on Pricinple) your next step would be to belittle Swift Playgrounds as having no practical value.

Not to mention that "what came of it" is hardly the best criterium to judge an idea.

For one, our industry is not exactly the best at adopting things, or being driven by ideas and innovation. Corporate wise it's mostly about selling snake oil, reinventing BS and making 3Ghz/32GB computers feel slower than Pentiums with bloat...

Second, because inspiration can take many forms, aside from direct implementation of the original idea. E.g. while Lighttable and Swift Playgrounds/XCode Playgrounds are based heavily on the program shown in the presentation, the presentation has wider ideas that go beyond the exact program shown (which is just an example to make the point).

As such, it has already inspired many UI designers, and many UI choices, and many have admitted so - even if they don't make the same kind of programming environment.

>They failed. These ideas are not workable, sadly. (I really want a world where they are, but they aren't.)

Your comments don't make it like one who cares either way, they're mostly about putting down the "idea man" (how does one dare have ideas, and even worse non-practical ones? The gal! We should all be working on practical things, like the nth CRUD apps, some Electron UI, a Go/Rust rewrite of some backend service, etc).


Just FYI, your comment appears to be a response to the parent of my comment, not to me :). Agreed on all points!
Yes, exactly! Sorry for attaching it to yours, the parent comment didn't have a way to reply directly (perhaps banned?)
Jan 08, 2020 · 1 points, 0 comments · submitted by ladybro
Brett victors talk innovating on principal( and more so actually Greg Wilsons talk from the same conf ( marked a pivotal moment for me in my work ethic. It really motivated me to expect better from the tools i use around every day.
Similar rxn to those talks. Also, if ever someone knew how to write an "evergreen" post (ie, one that holds up over time), it's Bret Victor.

His "Ladder of Abstractions" is a great example:!2/LadderOfAbstraction

I really enjoy his writing, but I think he has a way to go before he's in the same league as Homer, Plato, Lao Tse, and Shakespeare!
haha, those guys sure knew how to write a good blog post!
Yup! They got people still clicking on their posts hundreds or even thousands of years later
Also his essay Magic Ink:
Sep 12, 2019 · 2 points, 0 comments · submitted by tosh
May 05, 2019 · 1 points, 0 comments · submitted by jger15
So - watch Inventing by Principle, work out exactly what your principle is, and change the world. Good luck!

Oct 21, 2018 · yesenadam on Ask HN: Now what?
...Maybe Bret Victor's Inventing on Principle will give you some ideas/a new angle on life.

Bret Victor talks are inspirational:

- Inventing on Principal

- Stop Drawing Dead Fish

Fully agree. You forgot one!

Brev Victor - The Future Of Programming

on one level, yes

on another, they're down right scary and overwhelming, or at least dumbfounding and perplexing

..thinking specifically about The Humane Representation of Thought I had to stop it half way through.. :-/

see also Seeing Spaces and Media for Thinking the Unthinkable

Yep, I thought Inventing on Principle was the best computer-related talk I've ever watched. Not easy to describe what it's about! Design, tools, art, UI, visualization, invention, life.
It's like he has caught on to a kind of a zen thing. It is almost as if he isn't even there, while presenting about a technological topic at all. That is just the media for him to get an expanded wisdom across. What that message is is hard to identify. But there is a glance of it at the end of inventing on principle. It's a lot more profound than what the talk seems to be at the surface.

I really wish he would publish more frequently He has inspired me greatly.

Yeah, I was marvelling half the time at the wisdom, it makes other speakers seem merely knowedgeable, clever, brilliant etc. I missed most of it in my summary before. I love the

this is a cool way to live your life, according to some principle - this is mine; these are some other amazing people who had their own

aspect of it. His creators should be able to see and control what they're doing as they do it principle is awesome, and he's maybe uniquely well-equipped to do something about that. I wanna get the synth he designed!

What's the synth?
Alesis Ion, Micron and Fusion

what is curious to me is that that synth is famous for being extremely unfriendly to program. its usability is pretty bad and goes against many of his principles. i love bret victor's thinking and work since he became independent though.
Thank you! I hadn't seen these before. Great stuff.

Inventing on principle:

Watch the future of computing from him as well.

It is set in the world of computing before UNIX was out of Bell Labs.

Thanks. I will be watching all his stuff. I hadn't watched Inventing on principle when I commented before...I came back to say - I think it's the best tech-related talk I've ever seen. Well, so much wider than just computers or programming--although mainly about that on one level--but it's about one's life, purpose, meaning in life etc. The first computery talk I've seen that seemed wise, strikingly so, not just smart, clever, cool, brilliant, innovative etc. Thank you HN!
Sep 30, 2018 · melling on Questions
All 15 of them?

The market has spoken, programmers want free stuff, and they’re happy doing it the old fashioned way.

Except for those who aren’t content:

[Insert videos from Bret Victor here]

Lighttable is another attempt that comes to mind:

From my direct, personal, experience, it goes something like this:

"Don't you want better tools?" I'll ask

"Of course!" the programmer replies (note sometimes this is a conversation with myself) "but I don't want to pay anything for it" they caveat.

"That's no problem," I reply, "as long as it will make your life better."

"Well, that sounds good, but I also don't want to have to learn anything new."


"Also, it has to just work from day one, if it doesn't quite work as soon as I touch it, I'll swear off it forever and go talk badly about it on twitter and hacker news."


"Also, it has to work with every use case I can think of. Multi-threaded, GUI, deployed to HPC clusters running RHEL6 and also Docker containers running CoreOS, and it should be able to help me be productive in either JavaScript or s390 assembler. Also it should take no time to set up, and start giving me answers straightaway."


"You know what, the methods I already have already satisfy all of these requirements and as a bonus, I don't have to learn anything new in order to use them. I spend enough time learning new frameworks to write software, why would I spend more time learning frameworks to debug software?"

"Because you spend more time debugging software than writing software?"

"Honestly the process of debugging, and the process of writing, have become so intertwined in my thinking, that distinction between them seems arbitrary and pointless."

"Thanks for your time."

This is a really cool project, and reminds me of Bret Victor's Inventing On Principle[0] talk--which makes sense, because Glen has worked with Bret on Dynamicland.

These tools are made for beginners, but even though I'm not a beginner, I wish I could use these kinds of tools within my existing coding workflow. But I just can't use an editor/debugger that requires a mouse anymore.


OP was saying that code > UI "for developpers". Something like one of Brett Victor's UI[0] integrated in GIMP would be quite nice for a dev who can draw, or a painter who can code.

[0] (circa 3 min. mark)

Bret Victor - Inventing on principle

Alan Kay - Power of Simplicity

Steve Jobs - Marketing (unveiling Think Different)

Robert Cialdini - On Influence

Peter Thiel - On Zero to One (Notes on Starts Ups or How to Build the Future)

Naval Ravikant on Reading, Happiness, Systems for Decision Making, Habits, Honesty and More (Farnam Street podcast)

Josh Wolfe - On "This is who you are up against" podcast

Richard Feynman - Fun to Imagine

Paul Graham - Startup school (2008)

James Burke - Connections (BBC documentary)

<No link>

Jim Al-Khalili tells the story of the Atom (BBC)

Elon Musk's 2003 Stanford University Entrepreneurial Thought Leaders Lecture

Ken Robinson - Do schools kill creativity?

Paul Stamets on mycology, bioremediation and fungi- Joe Rogan Experience

Fantastic list!
Inventing On Principle - Bret Victor

Came here for this. My favorite talk of all time. Easily had the most impact on my career.
So glad someone posted this. Basically everything Bret Victor does is gold. His website [1] has a bunch of great things he's written/done; two of my favorites are The Ladder of Abstraction [2] and Learnable Programming [3].




Apr 14, 2018 · richardburton on Notes on Resonance
I have watched this talk from Bret Victor at least once a year to help me think about what to work on:

Inventing on Principle

> Thanks to the Eve team: Chris Granger, Corey Montella, Josh Cole, and Jamie Brandon. You were an inspiration.

And I hope they continue to be! The ideas that Eve made concrete are too good not to carry forward in the design of future languages. It wasn't just the literate/logical programming paradigms, atypical of popular languages in production today, that made Even stand out: it was the idea (really, the sort of moral imperative) that as you make changes to the code, you should be able to see the effects of those changes in real time.

It's worth pointing out that Light Table, sort of the precursor to Eve, was pretty much directly inspired by Bret Victor's talk "Inventing on Principle." [0] I'd encourage anyone who hasn't seen Bret's work to go check out that, and all his talks really. :)


I should note that Eric Hoffman also was part of the team for a year.
Added, thanks!
Don't forget Rob Attorri! He wasn't an engineer, but he was there from day one (cofounded with Chris)!
Added, thanks!
Just yesterday I offered "So Good They Can't Ignore You" to someone about to start their professional career. Mostly as a counterweight to the mainstream advice.

I recommend watching Bret Victor's "Inventing on Principle" [0] for a very interesting variant on the theme of "your mission in life & work".


Feb 06, 2018 · 127 points, 27 comments · submitted by DyslexicAtheist
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.

Really exciting stuff.

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.

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.
Great stuff, like all of Bret Victor's talks. My favourite: is "The Future of Programming (2013)":

(I also liked this satirical blog post about that talk:

Bret Victor's reading list, for anyone that's interested:!/Links
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! :)
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!
Isn't it about time for Bret to be noticed by the MacArthur Foundation?
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.



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.

Much of the work at the DynamicLand is in the same vein as Mike Eisenberg's Post-PC/Craft Technology Lab[1]

Similar to the MIT Media Lab (Mike is an alum) much of the research focuses on physical computational interfaces beyond the traditional screen/keyboard model - i.e. how can we collaboratively 'compute' things with real physical objects around us. Or put another way, what does computing look like when everything is a computer. Some other projects to come out of there are the Lilypad Arduino, a project similar to DynamicLand called SHALE, and Lockitron.


Alex Warth of HARC has a new Dynamicland-inspired repo called roomdb
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.

Honestly, I'd be happy if it were just open sourced with a heavy disclaimer about not being able to support users.

If you see a piece of technology and have an idea you want to try, with an open system you can just get the source code and try it. With a closed system, the answer is "first, rewrite it from scratch..."

its likely that its completely unusable off the machine thats running it and that there the author can't run it a month later (like grad student work)

I guess you could argue that devoted interested parties would invest the time to tease out all the dependencies, get it integrated in common packaging systems, and spend some time debugging it.

if you had an even slightly more devoted person they could make a production system using the demo as an inspiration. I don't know Bret personally, but he'd probably be likely to engage with that person and give feedback and advice.

>its likely that its completely unusable off the machine thats running it and that there the author can't run it a month later (like grad student work)

That's possible, yeah. But I bet there are a lot of real-world lessons they learned in the process of building Realtalk (and previously Hypercard in the World) that wouldn't necessarily be apparent from a demo.

For that matter, we don't even really know what the user experience is like - most of the pictures I've seen aren't high-res enough to see what the code looks like. Even if they're open to tours (which it sounds like they might be), I live on the other side of the country.

I'm sure talking to Bret personally would be illuminating in that regard, but reading through the code and commit history can be illuminating in similar ways (doubly so if the authors were diligent about documenting things). Heck, even documentation on how to use Realtalk would be nice!

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.

To understand why Bret does not open source, you need to watch this talk from his lab's ethnographer:

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."

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.)

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 (

I was following closely LightTable and EVE. Very inspiring projects.

> that wall being the limitations of programming languages you outline here

Exactly. I was thinking about the same a while ago. EVE is an attempt to build a new reality where those limitations are gone. But it didn't work quite well -- in order to get support, money, users it should be somehow connected to production.

There is a platform where all this complexety with IO (the mail send in your example) is abstracted quite nicely and can be manipulated/mocked: the BEAM platform (Erlang, Elixir).

You can record IO for particular process (it just messages), replay it if you want.

Also, modules can be compiled in any order, functions in module can be defined in any order. It's much easier to treat function as smallest unit of code. To create a parser that could transform code into data, allow it to manipulate (structured editing and all) and transform it back to text form, to be used by other programmers.

I think if LightTable was aiming at BEAM platform it could go a bit further. Utilize growing popularity of Elixir, and create a new development platform.

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.

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.
> 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.

Do you think it might be possible to integrate non-FRP style programs (basically stateful, imperative style) by running them in a VM which can isolate the effects and snapshot/restore the entire system state? In theory at least, it seems something like a web browser could rewind the state of a web app and replay with different input.
Snapshots/diffs are not enough to be able to "project into the future".

In the web browser this is mostly achievable if the whole app is programmed in a very strict React/Redux style where everything the React portion is handled through props. (Focus being an exception that seems just untamed, so far. I may very well have missed developments here.)

I can confirm that dealing with focus in react hasn't really advanced. There's useful libraries for working around this like react-hotkeys but that's about it.
Jan 18, 2018 · etanol on Microsoft MakeCode
I didn't take a deep look, but it reminds me to Bret Victor's proposal on "Inventing on Principle" from 2012:

Five years after Bret Victor's Inventing on Principle[1], it's crazy that there are not more coding environments that give new users a great out of the box experience with live reloading like this.

I started learning Clojure recently and had a bad experience configuring a development environment on the Mac. Leiningen threw “illegal reflective access” and “Unable to open cgroup memory limit” warnings that appeared to be related to an incompatible version of the JRE. I ended up fixing it (JRE downgrade, then upgrade after it was patched in Leiningen), but it was still a less than smooth introduction to a functional language compared with Elm, Elixir, or even Haskell.

The advice from many Clojurians to use Emacs is fine if you happen to use it anyway, but also seems particularly hostile to beginners.

Lightmod compiled all the demo examples without error for me.

I really want to explore Clojure and ClojureScript to build game servers and web games, and this project looks like a great way to get people using the language faster.


FWIW, if you're on a Mac, the absolute fastest way to get Clojure/script going for exploration purposes is to use Planck, which is a CLJS REPL with a few batteries included, built on JavaScriptCore. (There's also Lumo, built on top of Node, and I think there might be a Linux port of Planck, FWIW.) It's seamless, and I actually use it for a lot of the same scripting tasks that one might use Python for.
I hadn't heard of Planck (I know it as an ortholinear keyboard!) or Lumo. Thank you for taking the time to mention them both – downloading to play with now…
I ran into that bug too. It's the first bug that I've encountered with Leiningen after using it for more than five years. Sorry that that was your first experience with the toolset, but it's far from the normal experience.

Also, if you're happy using an editor other than Emacs, then go for it. I use it but only because I've been using it for quite some time, and other than the fact that I like the way emacs indents Clojure source there's nothing special about it in the way that I use it. Visual Code has nice support for the language so that's a good option if it's more up your alley.

One area where I see Lightmod being really helpful is setting up the initial project. Learning what's going on w/cljsbuild, figwheel and then how to combine that with Clojure in the same project file isn't the simplest thing in the world to say the least.

Thanks for the tips and reassurance – it's good to hear that using Visual Code is acceptable; it's what I'm more comfortable in, and I'll persevere with it!
You might also try Cursive[0], a full-featured plug-in for IntelliJ. You can use it free until you so something pro, after which it's about a hundred bucks. Many of the more well-known Clojurists seem to use it.

I believe that with Clojure, you owe it to yourself to have a first-class REPL.

I mostly use Emacs, but yeah, rabbit hole...


It would be really useful if VSC supported the Emacs indentation style: it’s what most people use in real Clojure code.

Paredit would be brilliant too ( if you’re not familiar)

It looks like there's an extension for paredit, but not sure how it compares to Emacs:

For formatting, I've been using this, which supports cljfmt:

And the rainbow brackets extension has made code more legible while I've been learning:

Oct 30, 2017 · 2 points, 0 comments · submitted by lucb1e
I find the jab at Bret Victor especially undeserved. He's an interaction designer (a really good one who sees through all the fads[0], which is kind of the opposite of what this one-liner implies). His focus is on better interface design, not formal language design; why criticize someone for something they're not trying to do?

And it's not useless; we probably wouldn't have had Elm without Bret Victor's Inventing on Principle[1][2]. And there has been some progress in that direction of interface design of, for a lack of a better term, "programmable environments": look at Apparatus, for example[3]. Where would you even fit that on these slides?





Quite true. I find likely that the next revolution in programming languages will come from designing a PL that's a good fit for these programmable environments. Maybe it should break from current undisputed conventions like the radical separation between "data" and "source code", and be more like a spreadsheet.

End-User Development has lots of under-explored ideas on how to build software automatisms that don't require the end user to learn a hard formalism (even if such formalism exists as the basis for the system). Though I understand that programming language theorists are not interested in that angle of the evolution of PLs.

There is a dichotomy between sealed programs and evolving programs. Evolving programs like Smalltalk or REPLs are great for exploratory work. Almost everyone wants sealed programs for systems to work reliably. This runs along the lines of Ousterhout's dichotomy as well - scripting vs systems languages.

The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application.

IMO, TDD and BDD could be seen as attempts to do exactly this.

> The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application.

Yeah, I see that as a likely evolution as well.

In some ways, an IDE is already an exploratory system with a focus on delivering a sealed system - the final compiled software represented by the source code. I believe this combination is what made IDEs so successful and universally desirable, and future programmable environments should share these traits.

Auto-completion, refactoring and code-browsing tools support the exploratory work. The problem is that IDEs are not so good at exploration as a REPL because they're unable to store intermediate results and states. TDD could then be seen as an ad-hoc way to store such intermediate state.

Agree on the benefits of IDEs and REPLs. An IDE/language with integrated notebook-style REPLs might be useful too. Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact.

The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes - instead of only showing what is directly modified (i.e. a line of code) and leaving the simulation up to the human.

> Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact.

Yes, exactly. You get that with a REPL (e.g. Lisp or Python) and copy-pasting to the source code files, but it's far from ideal.

> The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes

So, sort like explorable explanations[1][2], but aimed at developing a new model and not just exploring one that has been already made? That's what I'd like to see, too.



Yes, somewhat like these, but having the ability to inspect and simulate effects on intermediate forms and systems. So something along the lines of light table but being able to show more than just the immediate program.

Copying something I wrote in another thread: I want to see not just the immediate program I'm manipulating (text or otherwise) but also the implications - the affected parts of various other intermediate representations all the way to the running, live system that will be affected.

Do you see this as a useful dichotomy? In reality no system is truly sealed - it's just temporarily sealed between evolution steps, no?
I do find it a useful dichotomy because I work with people who evolve their code and wonder why I get my back up about monkey patching (because it's often my job to turn research or prototype quality code into reliable code).

If you've ever had to make another person's research or prototype quality code more robust it can be easy to wonder how on Earth they work the way they do. Having this dichotomy in mind makes it easier to have more sympathy.

It works both ways. Researchers need to understand why platform development moves so slow. This dichotomy helps reason about it.

But you're right, between evolution steps the system is not sealed. That's a concern and why projects like Debian are keen to have reproducible builds. It's also a big part of why containerization is becoming so popular.

Ah I see. So with 'sealed' you mean things like reproducible builds and being able to determine the exact set of sources, etc?

The containerization movement is interesting - while having these 'sealed' virtual environments and reproducible system builds is the right direction, I'm amazed at the size and weight of each of these.

Sure. By sealed I mean you compiled the program, you might have a turing incomplete configuration (e.g. ini, toml, json) and you can reason about the program. And by evolving (or, I guess unsealed) you are in the process of editing the program. Or you monkey patch it when you run it.

But with things like LD_PRELOAD, different .so minor versions, etc, a compiled program suddenly straddles the categories. Hence my comment about reproducible builds and containerization.

Aug 27, 2017 · 1 points, 0 comments · submitted by ntumlin
Aug 20, 2017 · beagle3 on “What next?”
> How do you do this with a text driven program?

If you haven't watched , I highly recommend it. Chris Granger, after watching this, created which you can download, and applies to ClojureScript, which is (tada!) text based.

Also, I had a chance to use time traveling virtual machine (which works independently of how your code was produced) in 2007, and while I haven't had a chance to use them, I know that source-aware time traveling debuggers have made huge strides recently.

> So you claim there is no benefit to be had. I claim the existing solutions are already failing.

These claims are not contradictory. I agree that existing solutions are failing in various ways, but I still disagree that the "code as rich data" would provide benefit.

> If one solution gets enough of these things right, there is no reason why it wouldn't succeed just because text-driven. (But it is also possible to do it correctly with text)

So, if possible to do correctly when text driven, why is text driven a problem?

> If the program code is always to be consistent, it cannot be text, because text allows you to input invalid programs. So how is text not a leaky abstraction?

All programming abstractions are leaky in one way or another, and text is no different. In my opinion, the leak that it is possible, during design time, to have an invalid program (which will be rejected as such prior to execution) is not a real problem. The requirement that "program code always be consistent" is onerous, and, in my opinion, harmful.

When I write code, I often start with sketches that cannot work and cannot compile while I think things through, and then mold them into working code. Think about it as converting comments to code. If an editor didn't let me do that (and likely wouldn't provide any help, because I'm writing comment prose and not "rich data" code ...), I'd open a text editor to write my plans. text editor.

I will restate my belief in a different way: Any benefit from "code as data" that cannot be applied to a textual representation, only ever manifests in extremely simple cases. I offer as support for this belief, the history of visual and rich data tools over the last 30 years, none of which manages to scale as well as text based processes, most of them scaling significantly worse (which is often explained away by critical mass, but there are enough successful niche tools that I think this explanation is unacceptable).

For those who haven't seen Bret Victor's incredible Inventing on Principle - I think you'd like this talk if you enjoyed Alan's:
You need a visual interface with knobs. Not text. This guy needs to see more Bret Victor!

Text is a visual interface, if you look really closely you can see each letter is actually a little picture.

Can you use text to move a slider?

(FWIW I have watched and enjoyed all Bret Victor's videos, and am looking forward to his big reveal. I've also experimented with visual front-ends to tidalcycles, so agree with you to some extent.. But text is really good for describing pattern.)
Some feedback on the website: IMO, it's obnoxious and disrespectful to play full screen video like you're doing. That just made me close it immediately and leave after reading through the text.

Considering the complexity involved in developing a an advanced IDE or similar, have you considered publishing an open source community version? Similar to JetBrain with IntelliJ. They seem to be doing great.

Since we're on the subject of experimental UI concepts, I'll plug Bret Victor's Inventing on Principle [0] talk. For me it was an instant classic.


Why does EVERYTHING have to be opensource these days to be considered acceptable?
So that companies which haven't made any contributions to the code or its development can profit from it, presumably.
Because too many projects fail or get abandoned and I will not invest in a project that may not exist next week.
If you look at the existing retail software market versus the open source market you'll quickly see that retail is obviously the better choice for a company in terms of product life and revenue. I mean the biggest companies in the world got to their positions by offering software to feel a market need. Apple, Google, Microsoft, Amazon, Ebay all the big tech giants, as well as the newer player like Facebook, Uber, AirBnB and just about everyone else who is making money has done so through selling limited access to their software. Sure some of those might offer open source products, but they never make money or have much value.

Open source software is important to our society because it helps people learn, but it doesn't have an impact on the real world where money runs things.

People who want everything to be open source tend to just want it for their own personal benefit and 95% of them don't contribute to that community either, they just like having something to complain about.

Because with open source software:

- You can run the program as you wish, for any purpose.

- You can study how the program works, and change it so it does what you want.

- You can redistribute unmodified copies without fear of the publiher suing you.

- You can distribute copies of your modified versions to others without fear of the publiher suing you.

Who wouldn't want to have all that in a tool that will be the basis for your own projects?

But what if you write it?

I'm happy with non-commercial use (including providing the source), but if someone wants to make money from software I write, it's only fair that they should pay me, and under the open source model they don't have to, and usually they won't.

That argument is convenient for you, but how is it convenient for the people using your code?
The only people who would be inconvenienced by it are those who can make money out of it. Anyone who agrees not to use it commercially can still receive it, source included, gratis, when it's ready for release.

If a commercial user likes my software they can pay for it or hire me. (I'm available). Is that too much to ask?

But what if:

1) you become unavailable?

2) you don't have the physical capacity to develop everything that the client needs?

3) you don't want to implement some feature that the user needs, for reasons? (related to the software architecture, or the direction you want the project to take, or whatever).

Open source gives the commercial client the flexibility to adapt the code to their uses, in a way that being tied to a single provider will never achieve.

Why do you think companies should have software developed for them by third parties for free?

If they pay for it, they'd have the source, and would be able to modify it for their own needs but not release it.

Who said development should be free? Paying the person who knows the software most in the world to taylor it to your needs makes all the sense. Paying for copy, in a world where making digital copies is essentially free, does not.

But having access to the source, without permission to modify it nor a perpetual license for using it, doesn't solve any of the problems I listed above. And if they have permission and are doing the modifications themselves, why should they pay the original author?

What you appear to be arguing is that developers shouldn't be compensated for their efforts unless they write custom software for commercial organizations as contractors or employees, and that if they develop novel software no one thinks to ask for, that should just be given away free for others to profit from.

> if they have permission and are doing the modifications themselves, why should they pay the original author?

They should have paid the author for the right to use the software. That would normally include the right to adapt the software for their own purposes.

The author has the right to decide on the terms of the licence under which software is released. Any user who doesn't agree to the terms shouldn't be allowed to use the software.

> What you appear to be arguing is that developers shouldn't be compensated for their efforts unless they write custom software for commercial organizations as contractors or employees, and that if they develop novel software no one thinks to ask for, that should just be given away free for others to profit from.

I never said that this shouldn't happen, don't attribute me words that I didn't say. I said that typically it won't, since it doesn't make any sense to the users of the software.

> They should have paid the author for the right to use the software. That would normally include the right to adapt the software for their own purposes.

You didn't reply to my question, which was: why?

> The author has the right to decide on the terms of the licence under which software is released. Any user who doesn't agree to the terms shouldn't be allowed to use the software.

No one is arguing otherwise. What I'm trying to explain is that developers following that strategy will likely find themselves with very few users. In the long term, the developer who gives the users a product that better matches the user's needs will displace the one who doesn't, that's pure market behaviour.

Paying the author for the right to be locked in a closed software ecosystem is a terrible value proposition from the point of view of the client. Note that this argument applies primarily to software like the one in the article, which tries to be a development platform, not necessarily to applications.

I understand when we're talking about crypto or security. You want your data to be safe. You want to know that it is what they're selling. But this? A guy is building something that might be cool one day. One should he make his engine/IDE opensource? He can but doesn't have to. I don't see people screaming why SublimeText, AbletonLive, Photoshop or many other tools aren't open source. There is still that thing called commercial software and some people make a living out of it.
Even through I love open-source, I can't argue this point.
SublimeText, AbletonLive or Photoshops are not platforms where you create an automated software artifact that runs on top of the tool. On top of a programming language, however, you depend on the tool being always available without major changes for as long as you need it to remain stable. This is not guaranteed on a privative development platform. They are simply not in the same class of products at all.

In all your three examples, the product they create is detached from the creation platform before release, and that product (text, music, images) is compiled/played/displayed on a different application; an also there are many alternative tools where the product could be processed if the original tool ceased to exist.

So there's no fear with those that, if the tool creator begins imposing more and more restrictions, you'll be locked-in. But a unique programming language for which your code can't possibly be ported to a competing platform? One would be stupid to develop for it anything requiring ongoing commercial support, beyond some cool tech demos.

Stupid as all those people building games with Unity? Or all those people who used to use Unreal/UDK before v4 while there was no source code available?

Anyway not here looking to start a flame war. My point was that the product can be good or bad and it doesn't have anything to do with it's source code being available or not.

My 5c. Everyone feel free to disagree.

Games is one kind of software where you usually won't expect to keep your code base maintained 10 or 20 years from now. So far for the "stable platform" argument where you as a user wouldn't want anything less than open source code, unless forced to use proprietary code for external reasons.

There might be a cost/benefit analysis where some closed platform is extremely far ahead in every other aspect, but you should be very well aware of the risks of being tied to that platform.

Both Unity and UDK recognised the benefits of open source, and have OS components.

A product can be good or bad without OS. So long as you can deploy what you make with it effectively.

Sometimes that means mindshare, like UDK and Source.

Sometimes that means complete decoupling tooling from code like Sublime and Atom.

Sometimes it is more about the deployment, like Visual Studio and Unity.

However, to stand out, this product needs one of the above.

It's new, and doesn't seem to be backed by a big name, so no mindshare yet.

So they need to somehow make devs want to use it for their code. A nice experience is usually not enough.

An OS community, or a fantastic cross-compilation strategy are the only two things that I, personally, have seen work.

OS seems to be the easiest of the two.

> So they need to somehow make devs want to use it for their code. A nice experience is usually not enough.

While I side with your central argument, there are numerous cases where the above is absolutely enough.

I actually disagree about the fullscreen video. Why would I ever want to watch video not fullscreen?

Vimeo also behaves like this on mobile and it's far superior to Youtube, which often totally hides the fullscreen button.

> Why would I ever want to watch video not fullscreen?

Because the way they are doing it there is no minimize button. A less technically inclined person may not know that they have to press Escape (and now, it seems, some laptops have no hardware Esc button at all). In addition, the first time I played it, for some reason, Esc did not work and I had to Alt-Tab in order to leave the video.

I didn't check what this looks like on mobile, but I do the majority of my browsing on an iPad and while I use a physical keyboard with it, it doesn't have an escape button.

Presumably, this would use the usual mobile video player though, which does have a minimise button, so its likely not a real issue (I'm not on iPad right now so didn't check).

>Why would I ever want to watch video not fullscreen?

Because you're doing other stuff while listening to the audio.

>Youtube, which often totally hides the fullscreen button.

It's in the bottom right.

>It's in the bottom right.

Not in OP's video. There's literally no way to escape the full-screen without pressing the escape key. You can't even double-click. I'm actually impressed by how user-hostile that video is.

There is an alternative non-fullscreen link available but Amazon CloudFront cache hasn't been updated yet.
It's just a youtube video:
Actually more like Stop Drawing Dead Fish by Bret Victor:

He is my hero actually :)

Dec 23, 2016 · shurcooL on Principles
This made me think of Bret Victor's classic Inventing on Principle talk [0]. It was also broken up in similar 3 sections.


I don't want to belittle anyone's work or inventions, but I think modal editors are old and outdated. They've had their time in my mind.

Bret Victor gave a great talk about programming and tools:

His talks always blow me away.

His demo is a neat parlor trick, but when you think about it, he's really just painting with javascript instead of a paint program.

Introduce any kind of higher dimensionality into his model and it breaks.

On the contrary, my reaction to reading OP was, "wow, somebody brought Bret Victor's ideas to modal editors!" The goal of switching verb and object is precisely to stop drawing dead fish (!/StopDrawingDeadFish)
This one by Bret Victor (or any of his other talks, really) also come to mind:

Firstly, maybe lastly, the conclusion of this video is real powerful stuff. I cannot pinpoint it's philosophical anchoring or origin. The same message was at the end of the iconic documentary about Jodorowskis Dune.


I have been trying to mentally operationalize the advice and ideas here, but found it really dificult and abstract.

Obviously an incredible lecture that deserves its own category.

Nov 11, 2016 · rpeden on You Don't Need
I think that's exactly the kind of workflow we should be able to create a graphical interface for.

I sometimes wonder if our ability to imagine what visual interfaces can do is limited by our experience with current GUIs. Right now, as other have pointed out, we're limited by the fact that GUI interfaces aren't really composable the way CLI commands are.

But what if we had something that is composable -- maybe something like Smalltalk on steroids -- where every program is a living object that can describe in detail what it does? Then, you'd be able to ask the program what inputs it requires, what its abilities are, and what outputs it can provide.

With something like that, it would be possible to visually put together interesting combinations of programs that we might not have created otherwise. Sort of the like what Bret Victor describes in 'Inventing on Principle'[1] where certain solutions to problems become much more apparent when you can manipulate things and try out new combinations quickly. I'm certain things like this exist (and have existed) in various forms, but I don't think we've explored the concept as fully as we can.

On the other hand, though, I agree with a quote from Eben Moglen earlier in this thread where he talked about 'point and grunt' interfaces. We've been iterating on the same paradigm for a long time. Touchscreens are better in some ways, and worse in others. We gain more physical interactivity with our devices, but we lose a lot of precision because we're now just smacking meat sticks against a pane of glass.

But you know, it's easy for me to sit here and complain about this on the internet. Actually doing something about it is much harder. Maybe it's time for me to fire up Smalltalk and give it a try. :)


Bret Victor's "Inventing on Principle" [1] or Rob Pike's "Concurrency Is Not Parallelism" [2].

[1] [2]

Paul Buchheit - Startup School Europe 2014

Anjana Vakil: Learning Functional Programming with JavaScript - JSUnconf 2016

Bret Victor - Inventing on Principle

Philip Roberts: What the heck is the event loop anyway? | JSConf EU 2014

I definitely recommend Philip Roberts's talk. I watched it a couple of months into learning Javascript and then everything "clicked."
By far my favorite talk is and has been for a very long time Bret Victor's inventing on principle, for me, nothing comes close, except for some of his other work I suppose.

Best talk open ever: "Unlike the previous session, I don't have any prizes to give out. I'm just going to tell you how to live your life"
Thanks for posting this, very much appreciated.

Are there any tools available which allow you to live code in such a way?

I did a quick search and found this -

It seems quite out of date though.

The closest thing I can think of is Clojurescript with Figwheel:

The goals of Eve follow some of the inspiration in his talk.

What's especially neat about that talk is the fact that it's from CUSEC: a student-run conference out of Montreal. So many great talks I've seen online were from that conference.

Never went to it as a student (it was only 3 hours away, how did I miss this?) but lots of my friends did, one even ran the thing for a year I think.


Was gonna post this if it wasn't up already.

After this, The Birth and Death of Javascript:

He could've taken the concept further tho. I think there are real hardware simplifications you could do if the OS is a jitting VM - no memory mapping unit and take out the expensive fully-associative TLBs.

This is great. I love that he goes into the future. :)
this is quite outdated
but it's from 2035...
I always have trouble when telling people in person to go watch this - how should I pronounce the "J" in Javascript?

* SPOILER ALERT, and seriously go watch it first *

If I pronounce "J" I do him an unjustice, and if I pronounce "Y" I ruin a great surprise that comes quite a few minutes into the talk.

I always go with the "J" pronunciation. It maintains the expectation that the talk makes a joke out of by breaking. I would rather give everyone that first time experience of hearing the "Y" pronunciation than do Gary an injustice.
Bret Victor - Inventing on Principle

We can argue on some of the points he makes but we can all agree that the demos are very impressive.

Very cool! Some of this reminds me of the talk that Bret Victor gave at CUSEC 2012:
Very cool! Seems similar to what Brett Victor demos here:
That was very experiential and life changing. Thank you for linking Brett's manifesto!
Lol, I wrote the same exact comment (just 2 hours later)!
These will definitely help convert Google Drive users. As a developer I'm more used to the edit-compile-verify cycle, but it's still nice.

Also made me rewatch Inventing on Principle

This tool reminds me of the work of Bret Victor who challenged developers to build visualization tools for code:

May 12, 2016 · 1 points, 0 comments · submitted by mkolodny
Feb 18, 2016 · vinchuco on Mathematics Animations
It is sad that Mathematics is often taught either as narrow examples that miss the big picture or abstract definitions which are more general but feel artificial.

The best teaching often jumps back and forth between the two.

Mathematics can be thought of a simulation of properties of the world inside people's brains which verify the result. Sadly, there's no shared comprehensive framework outside our brains for visualizing [1] and organizing all of it, since it's very flexible [2]. And thus most people miss out on experiencing the beauty of many results.

I sometimes wonder if LaTeX augmented by context (and visualization) would help, and I wish Mathematica was open source to aid this. At the same time, we are faced with incompleteness results that put into question any formal organization of mathematics [3].




Sorry for the long rant.

> I wish Mathematica was open source to aid this.

Rather than wishing for this that will not happen, let's work to make Sage, particularly SageMathCloud (, the lingua franca of CASs.

I actually deleted a rant that completely says what you just said. I 100% agree. It's mind boggling how much intuition is available to explain maths. It oddly just... makes visual sense. It's "simply" an explanation of what's around us.

Yet, when discussing it, <i>while learning</i> with math folk, it's usually met with "You don't have a degree" or "That's not a formal understanding of the definition, come back". It's completely exclusionary and killed much of my math passion until recently.

It seems a lot of concerns about math pedagogy tend to be killed off with "you don't have a degree", "you don't have the math gene" kind of rhetoric which is a pity. I discovered I really liked math waay too late for my tastes and it was mostly because I was being taught math by people who didn't really know math.
Jan 06, 2016 · 2 points, 0 comments · submitted by badboyboyce
Jan 06, 2016 · ElijahLynn on Bret Victor's Bookshelf
This is how I know him, a talk that every dev should at least know about. It is about live/realtime coding and has some pretty jaw-dropping demos.

"Inventing on Principle"

That was 54 minutes well spent...thanks!
Dec 06, 2015 · TheAceOfHearts on Apple: Open Source
I went to a reactjs meetup at Apple a few days ago. There they showed off Revis, a react library for making charts and visualizations that looked really interesting, with the selling point being that it enables you to create graphs declaratively. They said they had plans of open sourcing it, although they didn't give a due date.

Another thing they indirectly showed off was a reactjs playground which was very similar to swift playgrounds. I say indirectly, because the person that was presenting was showing revis using it. There's some public playground components that are around (e.g. component-playground [0]), but it's the type of thing where I think there's still room to experiment and innovate. Bret Victor's Inventing on Principle video [1] comes to mind.

I don't know how big the web presence at Apple has been in the last few years, but I'm hopeful that this is a sign that it's growing and that it'll push more resources to the Safari team so it'll keep up better with other browser vendors. Although they have a history of open source, I don't think they've open sourced much JavaScript? From googling around all I could find was that they were one of the biggest contributors to SproutCore [2], which looks fairly dated by today's standards.




I work at a web shop, and we're convinced that Apple is deliberately failing to make improvements to Safari (specifically on iOS). The theory is that they are conspiring to lock in people who depend on the platform, but also prevent them from delivering anything approaching the quality of native apps on iOS.

Though usually I try to avoid thinking of conspiracy; the more I work with their platform, the more reasonable this theory sounds.

I have been solicited to work on WebKit for Apple, but given how isolated Apple employees seem from the world, I don't think I could do it. I'm not willing to sign away my personality or existence for cash-on-hand. I suspect they're having trouble hiring people to work on WebKit, because although I think I'm a pretty good developer, I'm not the top of the barrel when it comes to WebKit developer candidates.

This is pretty much the definition of confirmation bias.
>I work at a web shop, and we're convinced that Apple is deliberately failing to make improvements to Safari (specifically on iOS). The theory is that they are conspiring to lock in people who depend on the platform, but also prevent them from delivering anything approaching the quality of native apps on iOS.

Classic cooky conspiracy theory.

In fact the Android browser is in many ways worse than Mobile Safari.

So there goes the whole theory...

Most Android devices these days run Chrome.
So, this paper is actually from 1986. More fuel for your argument.

Out of the Tar Pit ( is an interesting response. I'm not convinced Functional Relational Programming is a silver bullet. But I think the arguments about state are certainly compelling.

After reading Out of the Tar Pit, I got the impression that No Silver Bullet was perhaps accurate for individual programmers. But I think there are still lots of silver bullets for teams of programmers. I think a lot of your examples fall in that category. Source control, internet resources, etc. That all helps us collaborate.

I think maybe Out of the Tar Pit points at some things we can do in our code to improve our productivity as a group (by making code easier to understand and reason about.) I think some of Bret Victor's immediate feedback stuff ( and the places the Eve team are taking it ( are also pointing in that direction.

Ultimately, I think a lot of the crappiness in software these days exists because the things that are very easy for a single programmer make things hard for a group. It's funny because the author of "No Silver Bullet" is also the author of "The Mythical Man Month". Maybe he doesn't focus on collaboration because the conclusion of the Mythical Man Month was "only let one person code and have everyone else support him."

IMO bret is a truly revolutionary thinker in the field of CS, really a genius of our time. understudy of the similarly gifted Alan Kay. Inventing on Principle ( profoundly changed my perspective on life and software when I first saw it years ago, much like the Hubble photos. I wish our culture and society cherished and gave more credit to these individuals.
I don't know, seems like a lot of bloviating and hand waving to me.

>>Media are our thinking tools. Our representations of a system are how we understand it.

I got this quote from the site, seems to be the central premise for this endeavor. Is this even valid? Are media our 'thinking tools' or something else, like our 'communicate to others what I'm thinking tool'? There's a big difference imo. This person appears to be going for a Sapir Whorf Hypothesis applied to media. Seems to be similarly fraught with peril ie open to debate as SWH is.

>> Are media our 'thinking tools' or something else, like our 'communicate to others what I'm thinking tool'?

Interesting. Media are definitely enablers of better understanding, in my experience. There are often occasions where writing it down, or drawing a picture/graph have aided my thinking drastically. It's a method for channelling and organising thoughts so that my brain suggests the right next step, rather than getting hung up on peripheral matters, dinner, etc.

Having said that I can get similar epiphanies by also explaining the problem to someone else. That might suggest the benefit is less media, more a form of communication, as you suggest.

Personally though, I think the message is that structuring thought can yield great benefits and that's what these guys are aiming for as far as I can figure out. Great stuff.

> Are media our 'thinking tools' or something else, like our 'communicate to others what I'm thinking tool'?

What you're saying essentially is that the only times digestion of input would benefit from the things Bret Victor talks about is when those inputs are others' output. It seems that this suggestion would have only come from someone who finds themselves dealing almost entirely with the output of others and trying to make sense of it, rather than any original research or thought. What's more, is that I feel like I'm in some sort of Escherian loop here, because to anyone for whom is the case, they'd never have been interested in trying to make the suggestion that these tools wouldn't necessarily help elsewhere (having no "elsewhere" to contrast it to.)

The types of tools Bret focuses on are as important if not moreso for solo endeavors of research/discovery/understanding as they are for trying to achieve person-to-person communication with the smallest possible time-to-understanding penalty.

>> What's more, is that I feel like I'm in some sort of Escherian loop here

Indeed. More to the point, what I'm implying is similar to the Allegory of the Cave. Thoughts are not constrained by time, space, or physics. I can build whatever structures in my mind, create, theorize, hypothesize, but if I can't communicate that to others, what have I done? Navel gazing I wager. Example, Einstein was really good at communicating his ideas thru writing and mathematics. But whatever one communicates is a projection, a shadow on the wall of the real content of the thoughts within. The point being physical media of any sort is a poor substitute for the canvas of the mind.

> I can build whatever structures in my mind, create, theorize, hypothesize, but if I can't communicate that to others, what have I done?

Most of the types of tools being discussed here are ones to help with the first part. Not being able to communicate something after having figured it out is an appreciable problem, but not being able to satisfy the preconditions—of having figured it out for oneself to begin with—has necessarily at least as many negative consequences.

As for the question, there exist plenty of contexts where a realistic answer would be "quite a lot". There are lots of engineering problems that fit in here. It doesn't matter that you're able to communicate to someone the novel discovery you made that went into the implementation of the software they're using. That the software/bridge/ag technique/etc simply exists comes packed with benefits all on its own.

This isn't even to mention that, in regards to communicating to others something that you've worked out for yourself, the tools that you would have used to do that work initially (e.g., visualizations) are apt not to be described for that purpose as "completely useless".

This reminds me of the opening to David Foster Wallace's "This is Water."

There are these two young fish swimming along, and they happen to meet an older fish swimming the other way, who nods at them and says, “Morning, boys, how's the water?” And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes, “What the hell is water?”

Of course the invention of representations like written language, equations, and graphs changed the way people think. It's just hard to see at first because you've grown up immersed in them.

Love the Bret Victor talk mentioned on the Lamdu page: "Bret Victor - Inventing on Principle"
Apr 04, 2015 · hrayr on Myself – v1.0.3
The best and earliest example I saw of this was Bret Victor's talk "Inventing on Principle"
I'd like to see tests running as I type. Something like this:
I gave a talk at OOPSLA in Montreal in 2007, made a pacman game during my 30 minute talk slot using a live programming language/environment. I'm sure I wasn't even the first, as I got many of my ideas from Chris Hancock's PhD thesis published in 2003, "Real time programming and big ideas in computational literacy", and of course the multitudes of less but still interactive Lisp and smaltalk environments, and fully interactive visual environments way before that (starting with sutherland's sketchpad).
Is there a video of the talk?
No, I have some videos of the demos on you tube...see the bottom of

This reminded me of Bret Victor's great talk Inventing on Principle[0].


Great talk. Do you know what tools was he demonstrating?

Are these tools available to use?

Though those exact tools are not really available, there are a couple of "alternatives" when it comes to live coding; a HTML5 canvas playground[0] and another similar one[1].

If you are interested more in live coding you might want to check



Since this Asimov essay is about groups functioning in a space, Brett Victor's seeing spaces talk also seems rather relevant. Give people new ways to think about things, and great places for them to think together.
Sep 19, 2014 · 3 points, 0 comments · submitted by KhalilK
This is very cool and I hope to see it when it's complete.

BTW, have you thought of making the values in the code samples scrubbable? (e.g. at 4:20 in this Bret Victor video I think that that change would really aid in "feeling" the behavior of the algorithms.

Great idea for a book. I am all for interactive education. Well done. Also, what a brilliant video. A new way to interface with code and imagine algorithms, animations and data. All to be used for education! My favorite part of the video was at 30min, where Bret demos how to interactively make animations. Reading the comments on the video led me to purchasing Braid, a game that was mentioned. HA.

EDIT: Exploring your link, I discovered Bret Victor. Anyone looking for some inspiration look at his show reel.!/Showreel2012

Jul 13, 2014 · thikonom on Usable Live Programming
reminds me of
I decided to quit my job and start on the night that I saw Bret's Inventing on Principle video [1] and read his Magic Ink paper [2]. Based on lots of conversations I've had with other entrepreneurs, I'd say that a lot more people are inspired by Bret's work than you might think...



Python Tutor is a great inspiration and benefits from a greater amount of detail, though I've found it not to be very accessible for teaching beginners due to its relative complexity. I was fortunate to have the opportunity to see Philip Guo (the creator) speak at Google, though - really inspiring, and clearly very passionate about what he does!

For anyone else interested in visualization who hasn't seen it, Bret Victor's Inventing on Principle is also a wonderful idea of how visualization could benefit programmers:

Jun 02, 2014 · talmand on Introducing Swift
I posted this elsewhere in this thread:

Bret Victor worked at Apple for a time as well.

Jun 02, 2014 · talmand on Introducing Swift
Jun 02, 2014 · achompas on Apple (2011)
Ok, context for people:

This post is from 2011.

In one of his most popular talks from 2012, Bret demos a book-styled IDE. As you write code on one side, the IDE updates a visual representation of that code on the other side. (

Apple just announced Playground, where you can see immediate feedback live in your game as you tweak the code. (

Today, we learn two interesting things:

(1) What Bret worked on while he was at Apple.

(2) The gestation period -- conception to release -- for a fascinating, research-type software project at Apple (it seems to be ~3 years).

Jun 02, 2014 · xendo on Introducing Swift
I think they were thinking about this even earlier:
Our human brains have hardware acceleration for image processing as well. Limiting ourselves to text is wasting half our natural resources.

Flowcharts and LabView are old paradigms, they have and are problematic for abstract tasks (they're only good for data manipulation). What's needed is a new style of programming that combined the best of visual and textual representations. Wolfram Language [1] and Bret Victor's Inventing on Principle [2] are more modern approaches in that direction.

[1] [2]

I don't think that the OCaml debugger let you do the things demonstrated by Bret Victor in his talks, and implemented there. As explained elsewhere in this thread, these features let you replay a conputation sequence in a loop, and bind certain values of the computation context to visual inputs (sliders or more simply input boxes for instance) to modify these values during the replay loops. This let you observe how the computation sequence reacts to those changes. It allows a more playfull testing and tuning of a program. Of course it is way more useful in the case of a visual rendering performed by said computation. Please watch the Bret Victor's video for insight (maybe that one:
A couple of recent, interesting explorations:

Subtext ( - in particular check out the video on "schematic tables," which is very immediate and direct like Excel but better for general purpose.

Some of Bret Victor's work: Inventing on principle ( Media for the Unthinkable ( He has a lot of examples of similar interfaces for more domains than just what Excel is good at.

Another example, although much less so, is Unity's editor- property editing and level editing are very immediate and visual even for things like behavior.

Apr 02, 2014 · erikano on ipython 2.0.0
The interactive widgets reminded me of the great talk Inventing on Principle by Brett Victor.
demonstrates an immediate connection with their tool:
Mar 08, 2014 · 2 points, 0 comments · submitted by StandardFuture
I agree. It's impressive to me the people who are claiming that something like unit testing can compare to these kinds of tools, without seeing the general direction these tools are headed in. Unit tests are helpful, no doubt. But compare the following:

- Spend several minutes writing a small test suite for the functionality you're writing. Write that functionality until you think it's correct. Compile, run. See a "Pass!" or "Fail! (reasons: ...)" in your console or IDE, fix it until it's working. Feedback loop is measured in minutes, seconds at best.


- Write the functionality. As you're writing, you see the data flow through your program in real-time, immediately identifying bugs. Any unit tests you may have are _even more useful_ because you can inspect your program at any level, without having to debug or step through your program. No need to re-compile and re-run, no need to even Alt-Tab. Feedback loop is measured in milliseconds.

Light table isn't quite there yet, but it's a strong step in the right direction. Unit tests help, but they don't obviate the need for better tools.

To give a bit of context on the direction these tools are trying to move in, Light Table was heavily inspired by the work of Bret Victor, who bases his work on the idea that, quote, "Creators need immediate feedback to what they're creating." If you haven't seen his _Inventing on Principle_ talk [0], you should. It's one of the most eye-opening talks on software and design I've ever seen.


Precisely. Software it's all about shortening the length of the feedback cycle. Chorus: "How is email / web / google different than pigeons / library / index of an encyclopedia book?".
Jan 12, 2014 · kbenson on Meanwhile, at
or at least props to portray ideas rather than actual tools to use

Exactly. He is thoroughly invested in using technology and programming to teach ideas, concepts and ways to think.

Just out of curiosity, has he made anything I can actually use? Or does he have any work that is particularly substantial?

His CV[1] link has interesting stuff, but you may not find something immediately useful on his site. Light table was inspired by one of his talks[2] (when I first saw light table I thought it was him following through on the idea).



Edit: Whoops, put a link instead of your quote for the second section.

Reminds me of Brett Victor's “The future of programming” (, “Learnable Programming” ( and “Inventing on principle” (
Reminds me of Wolfram's earlier book...
This shows how far we've gone where we can write this kind of stuff easily.

However we have a long way to go. This would be nice for a start:

Nov 12, 2013 · 1 points, 0 comments · submitted by thomasloh
Bret Victor also has many other amazing and thought provoking talks:

Inventing on Principle:

Stop Drawing Dead Fish:

Drawing Dynamic Visualizations:

The Future of Programming:

I knew the name sounded familiar. Bret Victor also gave a great talk called Inventing on Principle (
A lot of the stuff here (especially the circuit simulator) were discussed in Inventing on Principle.
If you enter through the home page, you can see a list of his other talks:!/InventingOnPrinciple
You might want to check out this talk by Bret Victor, "Inventing on Principle":
You can do cool things with immediate updates:

The great thing about hosting on github is that people can send pull request and you have real collaboration. That's alsmost impossible with Illustrator files. In reality many OSS is abondoned and change leaders or simply die. If you have a source that is accessible by 100% of the programmers (and with icons there is a huge crows who's interested) then your project probably won't die.

Want will the kickstarter accomplish? Sure it'll give you great quality icons, but then what? What if the project is delivered and put open sourced? Is it going to be maintained indefinitely? For 2 years? 5 years? What about in 10 years? Can we still use it?

But now we're really off topic, I'm just re-elaboration why open source (and line based source code) is better. I could also argue why documentation in Markdown is better than word for highly collaborative projects....

Incase you haven't seen Bret's talk about Inventing on Principle, here it is:
If you haven't watched it yet, I like Media for Thinking the Unthinkable even better:
Awesome, thanks for the link. I have it queued up--I'm going to watch it after I submit my app to Apple :)
A very good one is "The future of Programming",

Where he pretends to be in a late 70's conference, discussing how the current ideas about Smalltalk, GUI environments, parallel programming and so forth, can be used and how the computing world might look like in 30 years time (meaning nowadays).

Yeah that was a very good one. I saw that a few days after it came out and he makes some very good points in that talk. I would love to be able to chat with him 1 on 1 and just ask him questions because he seems like he's thinking about problems in very new and exciting ways.
Visual programming used to leave me completely cold, but with the emergence of tablets and the promise not to make _everything_ visual, I hope to convince people otherwise. If you have not seen Bret Victor's brilliant "Future of programming" and "Inventing on principle", I highly recommend it.

I promise not to make the Haskell struct mistake.

I'll try and find time for it. Thanks for the recommendation.
Disclaimer: Our focus at Fogbeam is on "deploy on premises" apps, not SaaS. And while we expect to offer our software in SaaS form later, it isn't our focus, so my perspective may be a bit skewed.

That said... I feel like you just have to start with something that interests you. In my case, I was just plain fascinated by the idea of "social networks in the enterprise"... I was also really interested in machine learning / artificial intelligence, knowledge management and the idea of "collective intelligence". And over time, different events just led to all the dots starting to connect, and I started to see the kinds of products I wanted to build. Of course, the vision was pretty fuzzy at first, and we've iterated on it, and de-emphasized some aspects, added new aspects, promoted aspects that were originally less emphasized, etc.

The thing is, there are absolutely people already doing some - if not exactly all - of what we're doing. There are "enterprise social network" products out there... hell, there's actually a laundry list of them: Jive Software, Yammer,, Tibco Tibbr, IBM Connect, Salesforce Chatter, etc., etc., etc. But, to that point, two thoughts:

1. Despite how many ESNs there are, we still have some aspects to our approach that are actually different from the other ESN products out there. Our vision also goes bigger than just the ESN... that'll be our first product, but we see it as just part of a much larger whole. And it's that "whole" in sort of the "whole product"[1] sense that we think will really set us apart when it's in place.

2. Competition doesn't bother us. I remember reading a blog post from Bob Parsons (of GoDaddy fame) a few years ago, that said something like (paraphrased):

"Don't be scared of crowded markets, just be better than everybody else".

That resonated with me. Call me arrogant, but yeah, we think we can build a better product than Jive, Yammer, Hall, Tibco, IBM, Salesforce or whoever. And we think we're operating with a superior big-picture vision. So basically, we don't care that there's "somebody else doing that", we just intend to beat them.

So I guess if I had any advice for you, I'd say:

Start with something you're already interested in. Look for places where two or more of your interests intersect, or can be combined in such a fashion as to create something novel. Once you have the basic idea in place, do a deep dive into that world... read the literature (if there is any) on the domain in question, talk to people who might be potential users of your product (or, at the earliest phases, anybody who'll talk to you) and solicit their ideas. Look for the "X sucks" forum posts for your competition and see what people are complaining about. There's your opportunity to do better.

Another idea I'm big on could be paraphrased by saying "everything old is new again" or "the only way forwards is backwards". I know I've ranted about this before, but I think there's a ton of value in going back and reading the works of early computer industry pioneers - people like Vannevar Bush, Douglas Engelbart, J.C.R. Licklider, Norbert Wiener, Herbert Simon, Alan Newell, Ted Nelson, Marvin Minsky, etc. and seek inspiration in their writings. Surprisingly, there are ideas that were being batted around in the 1960's (or earlier) that haven't been fully realized yet. Take that inspiration, merge it with your interest area, and see if you can't come up with some ideas for ways to differentiate your product.

Also, watch that Brett Victor video[2] that is posted here on HN quite frequently. It's chock full of amazing insights.

Edit: to add one more thing: I don't know that being passionate about the thing you're building is sufficient (it almost certainly isn't) but I'd almost be willing to be that it is necessary. At the very least, I think it's a huge benefit to you if you're genuinely enthusiastic about the product and would want to use it yourself. In our case in particular, I definitely want to grow a large, profitable, kick-ass company... but even if we fail at that, or even if we weren't even trying to do that, I'd still enjoy the process of creating this stuff, because working on it is genuinely enjoyable to me. And when the hours start getting long, and things aren't going your way, and some doubt creeps in, I believe it's a lot easier to keep moving forward when that's true. If you do something that's only about the money, I would question if you'll be motivate enough to power through the inevitable tough periods.



Jul 28, 2013 · 2 points, 0 comments · submitted by goronbjorn
Bret Victor, who has been inspired[1] by Doug Engelbart, has showcased plenty of innovative ways on design/user interaction on his presentations/writtings:

* Magic Ink[2]

* Stop Drawing Dead Fish[3]

* Drawing Dynamic Visualizations[4]

* Media for Thinking the Unthinkable[5]

* LearnableProgramming[6]

* Inventing on Principle[7]








Watch his presentations, they are incredibly inspiring and impressive.

All are required viewing for the HN crowd.

Jul 21, 2013 · DanielRibeiro on Ideas for Computing
Where's our version of "The Mother of all Demos" ?

Bret Victor, who has been inspired[1] by Doug Engelbart, has showcased plenty of innovations on his presentations/writtings:

* Magic Ink[2]

* Stop Drawing Dead Fish[3]

* Drawing Dynamic Visualizations[4]

* Media for Thinking the Unthinkable[5]

* LearnableProgramming[6]

* Inventing on Principle[7]




[4] Drawing Dynamic Visualizations




The gentleman who wrote it is Bret Victor. I highly recommend this talk [1] by him (500k views), he's a true visionary.


Just watched that talk... amazing. Do any of the tools that he uses in that talk exist?
I believe LightTable [0] ran with some of the concepts in the video, and I remember one of Chris Granger's videos having an almost identical bit about mapping time over space in a ball/block jumping game and very similar themes. Either way, it's definitely worth checking out. Sorry if I get any of the details wrong, I'm a bit out of step with Clojure.

[0] An IDE that supports Clojure and Javascript right now, maybe Python soon? Bit behind on the news:

I have watched this video a few times and periodically revisit it. Sometimes we get to far into the woods and need to be reminded where we can go writing software.
Also consider reading his seminal essay called "Magic Ink" [1] and afterwards take a look at the publication date and try to remember where the web was back then.


The animation software Bret Victor demos in his "Inventing on Principle" talk looks pretty cool [1]. I don't know of anywhere the software from the talk is available though.

Yeah I love this work and have been following him all the way back from when he wrote Magic Inc.

I am not convinced about his particular way of doing animation though.

I am a huge fan of VIM's design (and by extension EVIL in Emacs, which is what I use most of the time), and I agree that all to most of this is achievable in Emacs.

I really like Jetbrains products though, and when I am on Windows those are my goto tools as I don't have the UNIX user space to leverage alongside Emacs or VIM.

They provide a great environment for those languages that don't have great support outside of commercial IDEs or for people turned off by Emacs/VIM.

My first experience was using IDEA for Java (both VIM and Emacs support for Java is an area where they are weakest somewhat surprisingly) and I was very happy with IDEA, so I tried PyCharm later on when I was on Windows and using Python there.

However, Emacs makes use of Python's REPL much more fluently than what I've experienced in PyCharm where the IDE has no interaction with the REPL outside of user engagement.

PyCharm in comparison seems entirely ignorant that it has a REPL it can exploit and integrating tightly with it would pay dividends.

Coming from Emacs where REPL integrations tend to have at least some sense of intelligence about them this was jarring.

PyCharm's intentions though are also very nice and isn't something I've found in Emacs or VIM to the same extent.

The IDE still has the same trait I've seen in Eclipse, VisualStudio, XCode, and Jetbrains' products though where it makes determining what the project entails into an overly complicated affair though, an area where VIM and Emacs have less red tape to get into.

There seems to be a great deal of improvement in that area for tools to get into where they are smarter without requiring so much user facing bureaucracy up front.

On one hand we have Emacs and VIM that largely pretend there is no such thing as a project and that tools could perform actions on that as a unit.

Then on the other side IDEs want to recognize that a project is an actionable unit and that it is a unit but then engage in 20 questions just to get started on a project and even after that get easily confused when moving files around.

Anyways, as far as IDEs go, Jetbrains' products have been the most enjoyable to use.

I do wish they were full open sourced though so that contributing improvements voluntarily wasn't a comparatively precarious trade off compared to VIM or Emacs or whatever open source tools you use.

Also, I wish IDEAVim was a lot nicer support of VIM's features than what it currently has so that I didn't have to want for some functionality at times.

Both the Emacs and VIM or typical IDEs have a lot of room for improvement in general though, tooling could be a lot nicer and homogenous across languages to the extent possible.

I really wish anyone would run with Bret Victor's idea of closing the feedback loop in programming ( adamantly and also implement Douglas Crockford's idea of scope based coloring everywhere (, the latter of which I really want in functional languages like Haskell/OCaml.

Those two alone would add significant utility to the available tools.

After seeing Crockford's scope based coloring idea syntax based coloring seems incredibly superfluous even though I use it myself.

It really feels like we are in a tooling stone age with a great deal of retreading and regression in some respects despite having a lot more man-months thrown at the area.

ideaVim is Open Source and contributions are welcome.
Why is our generation stuck in VC-istan instead of working on things that actually matter?

I believe Bret Victor tried to answer[1] this on his Investing on Principle[2]:

Default choice 1:

The world will try to make you define yourself by a skill. That's why you have a major in college. That's why you have a job title. You are a software engineer. And you'll probably specialize to be a database engineer, or a front-end engineer, and you'll be given front ends and asked to engineer them. And that can be worthwhile, and valuable, And if you want to pursue your life pursuing excellence, and practicing a skill, you can do that. That is the path of a craftsman. That is the most common path.

Default choice 2:

The only other path you hear about much is the path of the problem solver. So I see entrepreneurship and academic research as kind of two sides of that coin. There's a field, there's a set of problems in that field, or needs in the market. You go and you choose one, and you work it and make your contribution. And a little bit later on, you choose another problem, work it, make a contribution there. Again, that can be worthwhile and valuable, and if that's what you want to do, you can take that path

And finally:


But I don't see Larry Tesler on either of those paths. I wouldn't say he was contributing to the field of user experience design, because there was no such thing. He didn't choose some open problem to solve, he came across a problem that only existed in his own head, that no one else even recognized. And certainly, he did not define himself by his craft, he defined himself by his cause, by the principle that he fought to uphold.

There are many ways to live your life. That's maybe the most important thing to realize in your life, that every aspect of your life is a choice. There are default choices. You can choose to sleepwalk through your life, and accept the path that is laid out for you. You can choose to accept the world as it is. But you don't have to. If there's something in the world that you feel is a wrong, and you have a vision for what a better world could be, you can find your guiding principle, and you can fight for a cause. So after this talk, I'd like you to take a little time, and think about what matters to you, what you believe in, and what you might fight for.

And I add: following non default choices is hard. Following a principle is hard. Noam Chomsky explains the deep reason why that is on his Manufacturing Consent[3]




This made me think of Bret Victor's talk Inventing on Principle where he encourages the audience to basically do what you're criticizing - sort of developing an activist mentality for the problem you're trying to solve, even if it may seem trivial to some.

Reminds me a lot of Bret Victor's Inventing on Principle talk ( I went to the lecture he gave at Stanford back in February ( and meant to ask him what ever happened to that editor he demonstrated. He's working on new software right now now that lets you take datasets (think plaintext CSV files) and programmatically construct new visual displays of those data (so perform this set of actions on each item, and repeat that through the entire set with this one change, which the software will learn to repeat through the rest of the data). That new software is web-based, but again, didn't hear anything from him about when to expect it to be released.

Very cool to see this stuff moving in the direction of being responsive inside the browser, and actually working. Understanding variables is one of the most common problems for beginners, and being able to change the variables and see the immediate effects in existing code is compelling.

I agree very impressive. What it resonated with me is its kind of the web 2.0 equivalent of what we called a "programmers console". Classic blinking lights.

IF you follow that analogy, WRT the "Understanding variables" common problem as you state etc, a pretty obvious addition from the front panel area was ways to look at internal state. And breakpoints...

Bret Victor has indeed been my primary inspiration for this project, even before the Inventing on Principle talk (e.g. Ladder of Abstraction, Kill Math, etc). I've written up some more details on the implementation and motivation here, if you're interested: :-)
Asperger isn't a binary diagnosis; it's more of a continuum.

The skills that make you a good programmer place you a little further out on that continuum almost by definition. [1]

Therefore the real question is: Do you feel you would benefit from the treatments that become available to you were you to receive the diagnosis?

[1] The simplest way to (sort of) get that is this quote from Inventing on Principle: "People we consider to be skilled software engineers are just the people really good at 'playing computer.'" ( @ 17m40s)

This link blows my mind. Thank you.
The only reason I gave you a single karma point is because there's no "give this person all of my karma for that comment" button.
Summary of the links shared here:;playnext=...

And here are them with titles + thumbnails:

how awesome are you? thanks
Thank you so much for this!
This is cool :) Btw. the first link was somehow (re)moved. The link is now:
Fair question.

One that immediately pops to mind is this:

Wow. Great video; good referral.
Apr 02, 2013 · simonv3 on Imperative vs. Declarative
I work with a bunch of UX designers, and as the only developer here I'm often confronted with their question of "why can't I just describe what I want done?"

Their apprehension of tackling code is one I don't immediately understand, but I do get that they don't want to think about the how, rather the what. It's a funny parallel.

Here's a great video by Bret Victor who saw this problem, and tried to fix it for animation:

The first thing that came into my mind as I saw the demonstration video was Bret Victor’s instant feedback theme ( It would be so cool to change the component parameters interactively and see the changes in the simulated graphs.

Having an “unsaved changes” warning in a web app feels weird since we have Google Docs.

Thanks for all the feedback. We've seen the video and our client-side simulation engine lets us think about building something like that in a future version!

It turns out that many users are using CircuitLab to do a quick test or a quick change (i.e. what if 0.1uF becomes 0.22uF), and unlike a conventional text document, it isn't 100% obvious that the newest version is always the one they want to persist. (Imagine if git/hg auto-committed your code every time you typed a character!) In some scenarios it's actually more like interacting with a REPL. This is definitely a UX area we'll look to get right going forward!

Maybe a photoshop style history would work well here?
There are two separate user desires that you need to separate:

1. If [browser/server/electric utility/network] crashes I should not lose work.

2. I want to explore a few quick changes and then revert back to a known good point.

The technical solution is to do continuous saving but let the user mark certain spots in the revision tree as more important. Please note that you will be storing all revisions and the structure will most definitely be a tree (due to undo/redo/forking whatnot) Marking could be as easy as hitting save or creating a named revision.

From an UX standpoint continuous saves are best effort while explicitly hitting save should freeze the system and only return an OK once the data has really been persisted to disk.

My $.2, I've worked on Google Docs and Tinkercad.. :-)

Hi Kai, Tinkercad is awesome -- been following it for a while! Agree about the value of the continuous saves, and this kind of functionality is certainly on our roadmap. Thanks!
These are very good points. I believe this also echoes Bret Victor's comment at the end of his famous Inventing on Principle[1, 2]

There are many ways to live your life. That's maybe the most important thing to realize in your life, that every aspect of your life is a choice. There are default choices. You can choose to sleepwalk through your life, and accept the path that is laid out for you. You can choose to accept the world as it is. But you don't have to. If there's something in the world that you feel is a wrong, and you have a vision for what a better world could be, you can find your guiding principle, and you can fight for a cause. So after this talk, I'd like you to take a little time, and think about what matters to you, what you believe in, and what you might fight for.

The Passionate Programmer[3] had a similar point throughout the book. Pg said similar thing years ago on his You Weren't Meant to Have a Boss[4].





* Expose APIs for developer to hook into firefox and reload pages or parts of pages (i.e. reload changed JS/CSS file)

* Intuitive system for playing, changing, rewinding, and replaying JS files for more rapid feedback (see:

* Let me alter CSS / JS live (like I can with firebug) and then save it to the file if its local

* Implement some sort of system that shows link between JS events and the HTML they are bound to

The most inspiring of all programming videos would be this one by Bret Victor. The talk is called 'Inventing on principle' and changed my perception of how I think about and create software forever

This was amazing. Thanks for that.
Wow - that's amazing! Thanks for sharing that.

I found it very inspiring and has given me so many ideas already.

Feb 19, 2013 · 2 points, 0 comments · submitted by senthadev
Turning point talk. Must listen.
The Bret Victor presentation for those interested:

I can't help but smile while I watch.

I can honestly say that the best thing to have come out of this article was the link to Bret Victors talk on inventing on pricple - Thank you.
Thanks for singling that out. The specific demos of interactive coding/visualization were cool, but the end where he really gets into the general topic of finding a guiding principle and using that to change the world - was very, very well worth the time to listen to.
A is something HackerSchool can answer, given that they are paid by startups to recruit ( In addition, the participants range greatly in experience, so you can a lot more datapoints there.

B. There are different types of 'becoming powerful'. Given that you are self-taught, you may want to identify and fill some holes in your knowledge. Maybe you could go through SICP, Algorithms, learn about functional programming in scala, etc. I would personally try to find something really challenging to learn on your own that I've really wanted to learn for a long time. On your website, you mention doing predictions with twitter. Maybe you could go deeper into AI / machine learning. I'm currently going through Algorithms, and it's been a really frustrating / rewarding / mind bending time, and it's definitely shown in my code.

Powerful in the sense of creating new and innovating things seems to come more from ideology / beliefs than from using a specific programming language or framework. You might want to read more into Bret Victor and Richard Reynman if you haven't already.

Bret Victor's Inventing on Principle comes to mind:

Richard Feynman's approach to research problems is also really enlightening. Have 10-20 hard problems floating in your head, and as you go about your day, reading, looking, exploring, match everything against those problems to see if you can make any progress on them.


Thanks, that's a really awesome response. I'm grepping through the Victor article now. All the best.

>I view it as a Windows 8 ninja rapidly switching between all sorts of tasks I vaguely understand, and the relationship between the gesture and the computer's response seems hard to follow.

I find this aspect of Win8 (switching between Modern UI mode and desktop mode) bafflingly, appallingly bad. It's one of the shortcoming that personally affects me the least (because I never find myself needing to use Modern UI mode), but it is undoubtedly one of the most egregious design decisions.

In a recent conversation with my dad, the archetypal non-computer-guy, he said he wanted a computer with "idiot mode". The problem with win8 is that, while it has the simplified modern UI mode, I can't see it being comprehensive enough for really anyone's computing needs. So you end up switching back and forth between regular and modUI, which for a user like my dad is just a usability nightmare. Switching between both modes is vastly more complex than using either mode exclusively, but you're virtually forced into switching, at least occasionally. I mean, having chrome and IE installed on the same machine is a bit of a stretch to begin with, but when you have two versions of each browser, it's break-down-in-tears laughably bad.

I'm reminded of Larry Tesler's famous "no modes" activism [1] which I first heard about in Bret Victor's truly excellent "Inventing on Principle" presentation. [2]



> It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head.

Completely true. That is exactly the Bret Victor's point in "Inventing on Principle":!/LearnableProgramming

Programming tools (languages, APIs, IDEs) needs to reduce the problem you need to hold in your head.

For anyone who hasn't seen Bret Victor's mind-blowing talk, here it is:

Dec 02, 2012 · scottyallen on Notch trying jsFiddle
This would be a great demo to see running in a responsive programming environment, ala Bret Victor's amazing Inventing on Principle talk ( I want to be able to click on hex values and get a color picker that updates the demo in realtime, and be able to click on various magic numbers and drag a slider to change them.

Incidentally, Bret Victor's talk was the starting point for Khan Academy's CS curriculum that John Resign led (

Edit: I managed to get this running in, which does some of what Bret Victor was talking about (basic sliders and color pickers): Not sure why it's running so much slower though...

This "responsive programming environment" you speak of has been around for a really long time. Don't expect sliders and colorpickers to do cool stuff, but this should be a good jumping off point for you to start learning from:
Thanks, I'm plenty aware of gdb and debuggers:) (ex-google software engineer, etc etc) Go watch the video. Bret presents a very cogent vision for a dramatic improvement on most of today's standard engineering/design tools.
And here I'm going to point to Bret's later writing,!/LearnableProgramming. It's not about the sliders it's about the understanding. A good example is the first large loop setting up the texture.

    for ( var i = 1; i < 16; i++) {
        var br = 255 - ((Math.random() * 96) | 0);
        for ( var y = 0; y < 16 * 3; y++) {
            for ( var x = 0; x < 16; x++) {


If this was a first introduction to programming it would scare off many people.

My interpretation of Bret's idea is that it would be better to have the ability to highlight the section of the texture being written by each section of the loop. It's not the sliders & live editing that are most important it's about linking abstract control into meaning within the learner.

yes - that is also my interpretation - you mouse over the canvas, and the block of code that "lead" to the bit that you "highlight" in the canvas lights up so can directly navigate from the final output back to the source code (and vice versa).
Thanks for the livecoding link. I assume there's some overhead in constantly checking for and applying code changes - that's probably the reason for the lower frame rate.
it's not polling, its reevaluating code when codemirror triggers an event for text changing (which uses the dom underneath).

the problem is from calling setInterval every time the code is evaluated, leading to way too many function calls/second

Good point, I hadn't thought about the fact they might be polling for changes. Might be better if livecoding used an event based model to check for updates...
How do you suppose event-based models are notified of changes? Ultimately you are still polling, you're just abstracting it out of your higher-level design.
Or if it works at all like Scrubby ( which was on HN a couple days ago, it might rewrite all constants into global lookup table indexes, which surely wreaks havoc on performance.
Here is a version adapted for Tributary:

Press play in the bottom left to have it go, and scrub numbers/colors to your hearts content!

Part of the reason it slows down in livecoding is because of the way the original code uses setInterval, and every change reevaluates the code which polutes the scope and starts way too many threads going. I've added optional functionality to Tributary which gives you a run loop (using requestAnimationFrame) that doesn't polute anything.

Hope this helps!

Very awesome:) It's _almost_ fast enough to feel like you're modifying it in realtime on my macbook air. This is a great demo of what might be possible with this responsive programming approach.
although i have cursorily skimmed the article, it seems to be based partly on his excellent talk "inventing on principle", available here:
It's important to point out that was Bret Victor that created this concept from which Kahn Academy took inspiration from.

As Bret Victor says in his essay, live coding is not a new concept and he did not create it.

The current trend in live coding seems to have spawned from a discussion between two computer musicians (Fabrice Mogini and Julian Rohrhuber) in 2001, with masses of related prior art going back to Lisp machines, Self, Smalltalk, corewar etc.

Responsive live programming (not just code reload), which is closer to what Bret Victor is doing here, goes back to various visual languages of the 80s and 90s.
Like the ones I mentioned.
You didn't mention any VPLs. I would throw in a few...ThingLab, AgentSheets, LabView, Prograph, Fabrik, and so on. These were the original live languages.
Self is certainly one.

But why do you think liveness requires visual programming? I see them as pretty much orthogonal.

Separately, when I see "visual programming language" I see "unusual programming language". When language features become normal (like 2D syntax in Python/haskell), then we stop calling them visual. A great deal of visual features are just alternative ways of structuring text, ways of constraining syntax, or ways of constructing high dimensional (and therefore non-visual) graphs. To a large extent, all programming languages are visual.

Why would you call Self a visual language? It has an IDE, but the language is most definitely textual. Its only when you throw in Morphic does the line begin to blur, but you are back to text again if you want to write any code. Many languages we think of as visual are more structured or graphical (graphics baked around text); compare ToonTalk to Scratch! Most languages fall somewhere in a spectrum between heavily visual and heavily textual, but this is my own classification system and there is hardly much consensus on the topic.

Liveness doesn't require visual, of course, but that's where liveness first shows up in history (SketchPad, along with directness). I go into some of the history in my own paper on the topic (

I haven't actually used Self, but from reading the paper, discussion of embodiment, tangible objects, and direct manipulation makes it interesting from a visual perspective.

Personally I think all computer languages are textual by definition, and vary in the amount of extra visual support for syntax and more often secondary notation. The Reactable perhaps pushes beyond this limit by making proximity and orientation part of the syntax, but still is basically about composing textual symbols.

If we're doing that thing, I wrote a chapter on this in my thesis :)

[ For the benefit of any others, here's a link to Sean's preprint: ]

But that aspect of Self comes mostly from Morphic. Anyways, Self/Morphic were a huge inspiration on my own work. There are deeper distinctions between textual and visual; think a Van Goh painting vs. a book by Steven King. They say "a picture is worth a thousands words," but actually, the worths are not very comparable. Text is much better at expressing abstractions than visuals are, which is why most VPLs mixin some text (though their are pure VPLs like SketchPad and ToonTalk).

I skimmed your thesis a few months ago; lots of good work there! But I think we are a bit out of whack on our world views (arts vs. PL), which is why we might not be talking on the same page.

Thanks, I forgot about the DigitalLibrary link :p. If someone is just looking for related work, better to try (smaller download as it doesn't embed quicktime movies).

Yes we are probably talking past each other here a little, but I enjoy and respect your work on SuperGlue. Not having used Self I don't understand the distinction between it and Morphic.

There clearly is a distinction between textual and visual, but at the same time they support one another: text is made out of pictures, pictures can be described with text (e.g. svg). For me the aim of visual programming language research shouldn't be to disparage or get away from the composition of symbols, but to supplement that with mental imagery. As I see it, mental imagery and language are most valuable in combination.

I'll look into sketchpad and toontalk properly though, "truly" visual language is a fascinating area.

Self is a language, Morphic is a GUI toolkit/framework/library. You can play with Morphic implementation in some Smalltalks (I did it in Pharo) and even in JavaScript:
> His various essays, talks, and so on are just alternative "projections" of this thesis. This is a sign of clear thinking.

See for a well-known presentation about "inventing on principle". Fast forward to the 10:45 or 23:00 mark to see some interesting examples of this principle he follows.

Here's the link to the Bret Victor presentation where he talks about this concept:
Sep 05, 2012 · larister on Realtime Three.js Coding
Brilliant. I wonder if it was inspired by Brett Victor's fantastic talk 'Inventing on Principle' ( - it seems there have been many such efforts to break the barrier between writing code and seeing the effects since that talk appeared. Maybe it's just that the talk made an impression on me and hence I've been noticing this sort of thing more. Either way, bravo Mr Doob.
I feel that talk made an impression on many people. I think that talk made live editing "mainstream" and Bret "stole" the concept by doing a good show just like Apple does. It's been done for years but no one "bothered" making a good show/product that wowed people.

From the top of my head (fluxus) [1] and impromptu [2]. And I bet every game company have their own live editing tools.

Anyway, </rant>.

What inspired me was this video of Iq's live coding setup [3] from last year. Months later I made a webgl version [4] to help spread glsl know-how. Then doing the HTML/CSS/JavaScript one was just natural de-evolution :)





Not to forget JSbin that has been here for a good 4 years now and many other live editors like it.
I met with Bret Victor for lunch while visiting SF a few years ago and I specifically argued against visual programming languages making anyone able to program. I mean I know that some people are more inclined to think in blocks and visual metaphors (Hell most programmers draw out ideas constantly cause we do too) but any sufficient program eventually gets complicated enough that visual programming kind of breaks down unless it gets more and more abstract to make reusable components and modules that you can navigate too etc. I pushed at the time and I'm not even sure he remembers at this point but for augmenting text based programming and making what's happening more visual and real-time. Which seems to be some of the direction he's taking which is combining his great ideas in visualization with traditional text based programming environments. I was also a huge fan of Javascript as the lingua franca despite it's deficiencies because web based IDEs and examples were inherently so much more shareable than code you had to download and try (There could be ways around this such as a desktop repository of code viewer, but that's a friction point to people actually checking out demos/examples interactively ala JSBin as such.)

I'm personally loving what Kahn academy is doing that John Resig credits Bret Victor's talk on Inventing on Principle ( as a major inspiration. See article where he announces and explains their in browser interaction learning of CS course material:

In closing to name a view limitations of most visual programming languages: the naming problem (Most parts of your system need to be named in order to be able to talk about them), text based is stronger at this. Instantiation of reuseable code is pretty abstract to do visually. Eventually all programming gets complicated enough that text based approach really is easier to work with. Not to mention all the tools you can't leverage comparitvely to text based such as version control, REPLs, etc. I guess I think visual programming is idealized and people are spending all this time learning something that isn't as useful to know in the long term compared to traditional programming because all the important platforms have much richer support for text based programming (iOS, linux, C/C++ for games). But combining visualization of code execution is the perfect balance and would lead to basically replacing much commenting with an actual intuitive visualization of runtime complex structures/state. And definitely real time feedback of tuning /visual parameters is great. In the game industry all of this is very standard and I do feel there is a little more awe for his work than would be given by your typical graphics, art tool, or demo scene programming devs. Most game development toosl for say level editing and animation are all highly visual and real time interactive. Same goes for any serious AI dev they have debugging tools for visualizing all planning for entities communication, path planning, animation states, and more.

Anyway, just my thoughts. Still think Bret Victor is one of the most compelling thinkers in this space.

Just listened to a Herding Code interview with a guy who was using APL to get domain experts programming.

He had a very interesting and elegant solution to the problem: You let the domain experts take charge of implementing their domain logic. But as soon as you hit a point where what they're doing needs to be shared with the rest of the company, you bring in a software engineer to sit down with them and review the code. They take charge of making sure it's robust and reliable, and work with the domain expert to refactor it into something that will be more maintainable.

That seemed like a reasonable solution to me. And the thing that was striking was that he wasn't doing it with any newfangled visual languages or anything like that. It's already being done successfully in a business environment using APL.

Intuitions and anecdotes are fine, but there is actual research on visual programming languages, as well as on computer science education.

Visualizations, animations, and metaphors do help beginners learning programming and understand programming concepts. Scratch is currently probably the most well known tool for beginning students to use for programming (used with kindergartners all the way up to college freshmen).

Some people are helped by visual metaphors. Others learn by hearing; other by reading.

And then there was that thread about some people never, ever 'getting it' and being as hopeless after a semester class as the first day. I've even met folks who, after years of computer classes, still hadn't figured out that code is executed in sequence.

Actually a lot of research over the past few decades has shown there is not really evidence for 'learning styles' - that one person might be a visual learner, and another an auditory learning, and so forth.

Learning isn't just about sensing (hearing, viewing), anyway, it is more about action. What are the students actually doing, and what can students do with a particular tool. Actually everything we perceive is tied to what we do (see: enactivism, embodied cognition, ecological psychology).

Many students aren't 'getting' programming in CS classes partly because it is not taught well (if instructors switched from lectures to active learning techniques, student retention and learning might double or triple, based on research in other domains), partly because the tools themselves are not designed especially well or are not designed with beginners in mind (including python and java), partly because it is often taught devoid of any context (see, situated learning and situated cognition), partly because of low student self-efficacy (what you mentioned - thinking they just can't learn this stuff), and tons of other reasons.

Oh come on - I personally know people who've hired readers in college because they absorb more efficiently through hearing it spoken aloud. Others despise pictures - they want written descriptions. Some the other way around.

Rationalize it any way you want - they learn faster and better one way than another, measurably.

And about bad teaching: the whole class gets it, but a few. The teacher is clearly not addressing their needs, but they are also clearly not doing it 'wrong' - many do understand just fine.

It embraces this concept:
Hey thanx, it's a nice talk for sure :)
All ideas are evolutions (or sometimes rehashes) of old ideas. It's a part of progress.
Having good competition is a necessary part of progress. You can always stick with emacs or the (entirely) OSS alternatives.
Light Table will be released open source under the GPL - just like emacs.
Have you considered LGPL or dual license? GPLv3 will restrict even your own future work involved the product.
I believe they must be planning on using using a dual-license. Quoting, "the core of Light Table be open sourced once it is launched, while some of the plugins may remained closed source." Source:
Correct, it'll be dual licensed.
Aug 17, 2012 · FrojoS on Light Table reaches 0.1.0
Looks cool! When I first saw it I thought you where this guy: Bret Victor - Inventing on Principle

Planing to support Octave/Matlab at some point?

Aug 17, 2012 · vecinu on Light Table reaches 0.1.0
I'm not sure if Chris or any of you guys have seen this video but it is exactly what Light Table is about to become (perhaps more) and that makes me very excited.

Here's the blog post where Chris first talked about Light Table (before it was called Light Table)
Oh my. After re-reading that blog post I remember seeing it on HN before. My apologies.
I was at this conference (CUSEC 2012[1]), and he (Bret) gave a truly awesome lecture.

Also it was my first conference ever, so it's even better.

[1] Canadian University Software Engineering Conference, in Montreal.

I managed to make it to CUSEC 2011 but not 2012. Looks like I missed some really great presentations. It's unfortunate when this conference is in another province.
Chris started work on Light Table _because_ of that video. So be excited :)
This is not unlike Bret Victor's work - . Do watch the video, if you have an hour to spare, it's a beautiful demonstration of "programming by tinkering."
Don't miss the link to Bret Victor's lecture on responsive programming: . I found it to be very enjoyable and it further shows what is possible with this paradigm. [minutes 2-23 are most interesting and relevant]
Does JReisig's work support the Bret Victor idea of selecting the line of code and highlighting the pixels that it draws?? (shown at 8:00 in the Bret Victor video)
While I enjoyed that video, it came to me as a bit of surprise that this style of programming is being "rediscovered."

Anyone remember Morphic, Squeak, Lisp, etc? Emacs?

Lively Kernel is pretty darn cool too.

I'm not saying it's bad, I think it's cool that this style of programming is making a come back (and about bloody time I suppose).

The only thing I'm not certain of with this course is actually calling it, "Computer Science." Perhaps that's because I tend to agree with those who question whether it is indeed a science at all. However after watching a few videos and trying some of the exercises it seems to me to be a great way to learn how to program.

A great idea - it looks similar to the excellent NodeBox for Python ( I'm very much in favor tools that make experimentation faster and easier, for all the reasons that Bret Victor explains so well in Inventing on Principle (
I agree.

Tools which don't attempt to do too much are sometimes just what you need.

Wow. Didn't know about nodebox. I wrote a similar tool named info-beamer ( Its focus is livecoding for interactive OpenGL visualizations. Think about digital signage controlled by Lua. It was inspired by Inventing on Principle: I'm using inotify to reload the Lua code each time you save. Documentation is at
Gosh, what a horrible comment! The simple fact is that curl and wget's interfaces are bad, and everyone who learns to use them spends that 10 minutes. And then, if you're like me, respends that 10 minutes when I need to do something fancy again. If a new tool were to save 5 minutes (which this one does), that's 5 minutes saved on every use, which is probably a total of a few hours for me personally, and spread over the population of future users, is a few lifetimes.

Rather than admit that even incremental usability improvements are not only useful, but continue to pay dividends long after the tool is produced, you lambast the author and the effort.

Not cool.

P.S. You should watch Bret Victor again, talking about how much easier it is to crush an idea than to support it and nurture it.

Your comment is an ad hominem attack where you falsely accuse someone of making an ad hominem attack.
You know, I was about to defend myself, but you may be right. My tone of outrage at the slurgfest being wrong was itself rather wrong. If he didn't see the long term incremental improvements this tool offers, that's nothing to be outraged over. People make mistakes.

That said, I think it's a stretch to call this mistake of mine an ad hominem attack. It doesn't fit my normal understanding of such an attack - there was no name calling, etc. And certainly I didn't accuse him of an ad hominem.

Thanks for pointing that out. I made slurgfest's comment a proxy for slurgfest when I interpreted your comment, and that is indeed a stretch. I agree that neither of you were all that harsh.
curl and wget might not follow Unix conventions all that well, but from the look of it neither does HTTPie.

Thus the GP's point stands that this program offers little more than a stylistic change. And a bit of pretty printing, which you could (ideally) pipe into some syntax highlighting script or an editor to get the same effect.

Don't read the docs with this thing, for example, and you'd wonder why it defaults to JSON encoding and not the default HTTP POST format. And so the 'simple' version is now dependent on a trend and not the HTTP standard. In fact, even with a modern API I don't recall ever having to serialise my data before posting it. So why this?

That's a few minutes wasted on RTFM already. What else will there be?

Still, you pay a one-time cost of reading the manual, then the ongoing benefit of using a nicer UI. With cURL you pay the one-time cost of reading its manual, but also pay the ongoing cost of dealing with its unintuitive, verbose, and generally less human-friendly UI.

JSON encoding is a sensible default these days for a tool to be used by humans, though I agree there's a good "principle of least surprise" argument for defaulting to plain HTTP POST. It would also be nice if it had a setting between "interpret response as JSON" and "uglify the response", but OTOH those additional formats are good opportunities for user-contributed patches.

All the competing tools are not "for humans." Who are they for, then? If you don't see the negativity in that sales pitch (and your own complaining about other people's creations, which were also the products of hard work) then I don't think you are being honest with yourself.

If this tool actually didn't require me to go to a man page and read lots of flags (.... exactly like every other tool) then I might be more enthusiastic about its advantages. But I don't see advantages. I just see yet another tool. Well, that's fine... use what you want. But I don't agree that it is superior in any clear way, and that's really all I said.

People who are really capable can handle and learn from critique and don't require constant sugarcoating because their minds are more at the level of problem solving than ego defense.

curl's interface is a PITA for testing JSON APIs. HTTPie's isn't:

  http POST http://localhost:3000/person/create name="James"
The "for humans" bit signifies the author has taken care to simplify the interface for practical use, rather than for shell scripting.
Yup, I was excited to see that.

I have a text file with examples of testing different kinds of API calls w/ curl, and I have to refer to it all the time because the syntax is so easy to get wrong if I just type it out. I've also had to waste lots of time supporting other developers using our API, who got tangled up in the curl syntax in the examples I provide them.

Looks great, game changing in fact. It seems to be quite inline with Brent Victor's vision ( One thing I'd like to see stolen from his demo: Once you have direct visual feedback on what you're doing, it makes a lot of sense to have widgets for your style definitions, e.g. scales with handlebars and color pickers popping up when the cursor is over values with corresponding type. It's a great thing that this project is both funded and open source. Quite unexpected from Adobe tbh.
This is a very interesting talk.

Thank you for sharing with me. :)

In return, I will offer you two interesting non-sequiturs, because I don't have anything topical and a non-sequitur seems like it's worth half what something germane would be.


Bret Victor, "Inventing on Principle." First 5 minutes are terribly boring. Give him a chance; it's 100% worth it.


Damian Conway, "Temporally Quaquaversal Virtual Nanomachine."

It's as funny as it sounds.

Jun 13, 2012 · DeepDuh on Using unix as your IDE
Thanks alot for that link, it lead me to this very interesting talk by Brent Victor, as kind of a counter argument to that principle: And holy shit does he have a point. Many of today's programmers seem to be trapped in the thinking that the unix and vim principles are the holy grail, forever to be pursued, never to be changed. Isn't it time we stand up and reassess the tools we have? And I'm not just talking about the teleprompt generation tools like unix and vim, but also today's IDEs that have basically evolved as extensions to those tools.

I also recommend the following talk about "subtext":

That's a great talk (see also chris granger's "light table", inspired by it), but is an example of a key truth of tools: the right "tool for the job". Like products with usages, tools are more or less appropriate for specific usages.

IDE's are great for navigating huge codebases, and massive libraries with long informative names (intellisense), integrated debuggers that can step into libraries, refactoring tools, etc. The visual gui builders are also really pretty cool - and a wysiwyg example not that far from Bret Victor. They require less effort (and skill) for these specific common tasks.

Bret's use of time is great for games, but not appropriate for all programming tasks. There's been extensive discussion of light table (here and on progit), about how it seems more suited to smaller, experimental coding (not large codebases) - but this remains to be seen, as the tool's not yet available.

I use vim myself, because I'm writing parsers and related code, an example of pure code (non-library, non-gui, non-web), leaning toward the algorithmic, which vim grew up around and was shaped by. Vim/emacs are still the deepest most fundamental level of coding - but that's only appropriate if you need to be working from first principles. Most of the time, for most high-value development, you're not. I think that for specific domains, where custom tools can get some leverage, it's more productive to use those tools. Tool for the job.

You'll probably be interested in Light Table:
I would argue that very few of today's programmers really follow the Unix philosophy, but those I know who do would likely agree that our tools should be reassessed. But you seem to be conflating the idea of reassessing our tools and reassessing our principles. In my opinion the core principles [1] are eternal, however transient the programs themselves.


I'd argue that the tools (if they're 'good' in itself) reflect the principles with which they have been designed. And no, I don't think that these principles are eternal. We should look at the context under which these principles have been formulated or evolved, compare it to today's context, pick out the principles that still apply and throw the rest out. As an example, building small programs to do well defined, easily testable tasks and chain them together, is certainly still a good design principle. Strings as the universal interface, however, is not in my opinion, since it just doesn't reflect how most of today's UIs are built on objects - thus we have today's disconnect between the terminal and the GUI.
You believe that text as a universal interface isn't a good design principle because it doesn't reflect how other UIs, built upon completely different principles, behave? Is it not possible that it remains a good principle that WIMP GUIs simply do not adhere to? (Also related, "everything is a file.")
Unformatted text (as in text that doesn't follow a machine-understandable format like xml or json) is not a good interface today, I absolutely believe that. Imagine if "ls" would return an xml table that you could easily reuse in other programs, including graphical editors. Imagine that the OS could understand what every column represents and give it a name. You could do something like

ls | showtable in.modified in.filename --sort:1.

Of course you can do this today with sed, but in a very unintuitive way not easily accessible for beginners.

Jun 12, 2012 · hugs on Coming up with my best idea
The only thing not mentioned is the variability of time scale. Sometimes the idea process can take years. For example, it took Bret Victor 10 years to find his ideas about UIs. ( ) For truly world-changing ideas, 10 years is not uncommon. Steven Johnson explains this as a "slow hunch" in his TED talk --> "Where Good Ideas Come From" ( )
Very good point. I was lucky in that case with CPU Wars as it took me around 2-3 weeks.
I don't want to talk for Chris Granger, but my intuition tells me that the features you listed are things he considers to be the baseline for a modern editor and are not the true reason he's building Light Table. I think his goals are more about making a real product with the capabilities of the demo IDE Bret Victor showed in his Inventing on Principle talk Eclipse is nowhere near this today, and perhaps it never will be. I'm backing Light Table because I think Chris has a shot of getting there.
May 10, 2012 · tlrobinson on Recursive Drawing
Very cool. It's a bit reminiscent of Bret Victor's concepts:
I like the idea in your Edit. If you manage that, you're on a winner. I'm not technically astute enough to have a serious opinion, but intuitively, it makes sense that a dev environment (particularly using tools like VIM and TMUX) isn't far away from what Heroku is already doing with virtual machines. People are always bunging on about how to develop using an iPad - that's clearly the way to do it.

Don't agree on the plateau so far as dev tools are concerned. Would be surprised if you haven't come across Bret Victor's ideas ( In my view, implementing those principles could really change how things are done. Can't wait to see what he comes up with over the next few years.

As to solving the core problem for now: the only solution is to just be really opinionated so far as beginners are concerned. Reasonable minds can differ on textmate/vim etc, but just showing students how to setup one solid set of tools on windows or mac (and more importantly, explaining it) would be a hell of alot more than is already out there. :)

I think the author did not really get the motivation behind the LightTable concept. For those interested, it was this talk that inspired the guy(s):

It's about the instant feedback during development as opposed to the classic change/compile/reload cycle.

Especially for concepts it's important to understand the intention rather than picking on it point-by-point (which in itself, while true for the most part, seems rather pedantic to me).

Honestly, I've been aching for this to become a reality ever since I saw that talk.
Obligatory mention of "Inventing on Principle" by Bret Victor ( which explores a lot of similar turf. With Circa though we get to have these things today though, and with C integration to boot. Great work.
I hope that you incorporate some of the ideas Bret Victor has been advocating. He might even be interested in helping directly.

If you're not familiar with him or his work, here's a good start:!/KillMath

Light Table was actually heavily inspired by BV's work by his own admission
You would make Bret Victor proud! For a slight chance you have not seen this; check it out for additional inspiration
This reminds me of Bret Victor's presentation He presents a few demos with similar concepts and a great talk nonetheless.
Apr 08, 2012 · ramblerman on Notch live coding 0x10c
relax uncle bobo ;) I'm a general proponent of testing, but this is a game and as such the feeling is more important, not everything is capturable by tests.

Notch is creating right now, watch "inventing on principle" which explains the importance of immediate visual feedback.

Also give him just a "little" credit for minecraft

Yes, i dont mind that notch is writing code without tests.

I just dont want anyone else to think it is a good idea for them :-)

Apr 07, 2012 · phillmv on Notch live coding 0x10c

>When building the engine, Notch wrote a function which would continuously pan the camera around and clip through the walls and keep the view on top, so he could make changes to the code and see the effects they made in real time. I’m used to testing by writing a function, building it, installing it on the device I’m testing on, and then seeing the result, which can take up to a minute at a time, so it’s easy to see how HotSwapping could save a lot of development time.

and two,

Mar 25, 2012 · sounds on A Game to Make Games
Reminds me of the 'Inventing on Principle' talk:
o/t is a really wonderful concept (and would be even better if I had a larger-than-13"-screen :-) Reminds me of the editor used by Bret Victor in his presentation

on-topic... the technique is interesting. What kind of real-world applications can we expect?

Mar 18, 2012 · loup-vaillant on Why software sucks?
How do you measure your productivity? One would naturally tend to count the number of lines changed, added, maybe removed. But they are a poor proxy. What really matters is the value brought to the customer, and the cost of this value to your company. These are obviously very hard to measure at the programmer level.

I think the important question here is, does IntelliJ help you simplify existing code? Do you routinely simplify existing code? Does your team routinely simplify code? Or even better, does IntelliJ help you write simpler code in the first place? Meaning, is code written with IntelliJ routinely simpler than code written with Eclipse or Emacs?

My experience with IDE overall, is that they are of tremendous help for navigating complexity. On the other hand, they are of very little help for reducing complexity. (You cite the method renaming as an example, but compiler errors keep track of broken references just fine)

Regarding the REPL, it's not the REPL itself which is essential. It's the tight feedback loop. There are other ways to provide such a loop. Some of them are much, much better than REPLs:

If you have not watched the talk (, I highly, highly recommend it. It's a very worthwhile and inspiring hour. In it Bret Victor ( discusses living life according to an overriding principle. For him, that principle is that creative tools should offer immediate feedback. He demonstrated a number of software tools to that effect: creating computer art, games, algorithms, electrical circuits and animations by seeing the effects in real-time as you code them. The link is an implementation of one of his demos.

But more important than his particular example is the general theme. Having a principle, which is a specific, actionable thing wrong with the world (other examples from the talk: Larry Tesler and modal computing, Richard Stallman and non-free software) is what allows you to have the biggest impact. It's being able to look at something in the world and ask yourself: does this match my principle, and if not, how can I fix it?

I had the same reaction, the talk was amazing. And for me, it finally made it clear how someone can do something as hard as a startup and not give up: it takes belief in a (time invariant) principle.
Does Bret Victor write all those things himself? They are staggeringly awesome. I am now suffering from a major inferiority complex! This totally lit a fire under my ass.
That talk was mind-blowing. Was there any good discussion on Hacker News?
Yep, it was on Hacker News. Here's the previous discussion:

My favorite (paraphrased from audio) quote from presentation specific to principle of immediate feedback:

"I can make these changes as I think of them. That is so important to creative process. If there is any delay in that feedback loop between thinking about something and building on it, there is this whole world of ideas that will just never be. These are ideas that we can't think."

This principle is one of the best things about learning CSS with modern tools (Firebug, Web Inspector etc): if you wonder why something works, or how it could work given different values, you can just change the values live and see what happens. Firebug allows you to click in any value in CSS, and use up/down arrows to continuously vary it (for non-numeric properties, this scrolls through all possible values).

This enables a style of self-guided learning involving forming a mental model of how particular bits of CSS work, playing with them until they break in expected ways (validating the model) or unexpected ways (prompting more experimentation or a visit to documentation, and subsequent improvement of the model).

I can also attest to the fact that live web page prototyping is a fun way to impress non-coders/non-web-developers :)

Comparing creative works built using a slow-feedback model versus a fast-feedback model is also interesting. With music, fast feedback would be playing an instrument directly; slow feedback would be putting together the output with a sequencer or drum machine, or writing it on paper to be played by an orchestra. The fascinating bit comes when you get sufficiently advanced practitioners of the art of slow feedback - for instance, composers who can hold an orchestral score in their head and imagine how it will sound, essentially having built a sufficiently advanced mental model that they gained a fast-feedback loop within their imagination. Does this suggest that for any given domain, even if there are obstacles in the way of fast feedback, that someone will eventually always be able to transcend the domain's limitations... or does it suggest that if we had better ways of communicating an entire orchestral score in realtime to an orchestra, that composers would generate even better works?

Really cool. This reminds me of Bret Victor's talk where he stresses the importance of seeing the effect of your code immediately (

It's not clear from the description but it would be great if it could immediately render whatever Core Graphics code I was writing, as I was writing it, much like this in-development tool ( which popped up in my Twitter stream a couple days ago.

What Bret Victor showed in his talk was quite amazing. It really opens up one's mind to what all is possible and what can be changed.

The Core Graphics video is interesting. Live rendering like that can help developers see what they are actually coding. The whole compile and test cycle just breaks the chain of thought which goes on while coding.

this is pretty cool. it's very close in philosophy to bret victor's last demo at cusec
Thanks, will definitely see the video.
I can relate to where you're coming from. When it comes to the motivations that drive some engineers (vs. the ideals that ought to drive them), you'll probably like the recent talk by Bret Victor, "Inventing on Principle" (

You (correctly) point out the places where capitalism comes up empty, if capitalism is our implicit system of determining the worth of goods and services. Apart from the environment (which seems unaddressed by the major economic models of the world) or the other causes you mentioned (unaddressed by capitalism, at least), I suppose it's fine to rely on the adequacy of money as some measure of the wealth we add to the world (

Even if the world is being eaten by software (, the transition to using software happens fastest through startups, I'm coming to believe. I used to work in a life-sci research lab, and there's just an exponentially growing divide between data growth and the tech resources to handle it. NGOs and government can be disorganized and unmotivated, so working for them is not necessarily going to be the best use of your engineering talents. But that might be aside your point, i.e., try to work towards noble goals.

Lastly, and most importantly, I find the model of the Aravind Eye Hospital as truly inspiring and business-model bending: a company set up to help the ones who are the _most_ in need. The ones who can least afford it. And yet in the process, generate income that goes back to serving and accelerating the mission. _This_ is what "social enterprises" ought to be:

Thanks! Interesting stuff. My point is actually broader. I don't want engineers to be inspired by nobler things - I just want them to be inspired by bigger things. They may want to enslave everyone on the planet - that is a big goal indeed - and though I believe most will try to do good rather than bad, first they have to learn to think about the why before they start thinking about the what and the how.

The what will be cooler gadgets and "increased productivity" or "streamlined processes" only if the why is money. Money is perfectly OK as motivation; it's just so... pedestrian.

Mar 06, 2012 · aaronsnoswell on Interactive Canvas
I've developed an alpha version of something like Brett Victor's interactive canvas prototyping tool, see Feedback and discussions more than welcome!
Mar 05, 2012 · 3 points, 0 comments · submitted by kjbekkelund
This is just one segment of Bret Victor's wonderful presentation "Inventing on Principle" - see the whole thing at
Mar 01, 2012 · Detrus on Pretty Lisp
I think it is a lack of creativity. Also a lack of serious attempts and minimal refinement in successful attempts like labview.

Take the simple case of naming. In plain text, the name of a function is its unique ID, more or less. Some language cultures love long descriptive names like BattleResourceMediator.getMediatorInstance(). Well such names can be broken up into tags. [Battle Resource] [Mediator].[get][Mediator][Instance]. Then when you don't need to know it's a mediator instance you'll see [Battle Resource].[get]. If you need to see what's a mediator and what's a factory, turn on some deeper editing mode and swim in verbose boilerplate.

You're not going far from text, just augmenting it with simple ideas we use in bookmarking. You can go further, add tags to sections of code to rate and label it as readable, hand optimized, quick & dirty, reviewed, etc. Simply a better UI for documentation, so in a zoomed out view of a project you can see at a glance how much is hand optimized.

Also watch this video and notice the sorting code walkthrough. A simple case of refinement where you put output side by side next to the code and format it properly. We'll need a lot more refinements like this, which means more attempts, more creativity.

Mar 01, 2012 · Detrus on Pretty Lisp
We have the systems we have now because we used the same medium for thousands of years. To create new expressive mediums that take advantage of computers will take careful design and iteration, just as alphabetic text went through various handscripts like cursive, torturous to read German blackletter and settled on

Then we went to san serifs (like here on HN) and then to monospaced code fonts. It's a long line and a lot of work by designers.

Adding to this medium will also take a lot of work. An essay can be more expressive when various ideas in it are turned into visualizations. Writers of long novels use special writer software to keep track of which characters interact with what others, to create family charts, friend charts, event timelines, etc.

These don't replace text, they augment it. And it would be interesting to have a macro view of the book through such tools for readers someday.

Not every attempt reduced the expressiveness of code. Syntax highlighting is graphical. Labview is graphical. Short compile cycles so the programmer can see what he's doing is graphical. Great demo of that here

Just because this particular attempt at pretty lisp leaves much to be desired doesn't mean we should stop attempting. Simple programmer tasks like naming can be improved if we move away from plain text as the medium, more detail here and

Yes, to be more clear, I should have said all the attempts to replace code with some kind of a graphical representation, ends up reducing expressiveness.

Augmenting the text with graphical representations is a wonderful idea, that IDEs already perform in many ways, with many more yet to be discovered.

Feb 29, 2012 · elangoc on JavaScript at Khan Academy
I'll go out on a limb to disagree with most of the comments here and say that I think JS seems like it could be very effective. The Stanford CS101 course page has already implemented decently well:

The language you learn doesn't have to be the language you end up using, or using to learn CS. It just has to get you off the ground.

So many people get turned off from a subject when they "don't get it" at first, so really, the challenge is providing the least painful intro to programming. Personally, my first languages were Logo and Pascal, and since I almost wrote off programming before Pascal as being too hard, I'm glad I saw C++/Java only afterwards.

One thing that enamors me about the JS approach is that it reminds me a little of Logo -- not only are the results are very immediate, but the visual output gives us a constant second avenue of insight into what we're doing. I'm sure many have seen Bret Victor's talk "Inventing on Principle" (, and he underscores the benefits of direct feedback to what we're doing. I have a friend taking CS10 at Berkeley this semester, and the Scratch-based environment also seems equally cool.

That being said, I don't use JS much (haven't really touched in it 10 years), but I believe it when people say it's (still) horribly irregular. In that regard, it might be on par with some other scripting languages (e.g., Ruby). So the distinction to be made here is that JS might be easy, but (as we can see) not simple.

As people who program seriously, we need simplicity in a language in order to build up large apps that we can easily reason about and don't bite us in every corner. (Note: simplicity in a language doesn't necessarily mean it's going to be easy at first.) But I wonder if we've been so used to programming that we forget how it can be hard to learn at first, and we're just ruling out the easy approach, which would exclude just what some newbies need.

Simplicity in a language is great.

JavaScript is actually a very simple language modulo a small set of irregularities. Most of these irregularities go away with "use strict", which is basically the modern version of JavaScript anyhow. (And even more improvements are in the pipeline with future versions, which you are free to use for projects outside the browser!)

While there are several reasons why I would not choose JavaScript first for "serious" programming (although it's pretty high on the list), these reasons are shared by most of the other popular languages like Python, Java and C++. (I also think all three of these languages are more complex than JavaScript.)

If people who programmed "seriously" actually cared about simplicity and reasoning about code, we'd see much more Haskell in the wild. But instead we see the three unfortunate languages I listed above: Python, Java and C++. (Rounded out with mostly similar languages.)

I totally agree. My statement about simple vs. easy is actually a weak attempt at restating some of the principles that guided the design of Clojure (from Rich Hickey's talk "Simple Made Easy": JS is approaching big apps with Node.js, and Clojure is approaching browser JS with ClojureScript... not sure how it will play out.

What are the current trends in language use? Are people moving away from Python, Java, and C++? and if so, to what?

Looks great! Have you looked into trying to do any realtime feedback like in Bret Victor's recent talk? (amazing watch - the circuit part is ~23 min in)
Link to CUSEC talk :
Wow. Amazing talk.
Consider the values that you seem to take personally, the ones that you can't leave alone, even when it seems to make sense to set them aside. What are the things that you can't leave undone, that you can't not do?

Most people have a few closely-held, somewhat abstract values that stay with them even though they may get expressed very differently in various contexts.

Look at Bret Victor - Inventing on Principle ( He's talking about himself and others who eventually got very specific about why things are worth doing, for them, personally. When people understand that, they get very inspired and very productive.

So, why do you value a stable, quality product? And why do you value choosing the right stack? Maybe it's the elegance or power of using the right tool for the job. Or maybe you enjoy understanding technology deeper than the people around you. What other values are persistent for you. Whatever they are, look for more ways to express those values and to share them with the world.

It's sometimes long hard work to learn this about yourself. And as you do learn, you'll know which projects can be satisfying and which to say no to.

Vision and principles is a good method. This is a great talk about that

Covers the inventions at Xerox PARC, how they were motivated by removing modes. Then how Brett Victor of Kill Math fame comes up with his ideas. They all stem from a single unifying principle.

First world problems though and no concern with markets and customer validation.

Feb 25, 2012 · Geee on Kill Math
Have you seen this Bret's talk about his principle ? It's not really about simplification of things.

The principle is basically "to see what's going on", or "to have immediate connection with what you are doing". Basically when you design something, you have to try to think or simulate in your head what's going on. Bret wants to remove that barrier so you don't have to think.

There's some great examples in the video where the principle is applied to graphics, game design, electronics, programming etc.

Feb 25, 2012 · mythz on Kill Math
I pretty much read everything Bret Victor produces these days given he is responsible for one of the most insightful presentations I've ever seen:
Thank you for this link. I have a feeling it will change my life.
The best talk I've ever seen.
Thanks, I did not realize it was the same guy, I still have that video in watch-later.
I was at that talk and, let me tell you, there was magic in the room:
In a recent talk, Bret Victor gave a demo of an animation program where you could just click on an object (a leaf in his demo) and drag it around, and the software would record the object's position as a function of time. (His demo actually had the software on an iPad.) It was beautiful, direct, intuitive, and now I want it in all animation software!

Video of his talk:

Bret and I actually overlapped at Apple a little bit, his work has always been insightful and amazing.

His first demo also is very similar to our own HyperEdit ( though he takes the concept to the next level.

Feb 20, 2012 · lhnz on Online Python Tutor
Have you seen this presentation by Bret Victor [0], as he touches on user experience in writing code? It seems like it might improve your product. :)


Feb 19, 2012 · DanielRibeiro on Online Python Tutor
If you found this awesome, Bret Victor will blow your mind (the coding tool is the third example):
Thank you. This guy is unbelievable. He blows my mind every time he publishes something.

I want his editor.

I've emailed him asking for it! Gregory Bell asked him on twitter as well:!/worrydream/status/169497569855143937

No response so far.

I don't think he will answer positively. It's only a demo and somehow I don't see him releasing an unfinished program. But I can imagine other people picking up his ideas.

Actually there is someone in the Vimeo comment thread who has started a live canvas editor(1) inspired by one of the demos.

Edit: (1)


This is simply amazing.

I hope this guy makes millions off his work. For something this revolutionary, he deserves it.

great link! geez, this reminds me why i like to use web developer tools so much when i'm adjusting my CSS, HTML, and JS. honestly, a lot of my ideas come from real time editing. i love making small adjustments to my values and getting to see those take effect instantly.
Amazing! His ideas and creative intensity are so refreshing.
have you come across any such real-time tools for Wireframing/Mockups?


Mind blown. Not just from the coding tools or the other examples, but the combination of those with a simple and powerful personal philosophy.

I can't believe the original link (submitted 5 days ago) has gotten so few views/points.

I like this. A lot. It reminds me of Bret Victor's talk on being able to see what you're changing in a design live (

The UI could use some work though, it's cluttered.

Feb 17, 2012 · gry on Basecamp Next: UI Preview
It is. It's also one where you don't need to remember context.

Bret Victor describes and demos this in his presentation "Inventing on Principle." []. BCX is better than a page-based back button. By the way, back still works.

Your question--and Teller's advice about the arts--dovetails with Bret Victor's excellent talk, Inventing on Principle, recently released from CUSEC [1]. He starts by blowing you away with demos of software he's built, but then he backs up and reviews how he got there and why. His self-discovery process involved trying, making, and experiencing lots of things over a difficult period of ten years. That process eventually gave him the perspective to find commonality in things that make him react strongly. From there he found a principle to live by. For Bret and other examples he cites, it's not about domains and returns. It's about having a distinctive principle or cause that guides your decisions and approach to domains.

See also: mbarnett's response. I can't say it better than that.

1 -

Feb 16, 2012 · DanielRibeiro on Unix as IDE
I used to agree with this, but my mind changed after seeing Brent Victor's presentation[1] on how code and result can be integrated. Even Smalltalk's ambient can't compare (which is understandable, as it is much older).


Feb 15, 2012 · 1 points, 0 comments · submitted by jacoblyles
Feb 14, 2012 · 22 points, 1 comments · submitted by t-crayford
How soon can we expect to see an editor like this that is robust enough to no longer be a proof of concept?
Feb 14, 2012 · 233 points, 19 comments · submitted by jashkenas
For anyone who may read this thread and think the talk is just a showcase for Bret's design and coding skills, it's not. The demos are awesome in their own right, but they exist to set the stage for the rest of the talk.

"The purpose of this talk is to tell you that this activist lifestyle is not just for social activists. As a technologist you can recognize the wrong in the world. You can have a vision for what a better world could be. You can dedicate yourself to fighting for principle. Social activists typically fight by organizing, but you can fight by inventing."

He explains how he got to where he is, gives other examples from computing of people whose work transcends a skill or craft, and walks through how you can work toward that if you want to.

Yeah, this right here is probably the Mother of All Demos for this generation. Truly stunning. Every time Bret posts something I think he's finally released his masterstroke, but then he one ups himself the next time. Can't wait to see what he does next.
Bret is one of the smartest, most insightful designers of our time.
Might I note that spreadsheets have immediate feedback. They also enforce a pure functional style (which you can break out of by bolting on a script written in a completely different language. Makes it possible to mutate state, but you have to do it consciously, and it requires a context switch).

Both of these are great features for programming. I sometimes use a spreadsheet to "mock up" a function, if I think the function is amenable to such a thing.

Unfortunately, spreadsheets have pretty severe limitations as general computing environments.

Unfortunately, spreadsheets have pretty severe limitations as general computing environments.

I'm working on this problem, so comments like this are like crack to me.

Please say more. What severe limitations? Can you imagine a more powerful spreadsheet that didn't have them? If such a spreadsheet existed, what could be done with it?

Let me try and cover most limitations by saying this: a spreadsheet should basically be an interface to a Lisp interpreter. The ability to define new functions (within the spreadsheet itself) is the biggest thing, I guess. But if the spreadsheet is just an interface to Lisp, you get everything else, too.

Another problem is that you're stuck working with tables. Tables are great, but I want to be able to edit other data structures in a spreadsheet-like way.

Especially trees. Trees are everywhere. Mathematical functions, HTML, code in pretty much every programming language, XML documents (which include Word and Excel). All trees.

Joel Spolsky claims in his Trello post ( that Excel is about simple creation of tables, and great mass-appeal products are about the data structure they revolve around.

I think trees are underserved. I want to be able to write a tree, not 2 + 4 * 5 / 6, or <html><head><body></html>, or (((()()()))()())))(()()()())).

Plus you don't have to give up tables. Making a table out of a tree is easy (think HTML tables). Modeling a tree with a table is more clunky, in my opinion.

I think that a well-designed product along these lines could drag millions of "non-programmer" spreadsheet users all the way to Lisp.

I think that a well-designed product along these lines could drag millions of "non-programmer" spreadsheet users all the way to Lisp.

I love you! Please email me. Address in my HN profile.

The ability to define new functions (within the spreadsheet itself) is the biggest thing

Agreed. There are others, but if you have functions, especially functions as values, you can build most of them. But it isn't obvious how to integrate "native" spreadsheet functions into the spreadsheet as we know it. (Even Simon Peyton-Jones co-authored a paper on this, to little avail.)

Joel Spolsky claims in his Trello post that Excel is about simple creation of tables.

Right, thereby implying that Trello is what Excel really wants to be for most users. I bet against that. I don't think there's a simpler tabley core struggling to emerge from Excel, I think Excel is the core. The spreadsheet is the local optimum, and local alternatives will either fail to attract users away from Excel and/or get sucked into the black hole of becoming spreadsheets themselves. Why? Because spreadsheets let users play with data in a way that nothing else does. Excel isn't static tables, it's interactive computation.

Of course, when they eventually add formulas to Trello, Joel will write brilliantly about how everybody needs formulas. :) But can you iterate a quite-different product into a general-purpose spreadsheet? I don't believe so. That's Greenspun city.

I think trees are underserved [...] Plus you don't have to give up tables. Making a table out of a tree is easy

Here we may diverge. If the spreadsheet is a UI for a dynamic table, what does the UI for a dynamic tree look like? Seems to me you're likely to end up with something quite different-looking, which will make it hard to appeal to Excel users.

Making a table out of a tree is easy (think HTML tables)

Meaning the table as a root node, rows as children of it, and cells as children of rows? Again, though, the UI won't look like a simple Excel-style grid if it needs to render all trees instead of only "square" ones. The danger here is that if you make something too abstract, you lose the non-programmer spreadsheet users, the great bulk of the audience. Your tree idea lives or dies on whether there's a simple, general UI for it - where "simple" means "seems simple to Excel users". And also, I suppose, on whether there's a natural formula language for referencing data laid out in trees. Data references in formulas are critical to the way spreadsheets work, and they're the hard part (other than that, expression trees are easy to compute) - and the way spreadsheets do it relies on the grid layout.

Modeling a tree with a table is more clunky

It is clunky, yes. I'm not sure how to do it well. When people lay out hierarchical data in spreadsheets they tend to use indentation to indicate parent-child relationships. Significant whitespace I guess!

CUSEC (the conference where this was filmed) is hands-down the best technology conference I've ever been to. If you're anywhere near Montreal, I'd definitely recommend that do what you can to get up there (it's only $100!) since every year they have amazing talks like this that remind you why you became a developer.
If you wouldn't mind - I'm curious to hear what some of the other talks you've heard at CUSEC were? This one is amazing and I'd love to make it up there some year if the rest are even half the caliber of this.
From the Vimeo page above you'll see a list of the videos on the side that have been published by CUSEC. Some ones that I liked are by Reg Braithwaite, Greg Wilson, Zed Shaw.

Some ones that aren't on Vimeo that I remember really liking were by Dan Ingalls and Giles Bowkett, not sure if they were recorded or not.

Incredible. So many unique and well-executed ideas in one presentation. It's almost too much to take in at once.

With the iPad animation part in particular though, I got the same kind of feeling watching that as I do when I watch the original "mouse" videos on Youtube. Very exciting possibilities to say the least.

It's embarrassing and inspiring how many orders of magnitude higher this guy is playing at. What a presentation.
Bret is always have some impressive ideas. I love his article and the way of thinking. He is the most insightful designer.
Brilliant coder. Really glad this talk is available! Thank you CUSEC!
Every time Bret makes a new essay I feel like I've completely missed the point about what matters in technology. It's a strange mixture of frustration and inspiration. Amazing video.
I had a hard time getting the essay on time and interactivity, but this killer presentation really helped it sink in and dial the frustration to inspiration ratio.
I love this.. It is truly a life changer
this is TEDtalk worth. Unbelievable.
This is so inspiring, especially after having read and followed some of Bret Victor's previous work. You can literally see the progression of his thoughts moving towards this, demonstrating that he really is driven by inventing along the principal of immediate feedback for creators.

HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ [email protected]
;laksdfhjdhksalkfj more things ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.