Like you say, lack of source control is the biggest pain point.
In reality, it only works for "hello world" with 2 buttons. Anything non-trivial requires developers who are experts in Java, Javascript and GWT compiler/translator which translate JAVA to javascript. Debugging machine generated code was hell.
Having said that, GWT stagnated while the modern JS ecosystem evolved. GWT's debugger plugin died, and JS build and debug tooling kept getting better. React is a fundamentally superior approach to building UIs. And, while I'm biased, the React+Redux+TS combo is a solid toolset for building apps, and the ability to actually develop and debug code is way better than what GWT ever provided.
Just because some visual systems don’t have version control doesn’t mean they can’t exist. It isn’t like text-based diffing just poofed into existence. Someone had to build them, and even then they aren’t all created equal. For example, I use P4Merge to diff and merge from Git instead of using the poor UX of the built-in terminal tools.
I would argue that visual programming languages are much more ready to be diffed and merged than text since they usually already represent a graph.
One would need “universal visual language representation” file format if they want the visual languages to become as popular text-based ones are.
There are universal-ish formats for data (eg XML, JSON, etc). There are also sets of pretty standard operations for modifying data - for example, "insert", "move", "remove", etc. The same set of basic operations show up again and again for a reason - in ShareDB, Automerge, Yjs, etc. And you can use those operations to implement most applications.
I don't think semantic diff is ever what you want. Ideally you want your editor to capture the user's intent directly through the semantics of their actions. (Signal is lost reconstructing that in a diffing tool). But I bet visual programming could be expressed pretty well in a standard language of semantic changes. And then version control is something you could build on top of that in a pretty straightforward, and reusable way. (It'd be an awful lot of work - but I doubt there's unknown unknowns lurking out there.)
I'm trying to understand this part. Would you give an example of semantic diff losing intent signal?
You can’t tell what the users intent was by simply diffing the old and new contents. The right approach is to capture the users intent directly from the software that they use to edit the value, and then preserve that intent through the synchronisation system.
This problem is also easy to reproduce with edits on lists / strings which contain repeated elements.
Changing 999999999 to 1000000001, do you increment by two or re-type the whole number?
It is difficult to make users think in (invisible) state changes.
Small commits are all about trying to preserve an explanation of change intent - but they're not ideal because you can end up doing a lot of incidental code just to keep them actually working if they get merged to master.
Whereas looking at the sum of a big commit, you just get a mess which doesn't tell you much of anything unless it's limited solely to inserting discrete blocks.
Whereas ideally what you really want to know is "there's 37 actions replacing the use of variable Y with a call to function X being passed Y" and the types are the same in all cases.
The current products do have a bit of semantic knowledge, in the form of syntax highlights and function navigation, but those do not require full language understanding, fail gracefully if they are wrong, and often can be implemented with just a bunch of regexes.
This makes then writing a new text-based tool simpler (even if semantics is wrong, it is still useable). It also makes writing a new text-based programming language simpler (even though existing tools don't know my language's semantics, they can still work with the text including diffs).
I feel that the one-dimensionality of text makes merging and reasoning about diffs simple, because they are easy to represent side by side. To diff something like an image, or a graph, you probably want to see them on top of each other, however that makes it harder to see the whole.
I look at revisions of Keynote slides this way (side by side) via Apple's "Show Revision History", a feature I'm frankly much too reliant on. The only difference is that with code, editors actually highlight the changes between snapshots. Ideally, you'd want to add that.
Kind of a shame really since having a dependency solver as core part of the language structure sounds really cool.
Our first milestone was a speller similar to yours however we worked with MEAs rather than EEG. Small world!
Almost everyone that agreed are still there.
Great way to kill a career.
In my decades of experience there are of course many ups in no code, but as with any paradigm, the downs are highlighted the most and especially when you want to disrupt the text-based programming world that existed for almost a century now.
The major complaints about visual programming environment (backend) are:
1. Code is more expressive for experienced devs
Its true that code is much more expressive than generic graphical programming platforms for writing algorithms.. But how many of us write algorithms on daily basis?. What all of us do is glue various reusable pieces together to build the business logic. And for gluing graphical programming is actually superior - you can discover easily, dependent fields can be expressed easily etc. You need to use code in a properly designed no code system, but it's only 5% of the project. Now coming back to code being more expressive, if you look at algorithmic visual programming platforms designed for expressive coding like DRAKON (https://en.wikipedia.org/wiki/DRAKON), you can see that they are equally good or even better than coding.
2. No or degraded version control experience.
This is true as visual programs are still written to file as xml or json and there is disconnect between committing that vs seeing actual programs as graphs. This is a difficult problem to solve.
3. Incompatible or poor tooling
This is related to above point. Because visual programming tools need to distribute with a custom made IDE, the common tooling and CLI other available for generic text based programs can be lacking.
4. Hitting a wall
This is one of the biggest drawback I have heard from the devs so far. To be honest which programming platform have not made you hit a wall? In node.js you hit the multi-thread wall, in Java you hit the thread safety/performance(high memory usage) wall. In python you hit the performance wall. How do you solve it? Well in python you solve it using C or ASM libraries - and expose it to python. but you seldom hear a cry from python devs saying they reverted to C because python is slow or lacking.. Cos you learn to use the right tool for the right purpose. Similarly a well designed visual tool will let you do few things extremely well, but like no single programming platform can do everything extremely well, same is with no code or visual tools - for e.g. see DRAKON for writing expressive or algorithmic code.
5. Performance not on par.
Most of visual programs tend to not focus on performance as the priority is different. However this can be solved with compiling the graphs to native code.
When we built Codeflow, we tried to solve 4 and 5 and in our opinion we succeeded to good extend. 2 and 3 requires more effort from the vendor and the community (which is hard because every visual tool is unique). and 1 is possible but require more research.
One way to think about visual programming is this way - imagine a world where graphical vector image editing tools evolved without mouse - i mean you literally have to code everything - right from the pixel you need to edit, the selection - everything. Smart designers (or more of coders) became experts in it and they can produce some great quality images. The tooling is also great as the tool existed for decades with hundreds of libraries and ecosystem surrounding it. Now you come up with a new paradigm where you can use mouse and make it easy for novice designers to use it - there are two benefits you tout - More artists as opposed to coders can now create images - its much more easy to build the images. The coders on the other hand are not in favour of the new tool both subconsciously and consciously. Consciously because the new tool, while better in many aspects are no where near the previous precise tool in expressing the image - and tooling as well (version control, transformations, plugins etc). Subconsciously because somewhere they feel their decades of experience is not relevant anymore.. this is controversial but i have felt it when interacting with senior devs. (Similar to how many don't want to move away from vi/m to vs code for e.g).
On Mac, Apple apps and other "Mac-native" programs save revisions automatically in the background. At any point, the user can select "Show Revision History" and scroll through a timeline of changes. I'm not sure if this works with Excel, but it does with iWork/Numbers, and I use it all the time.
Now, Apple's implementation is just a simple timeline—there's no equivalent of version tagging, or git blame. But all of that could be done within a graphical environment similar to Apple's. It wouldn't be as advanced as Git, but I bet it could do what 95% of people actually use Git for.
You could though. Microsoft (or anyone else creating a "no code" platform) could absolutely build that into a graphical timeline view. Select these two snapshots, and show which cells changed.
The hidden benefit of (text-based) code environments is that problem is well understood and well solved for information represented as two strings of lines.
Non-text code paradigms fight an uphill battle for utility because they have to each reinvent that wheel, and many of the solutions are not portable to similar problems. I've used the diffing tools in labview, and they definitely work but I wouldn't want to have to rely on them for a large-scale project.
It's certainly not trivial (as Git wasn't trivial), but conceptually, version control strikes me as one of the easier things to translate to a GUI-driven environment. And it's something that should be translated, because version control is a major problem even in domains which have nothing to do with code, e.g. graphic design.
Let’s start with diff - If this is a text doc, diff seems easy. Show old and new text next to each other, somehow highlight new and old version. Immediate problem: what if you choose to highlight “new” with purple + underline, but user is already using purple + underline as a part of their text. Do you choose a different color? Or just hope it is “clear from context”?
Now for spreadsheets: the formula has changed, how do you show this? You can expand the cell to show formulas, but those can he huge, so your document can become unreadable. Or maybe just highlight the cell and let user click on it to see the formula difference - but then you can no longer see the changes at a glance.
What about things with no text representation, like conditional cell format? Are you going to come up with text representation just for display purposes, or are you going to design special text formatting dialog which shows “new” and “old” values?
There are hundreds of questions about GUI diffs which simply do not exist in texts.
> Immediate problem: what if you choose to highlight “new” with purple + underline, but user is already using purple + underline as a part of their text. Do you choose a different color? Or just hope it is “clear from context”?
Well, the first option that comes to my mind is dimming the full display, except for those rectangular regions which contain changes. I don't know if that's actually the design which makes the most sense, but a designer could mock it up as one of many ideas to see which one makes sense. (I work at a graphic design studio, so I'm fairly familiar with this process.)
The official tool would be Spreadsheet Compare [2], which looks like it does a better job than TortoiseGit's Excel diff. But it seems to be only available for specific versions of MS Office, according to the website.
The best of both worlds would be to write a version of diff-xls.js that used Spreadsheet Compare.
[1] https://github.com/TortoiseGit/TortoiseGit/blob/master/contr...
[2] https://support.microsoft.com/en-us/office/overview-of-sprea...
Git is flexible!
Also, no version control. Or, in our case since we used XML for output: poor version control. Reading horror stories about Excel also confirm this, it is hard to do correct complex programs in visual environments.