Hacker News Reader

> in my experience these tools open the imagination of what is possible and even more backend support is needed over time.

I just don't buy the argument that visual programming tools are inherently more creative or imaginative than text-based programming tools because at some point, you are going to be constrained to the UI, which always comes with tradeoffs.

I recently used a visual programming environment for a work project, and I went into it thinking that it would be a fun and interesting way to program and very quickly turned to hating it. The visual aspect of the tool constantly got in my way and I quickly found myself wishing I could accomplish what I was trying to do in my text editor instead of this godforsaken web UI.

The error messaging in the tool was so bad that I wound up just intercepting the necessary HTTP calls and debugging those instead because it was so much simpler and informative than trying to navigate this "Disney World" UI that looked great with a trash UX.

I'd be OK with a visual programming tool that gives users the option to go straight to the code layer if they choose, but I've worked for so many software companies in my career that I'm just not confident that most companies would be able to ship anything with a dev UX that comes close to working with code directly. You can't get away with "happy path"-ing a visual coding tool, which is how so many companies build software these days.

> I just don't buy the argument that visual programming tools are inherently more creative or imaginative than text-based programming tools because at some point, you are going to be constrained to the UI, which always comes with tradeoffs.

They aren't inherently more creative for all people. For example there is a group of people that prefers LaTeX to MS Word - but it's undoubtable that Word is more accessible to more users. The creativity comes from letting business users directly iterate on the UI mockups and underlying process, which is possible in these tools. Instead of waiting a few months for an IT project to start, the users can create a mockup in a few days and iterate a few times before connecting to a real backend. I would have thought this was improbable 3 years ago, but personal experience has taught me that there are many business users capable of doing this.

Most of the tools created with these platforms never "ship"; the primary users are often internal. At large companies, an internal app may have 10k users. Also, YMMV depending on the tool - some are much better than others at debugging complex flows.

Visual programming is an idea that keeps coming up because there are no examples of it, therefore it would seem like a great innovation.

Because there are no examples of it is precisely why it’s hard to do. Those who try either end up with something too application specific to be extended, or something too abstract to be used.

Take UML, it took the abstract route. It has many diagrams, it even has flow charts. It was big in the ‘90s and never amounted to much. Turns out that to implement something in UML is harder than just writing the code it maps to in the first place.

UML did fail as a modeling tool - it was just too complex. However, flowcharts have succeeded on many platforms in many domains. (Gaming engines like Godot Visual Script and Unreal Engine Blueprints, BPM tools, Enterprise Integration tools, many hardware design tools)

The best environments combine visual and code based elements so you don't get "stuck" when something is missing in the low code areas.

That's a weird thing to despise. You know it's not necessary to try and put everything on a level playing field. I don't think your argument is valid on that front because when you code, you're inputting code. Nobody says "I'm going to do some text based programming" unless there's a need for that distinction in that situation. I think low code and no code are perfectly valid because you're inputting no or close to no code to achieve the task.

The main reason I despise it is that the term is often used to imply that there is "no technical debt" or "no maintenance costs" or that this is "not real programming". In reality, users are still creating software, so technical debt and other maintenance costs will still build over time. Project management, feature prioritization, data/schema design, system design, module decomposition, testing, etc are all still important tasks and don't go away just because the tools are visual.

A lot of it is due to perceptions - in my experience senior non-tech managers misunderstand the term, whereas "visual programming" still emphasizes that this is a software project with all that entails, just constructed in a more accessible way.

+1 on these tools opening up people's imagination of what's possible. They're the experts in their domain, and having these tools allow them to project what they know onto a system that makes them more productive and efficient.

If you don't mind answering, what were the kinds of apps or processes that business/ops folks you worked with made?

I work at a large healthcare equipment manufacturer - the group I worked with automated many business processes relating to equipment field sales, service, and maintenance. The end users were generally internal sales or field techs. Most of the apps are basic CRUD and maybe some video links. We're a typical large enterprise, so it takes a very long time to execute new software projects and often by the time they are done the business needs have shifted.

The users started out by using MS Power Platform and SharePoint to create simple apps and forms and get some feedback from the users. After a couple of iterations they would finalize the desired flow and my team would give them an enterprise integration point (sometimes Boomi, sometimes custom code) to read/update the real data. We are currently evaluating Mendix and Outsystems to see if that will further streamline the process.

> A better term is "visual programming"

I tend to agree. "No code" seems to imply "no programming", but that's exactly what you do with these tools, just in a simplified way.

It also isn't always simpler. Once you're visually flowcharting minor text transforms "low code" is a misnomer

Yeah, text transforms are a bit of a nightmare in almost every platform. Most low code platforms have an expression or macro/function editor that would be used to deal with those - it's also ugly there. For my team, we usually cleaned them up in the back end services since citizen developers are not too familiar with these kinds of issues.