7 ms·

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

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 https://i.imgur.com/KsVliNE.png

actionfromafar 4y ago
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.
- galdosdi 4y ago
  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.
danielvaughn 4y ago
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.
- sgarland 4y ago
  IMO, Zapier is a little different because it's connecting disparate APIs. Disclaimer: I work for Zapier.
  - danielvaughn 4y ago
    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.
  - habeyer 4y ago
    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.
__alexs 4y ago
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.
fizzynut 4y ago
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.
- ciarcode 4y ago
  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?
  - wolpoli 4y ago
    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?
    - gmadsen 4y ago
      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
  - liketochill 4y ago
    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.
icefo 4y ago
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
WediBlino 4y ago
So counter intuitive Scratch ?

actionfromafar 4y ago

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.

galdosdi 4y ago
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.

danielvaughn 4y ago

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.

sgarland 4y ago
IMO, Zapier is a little different because it's connecting disparate APIs. Disclaimer: I work for Zapier.
- danielvaughn 4y ago
  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.
- habeyer 4y ago
  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.

__alexs 4y ago

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.

fizzynut 4y ago

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.

ciarcode 4y ago
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?
- wolpoli 4y ago
  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?
  - gmadsen 4y ago
    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
- liketochill 4y ago
  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.

icefo 4y ago

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

WediBlino 4y ago

So counter intuitive Scratch ?