Ask Slashdot: Is There a Way To Write Working Code By Drawing Flow Charts?

Slashdot reader dryriver writes: There appear to be two main ways to write code today. One is with text-based languages ranging from BASIC to Python to C++. The other is to use a flow-based or dataflow programming-based visual programming language where you connect boxes or nodes with lines. What I have never (personally) come across is a way to program by drawing classical vertical (top to bottom) flow charts. Is there a programming environment that lets you do this...?

There are software tools that can turn, say, C code into a visual flow chart representation of said C code. Is there any way to do the opposite -- draw a flowchart, and have that flowchart turn into working C code?
Leave your best answers in the comments.

Comments

You just described Simulink.

[Anonymous Coward]

Plus Simulink coder.

Wikipedia has a category 'Visual programming

[Anonymous Coward]

Category:Visual programming languages

LEGO Mindstorms/LabVIEW

[Roger W Moore]

It's no joke. LEGO Mindstorms comes with a graphical flowchart-like language using LabVIEW to write programs. Of course, the system is hideously slow and inefficient compared to text and with EV3 the brick runs Linux so you can easily dump it for Python, C++ or whatever you like.

LabVIEW itself is also used for instrumental programming in some labs although I expect it is rather slow so its applications will be somewhat limited. I've never used it myself in particle physics but I believe some of my condensed matter colleagues use it as a slow control system for commercial instruments.

Re:LEGO Mindstorms/LabVIEW

[Anonymous Coward]

LabVIEW has it's faults, but "limited" is not one of them.It is currently used to control the LHC at CERN, SpaceX uses it for its rocket launches, and it is in use by several companies for 5G wireless standards research. LabVIEW can be used in everything from simple data acquisition and instrument control, to motion and vision control systems, to HIL and simulation testing, to FPGA programing, and to testing MIMO communications systems. I have even seen LabVIEW FPGA used to program a National Instruments board that uses a Xilinx FPGA to perform laser cataract surgery.

The same LabVIEW engine that does all of the above tasks is the same one that is running the Lego Mindstorms brick. LabVIEW does a lot more than just "tabletop experiments".

Here are a few articles on LabVIEW being used in some of the applications I mentioned above. National Instruments has plenty more information on their site regarding the various places LabVIEW is used.

https://www.forbes.com/sites/alexknapp/2011/10/12/national-instruments-is-leading-a-quiet-technological-revolution/2/#1d796142d6da
https://www.forbes.com/sites/patrickmoorhead/2014/06/30/national-instruments-stepping-ahead-of-agilent-technologies-with-new-5g-wireless-design-tools/#7fac3aa67cd3
https://www.evaluationengineering.com/fpgas-make-retinal-disease-treatment-faster-and-safer

I'm not saying LabVIEW is the greatest language ever and will replace everything else, but it has its advantages in many applications. It is quite capable of scaling from a Lego robot in a grade school project to controlling some of the largest complex systems created, as well as providing top research scientists with tools to create new technologies.

Re:Congratulations, you just invented...

[TheRaven64]

He seems to want to take a dataflow programming language and generate C from it. This is trivial and there have been a bunch of tools that do it. The problem is, it's entirely pointless. If your code is better represented as a flow chart, then use a dataflow programming language and don't bother with C as an intermediate representation. The only reason to turn it into C is if some parts of it are easier to edit as C code (typically, bits with complex flow control, because even nested loops in graphical dataflow languages are pretty hideous). Then the problem that you actually want to solve is turning a flow chart into C, editing it, and then turning it back again while preserving the original structure. This is much harder, but typically dataflow languages let you call out to C for complex operations and that's generally a better solution.

Re:Does seem a bit 80's...

[jellomizer]

UML and other Flowcharting method are better on paper. But rarely can scale to a full application.
1. They are based on the idea that the business owners know what they want. UML and flowchart are based on the idea if you have enough meetings and talk to the right people that you will get all the info needed. This isn't true. What they say they want vs what they need are actually very different.
2. Like objects often will evolve into two different species. UML wants to make a Person class that can be inherited into Users, customers, execs, administrators... however as time goes on under real use you may find that you may have users who are just another program or dealing with customers who are business which has data elements that just don't fit in the model of a person. This makes either bad data entry to get it to work. Or crazy workarounds.
3. UML and flowchart are about understanding the info not building it. That one box that says save data could be a complex piece of code, factoring in silly things like security performance and the face that this data is being used by many people at the same time. Building a flowchart for all parts will just be more cumbersome and make the process way too officiated.

They are flowchart and UML based converts and languages. But they are marketed as workflow management systems, which are fine and good for what they are. But don't expect these to be on the top programming language board. As they are usually under tight controls of the consulting companies and the development companies.