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

Does seem a bit 80's...

[Giant Electronic Bra]

I mean, we have had UML now for going on 15 years. You can CERTAINLY generate code and other artifacts from some types of UML diagrams. None of these is all that much like a flowchart, and frankly flowcharts are essentially dead AFAIK. They really only ever worked well, if they ever did, on fairly straightforward procedural code. Back in the bad old days before Structured Programming and then OOP it wasn't all that uncommon to see people using them, but that was mainly because even fairly straightforward linear code was hard to understand when it was written in FORTRAN or COBOL. Such charts have little relevance in modern OO/functional coding where linear control flow is really not an issue.

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.

You just described Simulink.

[Anonymous Coward]

Plus Simulink coder.

Time marches on

[Waffle Iron]

When I was first taught to code in FORTRAN, we were told that we really needed to create a flow chart detailing every statement before writing any code. We also needed to start every line in column 8, and variable types were determined by the first letter of their name.

Those days are long gone, and we now have languages with features that allow us to directly transcribe our ideas without intermediate formats (yes, LISP always allowed that from day 1, yada yada).

I find that flow charts still have some usefulness on occasion, but only as a high-level planning tool. I will sometimes write up a flow chart with a dozen boxes to define the rough flow of a complex algorithm, but it might take a thousand lines of code to actually complete the final implementation. A flow chart that had enough detail to mechanically translate to code would look like an incomprehensible pile of spaghetti; not very useful compared to well-formated code.

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: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:Is this a joke?

[Dutch Gun]

Yes, you absolutely can write code using flowcharts, and I've got two practical examples from my career in videogames. Obviously, both were in specialized sub-domains, as the bulk of our general work is in C++.

First example: I worked at a place that allowed artists to wire up nodes in Maya using a circuit-like logic system. For input, they'd use timers, triggers, environmental sources (time of day), etc. Then they'd connect those inputs to various logic gate nodes (AND, OR, math, branching, delays, etc), and then to various output nodes that would affect the game world in various ways, such as triggering animations, environments, music/sound effects, and so on. This gave artists an incredible amount of power to shape the world if they were clever enough with their wiring skills, and all without programmer support. It was telling, though, that we eventually added a "Lua Script" node, because sometimes complex logic is really hard to do with circuit-type wiring.

Second example: In widespread use today, many game developers generate HLSL shader code using visual tools. Again, the same sort of logical wiring occurs. The connections represents an RGBA color source, or maybe a vector, while the nodes represent methods to transform that data. To blend two color sources together, for example, you pick a particular blending operation node, then just visually connect the sources and output. The visual programming paradigm means that technical artists can use this system rather than programmers, allowing them to tune their materials exactly how they'd like.

This sort of visual programming works really well when dealing with data flow in a fairly constrained environment. Other real-world examples include creation of sophisticated virtual musical instruments using visual programming techniques. Native Instruments has some products that work this way, like Reaktor. Example: https://www.native-instruments...

Re:Is this a joke?

[K. S. Kyosuke]

It was telling, though, that we eventually added a "Lua Script" node, because sometimes complex logic is really hard to do with circuit-type wiring.

There's a nice quote by Alan Perlis: "A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures."