Comment by aeruder | Hacker News Reader

Comment by aeruder | Hacker News Reader

Parent Full thread

100%. I worked at a company that really went in hard on Agilent Vee for hardware testing in the early 2000's. Absolutely a thing where a manager saw a "Hello World"-like demo and was so impressed that they went 100% full buy in.

Besides the obvious UI issues (like the fact that you couldn't really zoom out, you could just pan around your code), we had a bunch of engineers that still needed to do things like "get the three largest values from this array" and it just turned into the most ridiculous bubble-sort implementation you've ever seen.

Its pretty hilarious seeing some of the old screenshots now [1].

Anyways, I think it will always be really easy to sell some simple demos on low-code/no-code, but then the second you need something slightly outside the eco-system it just turns into a substandard mess that doesn't work well with source-control (or diffs) and in general is just harder than the code-full solution.

[1] https://i.imgur.com/KsVliNE.png

Yeah the main issues with visual programming are:

- Logic tends to take up a lot more screen space than real code

- There is no defined way to read the code. In real code you start top left and read left to right and down, but in visual code if there are lots of "paths" then your eyes end up darting around everywhere.

In automotive, development of control algorithms for the engine is entirely “visual”, through simulink/matlab. You design the model on simulink, then it generates the C code. I don’t have direct experience outside the automotive sector, but I believe that this approach is used in other sectors like aerospace. Maybe designing models is better than writing low level code for control algorithms?

I don't have any experience in the automotive sector. But when you say that the development of control algorithms for the engine are visual, I immediately thought finite state machine. My question: Are they finite state machines or is there more to it than that?

Depending on how complex, it would be a hybrid system. You have finite discrete states, but also continuous dynamics that need to be controlled (like a PID)

Control systems have always been designed in a connected box fashion. Before gui software existed. Visual coding is just an extension of what was being done on a blackboard

In power generation control when electrical engineers are discussing or analyzing the behavior of a governor or exciter block diagrams representing transfer functions are used. I would program turbine controls primarily in function block diagrams since it a great visual representation of the algorithms that makes It easy for some one to understand and observe how it works. I started with computer programming and it was quite an adjustment in my way of thinking to implement algorithms this way but no question it is the right tool for the job in controls.

Yes, IIRC some aerospace companies also use simulink. It's popular with safety critical stuff.

> Maybe designing models is better than writing low level code for control algorithms?

If you need both the code and the model, then generating the code from the model is also much easier than proving that your handwritten C code behaves exactly like the model used for verification. Having visual control flow for complex control systems might be less error prone than manually writing C (or Rust or Zig or $flavour_of_the_day) code. You probably know that, but other folks shouldn't forget that automotive and aerospace control software often means "programming errors might result in people getting injured or worse".

Text characters are always going to be way more concise than their visual representations.

The single most important point that is keeping visual programming from ever being taken seriously in corporate settings is the fact that there are currently no version control compatible with it (for good reason). You can't collaborate without version control.

I work out of a co-working space. A few months ago I walked past some people fidgeting with Zapier. Some (former) employee had built this crazy complex system of integrations, with connections going back and forth everywhere. It looked very much like this diagram, and I couldn't help but laugh, because it's the same kind of problem that coders face on a daily basis.

IMO, Zapier is a little different because it's connecting disparate APIs.

Disclaimer: I work for Zapier.

Ah yes true. My point was really that any tool can generate complexity, it's all about the underlying problem you're trying to solve.

Yeah, I think Zapier is one of if not the only example I've come across in my software dev career of a low-code-type tool that devs will reach for before doing stuff by hand.

Great example of where low-code is a better alternative for a very narrow use case of development.

The graph makes for a good laugh.

Also, I want to agree, but algorithm code can look ridiculous in any language, graphical or not.

I think graphical coding and "real" coding will merge from both ends. An advanced IDE today is already sort of beginning to look graphical.

I think this is very right. We have only scratched the surface in terms of creatively experimenting with the IDE UI to give the developer more ways to quickly explore and refactor code. Text in/text out is a serious loss in fidelity from the overall input/output capabilities of a computer.

I've had the misfortune of participating in a large-isch LabVIEW project and it looks similar.

Vcs integration and merge were also a big pain so most of the development was done on a single computer in the lab by many people.

The hardware that runs the LabVIEW code is solid tho and once you wrestle LabVIEW into doing what you want it works well

Getting flashbacks to programming ABB ACS800 motor controllers with some hideous block diagram based thing many years ago. Oh god.

We also had a ton of horrendous LabView spaghetti which was even worse.

So counter intuitive Scratch ?

Reply on news.ycombinator.com