> The whole point is that it's a research project.
> It's a vision for the future.
Neither of these mean we can't or shouldn't be able to have discuss whether parts of it are good or bad, make more or less sense. Is it a vision of a future you'd want to work with/in?
> I also think these comments along the lines of "what about X" are unhelpfully reductivist/dismissive.
My first statement was "I think the overall idea here is really cool". The intent is not to be dismissive. But if you think the only acceptable reaction is unalloyed praise ... then why even have it on a discussion-oriented site?
I think the way of working being demonstrated seems like a great fit for some kinds of work and that trying to awkwardly shoehorn software-development to happen in their system detracts rather than adds to it.
> If you can think of a better way to make ephemeral room-sized computing work
... I think an IDE, a keyboard, and a projector are better than printing code blocks at a specific revision which is identified by a computer-readable id, and which must be given a new ID and a new printed page every time you want to try executing a new version.
Yours wasn't the only comment along those lines, and I was replying to the class of them rather than yours specifically.
I don't mean to curtail discussion or say that only praise is allowed. I just want to steer away from "gotcha" energy on a research project.
Ideas/discussion/critique are welcome! "This project is dumb because it does things differently than I'm used to" or "because it currently only supports digital changes to the physical paper" are less helpful. Part of the fun of a research project is trying weird stuff to see what feels better and what doesn't.
Again, none of this is directed at you personally or about your specific comment. I just noticed a trend of comments about the code editing experience that felt more like trying to dunk on the concept than promoting curious discussion.
> I think an IDE, a keyboard, and a projector are better than printing code blocks at a specific revision which is identified by a computer-readable id, and which must be given a new ID and a new printed page every time you want to try executing a new version.
You're making several incorrect assumptions here:
1. That you can't interactively try out the code as you're editing it.
2. That the system as implemented is the final vision of how the system ought to work forever.
From https://youtu.be/5Q9r-AEzRMA?t=150 "Anyone can change any program at any time and see the changes immediately", which demonstrates live editing the code and seeing the projected flow lines change color. So you can keep editing and iterating on the program, trying out your changes without ever having to print anything. Once you are satisfied with your improvements, you then "commit" the code, which results in the system printing out a new page with its new identifier.
And if any part of your expectations isn't how things work, it's likely because this is a research project and nobody has written the code to make it behave the way you'd like. Since Realtalk is built on itself, one would only need to make the appropriate changes to improve the system.
> It's a vision for the future.
Neither of these mean we can't or shouldn't be able to have discuss whether parts of it are good or bad, make more or less sense. Is it a vision of a future you'd want to work with/in?
> I also think these comments along the lines of "what about X" are unhelpfully reductivist/dismissive.
My first statement was "I think the overall idea here is really cool". The intent is not to be dismissive. But if you think the only acceptable reaction is unalloyed praise ... then why even have it on a discussion-oriented site?
I think the way of working being demonstrated seems like a great fit for some kinds of work and that trying to awkwardly shoehorn software-development to happen in their system detracts rather than adds to it.
> If you can think of a better way to make ephemeral room-sized computing work
... I think an IDE, a keyboard, and a projector are better than printing code blocks at a specific revision which is identified by a computer-readable id, and which must be given a new ID and a new printed page every time you want to try executing a new version.