Sounds terrific. However, it feels like a lot of what they have achieved is marketing existing ideas that were already great, with improved packaging, but in a way that ultimately isn't practical.
Because truly plug-and-play components are an awesome idea. However they are not a new idea at all. As far as I can tell the real reason they are not more popular is because us programmers are worried we will be accused of being users if we use tools that are interactive. See Visual Basic 6 (which was an amazing system). Of course programmers do not realize this psychological issue exists and will not admit it is a possibility.
But in the context of Bret Victor's lab with the projectors and little pieces of paper, that puts plug and play components in a different category that makes them more palatable.
Also, projector based AR is much more convenient for people to demo than HMDs, but also not very practical for widespread deployment. But AR is amazing in general and this allows them a friction free way to demo its power with components.
But I think that multiplayer real-time collaborative interactive component based AR programming should definitely be a more common thing. It combines the advantages of all of those techniques. I also think though that all of those things are useful in lesser combinations. I believe a big part of the reason at least some of those things are not used more or more effectively is cultural or psychological rather than technical or practical.
The thing is the more you take advantage of components and interactivity the less you use the complex colored encoded text. That means programmers can spend a significant amount of time snapping together components and configuring them. Unfortunately programmers are not able to recognize this as programming. We have a feeling the more we do it the more we may lose our special incanter status and be classified as users.
> us programmers are worried we will be accused of being users if we use tools that are interactive. [...] Of course programmers do not realize this psychological issue exists and will not admit it is a possibility.
It would be nice if you explained what you even mean by this instead of just claiming that programmers who don't agree are in denial.
What programmer is embarrassed to also be a user? And programmers use interactive tools all time. REPLs, debuggers, editors, GUI design tools, and live-reloading web servers all qualify in my book.
Also keep in mind that when you stack abstractions on top of each other, the whole stack gets more brittle. So if you want me to use your better idea, it shouldn't abstract over the thing you're trying to replace.
To give an example: if you want to replace hierarchical filesystems you shouldn't build a thing that hides them from me, you should build a thing that doesn't use them at all. (This isn't a hard rule, sometimes exceptions are worth the trade-off.)
Understandably, this means changing things is a LOT more work than you're probably prepared for. Don't assume that we're only stuck in the past for bad reasons.
if you need any example of this type of behavior just look how "normal programmers" view labview programmers. most people completely snub their nose at labview "users" for not being real programmers and engineers (don't tell me they don't because i experience this constantly). in addition, labview's capability is often misunderstood by people who hide behind a wall of self-imposed bias. many times people are actually unaware of what is possible with labview simply because they don't care to know because it's not the real, hardcore, in the weeds type of stuff they were taught in school. meanwhile, people using labview to program windows, real-time high-performance, real-time embedded linux, and fpga systems (including cameras, sdr, etc.), all with the same language, are able to accomplish quite a lot. i fully concede that labview has many downfalls, but my criticism is based upon actual use of the language and tools and not via some uninformed bias. because of that, my criticisms don't necessarily overlap with those of the uninformed. and this is all relevant because when i tell people i use labview, you can just see any interest in my programming work leave their face, as i've become a simple tool user in their eyes.
this is a specific example regarding labview, but these types of biases exist everywhere, where engineers blind themselves to what is possible by the opacity of what was possible.
I wouldn't want to write a long letter on a piece of paper never mind software, it's not because I'm addicted to a fake status symbol it's because "reality" in the form of solid objects has limitations that software doesn't eg "a delete option". And the rest of vim. At Stone point you have to encode complex rules, and having a slider framework linked to moving a rock in front of a camera isn't going to help you write a compiler.
Because truly plug-and-play components are an awesome idea. However they are not a new idea at all. As far as I can tell the real reason they are not more popular is because us programmers are worried we will be accused of being users if we use tools that are interactive. See Visual Basic 6 (which was an amazing system). Of course programmers do not realize this psychological issue exists and will not admit it is a possibility.
But in the context of Bret Victor's lab with the projectors and little pieces of paper, that puts plug and play components in a different category that makes them more palatable.
Also, projector based AR is much more convenient for people to demo than HMDs, but also not very practical for widespread deployment. But AR is amazing in general and this allows them a friction free way to demo its power with components.
But I think that multiplayer real-time collaborative interactive component based AR programming should definitely be a more common thing. It combines the advantages of all of those techniques. I also think though that all of those things are useful in lesser combinations. I believe a big part of the reason at least some of those things are not used more or more effectively is cultural or psychological rather than technical or practical.
The thing is the more you take advantage of components and interactivity the less you use the complex colored encoded text. That means programmers can spend a significant amount of time snapping together components and configuring them. Unfortunately programmers are not able to recognize this as programming. We have a feeling the more we do it the more we may lose our special incanter status and be classified as users.