Hacker News Reader

Comment by yoz-y | Hacker News Reader

I spent the first years of my career writing "no code" signal processing platform. It had it's ups and downs. We indeed had a lot of non-coder users and it made prototyping simple to moderately complex pipelines quickly. However relatively soon for anything actually useful we had to write more components, some of which were not really reusable because it's non trivial to hide the complexity. At some point most workflows ended up in a "python script executor", because in the end code is always more expressive.

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.

View on HN

I run a no-code agency, and my conclusions match yours: no-code tools are great for getting up and running, and for involving less technical people in process development. But sooner or later you'll need to do something that is outside the boundaries of the no-code platform's feature set, at which point extending it becomes a huge mess, because you then are forced to write code and hook it up to the no-code process in very strange and awkward ways.

Like you say, lack of source control is the biggest pain point.

Agree, Remind me of GWT (google web toolkit) - Marketing message sounds very good: Let your Java Developer write java, GWT compile it into Javascript and run it on the webpage.

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.

Eh, I built one GWT app by myself in 2011-12, maybe 40K lines of GWT code. First web app I'd ever worked on - all my existing experience was desktop (C#, C++, Java, Python). It worked as advertised, and let me build something useful. Another team has a GWT app that we are just now finally working on migrating. Anecdotally, I've seen user group discussions of very large enterprise GWT apps. So, the technology does actually work as advertised.

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.

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

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.

Graph annotations matter a lot for diffing I think. I think this is actually a good space to explore as it is a hard problem, and would require some serious UX research on how to handle this.

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.

> To diff something like an image, or a graph, you probably want to see them on top of each other

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.

Abstract has pretty impressive diffing for Sketch assets and is basically Git/Github for designers

For Excel there is Microsoft Spreadsheet Compare, which shows the files side-by-side, highlighting differences in data/formulas/properties, and also shows the differences as a list. It can be quite clever, e.g. figuring out that columns or rows have been added or deleted (much like a diff on a text file).

That sounds like vaporware to me. I might be interested in adopting a visual programming system that had good version control. But so far they don't actually exist.

The problem is that text is universal, while each visual language is different.

One would need “universal visual language representation” file format if they want the visual languages to become as popular text-based ones are.

And yet, semantic diff and merge is a thing exactly because text is not universal when it comes to programming. Text is universal when you want to diff text but not when you want to diff programs.

Sure, semantic diff is nice, but it is purely optional. One can diff programs as text and get pretty far -- after all, that's what practically every version control system does today.

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

Speaking as someone who's been working in the space of collaborative editors for a decade or so:

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

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

I'm trying to understand this part. Would you give an example of semantic diff losing intent signal?

You see this in the preference for small commits.

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.

An example is, say you have a counter value. There’s two types of operations users can make - either reset the counter to some value or increment it. The counter was 20 and now it’s 25. Did the user set the counter to 25 or did they increment it 5 times? When there’s only one editor, it doesn’t matter - the result is 25 no matter what. But if two users both edited the value at the same time (the other user changed 20 to 30) now we have two different results based on the users intent. Either the new value be 35 (20+5+10) or we should pick one of the results (25 or 30) and just converge to that new value.

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.

This kind of works but users don't always express their intent in their edit actions, either because no available edit action can fully capture the intent or because it was simpler to achieve the desired state in a different way.

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.

Going to guess GNURadio based on calling it a Python script executor that outputs xml. If that's true, I'd that it really starts to break down when the desired logic breaks from the "apply sequential steps to a stream of contiguous data" paradigm.

It was OpenViBE, but looking at GNURadio it looks fairly similar so I expect limitations would be also quite comparable.

I would have assumed that no-code tools would have actually shined with weird non-linear dataflows since they’re usually all graph based.

Kind of a shame really since having a dependency solver as core part of the language structure sounds really cool.

I worked for a startup that built a no code platform. The experience you had, was the same experience that the majority of our customers had. Its a general problem with low code. We tried to make the software easily extendable so that developers could refactor away the complexity, by easily adding new tools to the design surface. The approach worked quite well for internal projects, but was at odds with the marketing approach to the product, so it was never pushed to clients. Clients were sold a utopia of business analysts dropping some components onto a designer and hey presto. Low code can work, but in the same way as traditional dev, where code should be refactored into components that's are easy to reason about. The problem is that this is hard to sell. There is a very nice balance to be had with combining low code with traditional dev. Its just very hard to find that balance. Its far easier to write good code in a traditional language that in a low code environment. If you add to that the expectations created from low code demos, its mostly a recipe for disaster.

Difficulty in version control and testing is one of the reasons I don't think I could ever work in a no-code environment. It's an issue that I'm sure many people don't care much about but it's also a big reason I doubt no-code will ever overtake custom code solutions.

I have a similar experience as you. I worked on a Neuroscience/BCI focused signal processing platform, and also came up with the idea of having a "Python script executor". We used YAML though to store the pipelines. Seems like a very recurring problem.

Mine was also a BCI processing platform actually (OpenViBE).

The software I worked on has striking similarities to OpenViBE. I am surprised we didn't find the software you worked on when we were looking around. There are also other programs you might find similar - NeuroPype & Open Ephys.

Our first milestone was a speller similar to yours however we worked with MEAs rather than EEG. Small world!

15 years ago I had a business try to force a group of us into such a system.

Almost everyone that agreed are still there.

Great way to kill a career.

Different people value different things. Some people would seek out that degree of stability.

Second that.. while some others prefer to join the rat race..

I started building "no code" tools since 2004. I am also the author of codeflow - a not yet open sourced visual programming platform. I wish no code distinguishes between frontend no code(webflow, wix etc), backend no code(codeflow, mulesoft etc) and full stack no code(outflow, mendix etc). First of all this "no code" is being used for decades in fortune 500 companies and many of their major backend services are run on yesteryear no code. In fact it wouldn't be wrong if to state that all big financial companies use no code as part of their major backend stack (its called in different names such as middleware/soa/integration/etl etc), but they are all visual, drag-and-drop backend/business logic builders that would have required complex coding without them.

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

> Also, no version control.

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 can also commit Excel files to a git repo. That lets you get back to old revisions and look at the commit messages. But you're not going to get a diff or git blame, which is what the parent comment really meant.

> But you're not going to get a diff or git blame, which is what the parent comment really meant.

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.

This exists, at least for Word and likely for Excel as well It is also horrible,hard to understand and not useful for most tasks you will use source control for

But is that inherent in any GUI-driven solution, or is it because Microsoft has never prioritized it as a first-class feature? I'd argue it's the latter.

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.

It is not clear to me at all how to make a good version control at GUI apps.

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.

I found your response very interesting. It actually makes me think this is doable because "hundreds of questions" doesn't sound too bad. Many projects answer hundreds of questions.

I think these are design issues that you could solve with a bit of work. As an example:

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

It turns out to be an extremely non-trivial problem.

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.

Well... diffing at least is possible :) https://programmaticallyspeaking.com/git-diffing-excel-files...

Git is flexible!

TortoiseGit had Excel diff available out of the box the last time I used it. [1]

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

https://www.xltrail.com/

Reply on news.ycombinator.com