Update criticisms.md

[vird]

[toinbis]

These changes seem only to be true if the visual coding environment is visual-only. On many cases there is bi-directional binding between the code and it's visual representation. By changing one, you also change another.

Take a look https://youtu.be/fQvWMoOjmQk?t=437 - enso visual language also has it's realtime bidirectional sync between code and visual editing.

[vird]

Not bi-directional https://youtu.be/fQvWMoOjmQk?t=260 Look at this moment. Created node, then moved by mouse. If nodes are movable then you need to store coordinates. Coordinates are not translated in code, so you can't reconstruct 100% correct original document having only code

[toinbis]

Might be that this example does not illustrate bi-directional. But the point is that you can't apply criticism to all the visual programing languages/ides/platforms.

You can analyse one specific visual programing toolkit and claim that it allows/does not allow you to have bi-directional state management between code, state and code+state visual representation.

Also, to give an analogy, code-only programming also would not have enough version control. Each keyboard click adds a diff. Another keyboard clicks adds a diff.. You only want to be reconstruct the state that has been commited to version control system.

Chances are I'm missing a point here, but intuitively I just don't buy the argument that visual programing has anything specific to do with being or not being able to be version controlled. Just my 5 cents.

[vird]

Might be that this example does not illustrate bi-directional. But the point is that you can't apply criticism to all the visual programing languages/ides/platforms.

And I didn't apply to all, and my point is mostly not about it

There is almost no generic version control systems with visual displaying of diffs

Even if you store document as code. Usually you can't properly display it as visual diff (the only known visual diff is github visual diff for stl https://github.blog/2013-09-17-3d-file-diffs/ )

[toinbis]

Thanks, @vird, for sharing the link. I do think I start to get the point.

And I'd still argue that there would be value of adding a sentence or two of context to your commit. Namely, to state it's criticism for visual programming compared to what. To the ideal scenario possible? Or to text-only programming.

My initial thought was that it's criticism when compared to text-only programming. But it seems you're generaly stating that most tooling is not capable of diff versioning, implemented same or similar to the STL example from gihub blog post you share, even though that's an important requirement and should be technically always possible to implement.

Thanks for interesting discussion!

[vird]

I've made some updates with more examples. I didn't like this new version because it has worse text to sense ratio (many repeated stuff which explains my position from different views). But I think you will like this version more

[toinbis]

@vird - many thanks. I sure do like the updated version much more. But mostly due to the fact that this is an interesting topic for me myself and I prefer a more detailed argumentation. I also think that this is really complex yet important topic and more context is needed to explain it.

Having that said, i'm just a regular watcher (not maintainer) of this repo, so it's not for me to decide how to proceed with this PR.

Thank you once again for sharing your point of view, I have really learned a lot in this discussion. Much appreciated!

[ivanreese]

Thank you @vird for the PR and @toinbis for the clarifying questions.

@vird I absolutely agree that this is a common criticism — and it extends to other "support" tooling around text-based programming too: find-and-replace, use whatever text editor you want, Unix's powerful tools that work with text, the ability to send code natively via email or SMS, and on and on.

The next time I take a day to work on this repo, I'll do a bit of cleanup on what you've written (and I'll take a look at the previous commits in this PR, since you mentioned that they were a little purer in their expression), and incorporate it into the project.

Thanks again!