Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on from the tracking-the-code dept.

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.

35 of 264 comments (clear)

  1. Is this a joke? by __aaclcg7560 · · Score: 2, Insightful

    I probably still have my flowchart template from Introduction to Computers in 1993. Used it for that one class and never used it again. Not even when I later went back to school to learn computer programming a decade later.

    1. Re:Is this a joke? by Nutria · · Score: 2

      I probably still have my flowchart template from Introduction to Computers in 1993

      They had me do it in 1983, and I know that flowcharts were around in 1963...

      I also remember 4GL flow chart code generators in the mid-1980s, and their promise of "programs without paying programmers". What a joke that was.

      --
      "I don't know, therefore Aliens" Wafflebox1
    2. Re:Is this a joke? by EETech1 · · Score: 2

      Someone is posting as you, with very closely spelled names, and 4980000+ uid's

    3. Re:Is this a joke? by Dutch+Gun · · Score: 4, Interesting

      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...

      --
      Irony: Agile development has too much intertia to be abandoned now.
    4. Re:Is this a joke? by K.+S.+Kyosuke · · Score: 4, Interesting

      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."

      --
      Ezekiel 23:20
    5. Re:Is this a joke? by __aaclcg7560 · · Score: 2

      [...] his troll is not very good.

      My troll is an asshat turned n00b who can post only so many comments before the mods down vote them into oblivion and the account gets restricted to two comments per day. This troll has three accounts that I'm aware of.

    6. Re:Is this a joke? by __aaclcg7560 · · Score: 2

      No, you somehow managed to convince Slashdot that you deserved to get control "cdreimer" even though your fat useless brain didn't think to sign up your precious pen name for ten years.

      You created a user account for the expressed purpose of harassing another user on Slashdot. I asked for the account to be disabled or deleted. Management deleted the account, putting cdreimer back into play and I signed up the account. You got pwned.

      "criemer" is doing a great job of deflating your useless posts and showing the world what an utterly delusional Slashdotter you are.

      Other users are starting to complain about "criemer" and "creinner". I wouldn't be surprised if those accounts go away in the near future.

      And no one reads your stupid ebooks, just reading the titles made me almost swear off literacy.

      Maybe not. But my ebooks do sell. Selling is the only metric that counts.

  2. Does seem a bit 80's... by Giant+Electronic+Bra · · Score: 4, Interesting

    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.

    --
    "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    1. Re:Does seem a bit 80's... by Z00L00K · · Score: 3, Insightful

      Simulink is a variation of flowchart programming, but maintainability is hard when it comes to flowchart programming. You need a football field or two to try to make sense of it and any large system will have cross-dependency graphs that are extremely hard to follow.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    2. Re:Does seem a bit 80's... by jellomizer · · Score: 4, Informative

      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.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    3. Re:Does seem a bit 80's... by thsths · · Score: 2

      Yes, both MATLAB/Simulink and NI LabView come to mind. But both are graphical representations of data flow, and not control flow. You can abuse them to represent control flow, but that is neither efficient nor pretty.

      As said above, since the demise of GOTO, control flow charts are really much less useful than they used to be.

      There was a variation for block oriented programming that was derived from Pascal, containing a table like layout and graphical symbols for IF/THEN/ELSE, WHILE and FOR loops. Lego Mindstorm V1 did something similar - and I thought it was quite beautiful. But little has happened since.

    4. Re: Does seem a bit 80's... by ShanghaiBill · · Score: 2

      Back in the 1980s I worked for a defense contractor, and we were required to have flowcharts for all our code. In theory, we were supposed to design the algorithms using flowcharts, and then write the code. But that is stupid, and no one ever did it that way. Instead, we had a program to generate the flowcharts from the code, and then we printed them on a plotter.

      One page of code generated about ten pages of flowcharts, so we went through a lot of paper. Each time the shelves filled up with flowcharts, we would stuff them all in boxes, put them on a pallet, and have them moved to a warehouse.

      AFAIK nobody ever looked at them. Other than as carbon sequestration, flowcharts are useless.

    5. Re:Does seem a bit 80's... by thinkwaitfast · · Score: 2

      Everything is hard when you have limited experience.

  3. You just described Simulink. by Anonymous Coward · · Score: 4, Informative

    Plus Simulink coder.

  4. Scratch by roskakori · · Score: 2

    Scratch uses an approach similar to flow charts. If you're not to picky about the notation, it might be what you are looking for.

  5. Why? by Tablizer · · Score: 2

    Why? Even if it could technically be done, it's probably not good code from a human-readability standpoint and will have to be heavily reworked, such as variable re-naming, splitting into functions/modules, etc.

    --
    Table-ized A.I.
  6. Educational kits by AHuxley · · Score: 2

    Look at the US educational products that let users do things with a gui and even a robot kit.
    They often have a very simple gui system of getting input and presenting an output.
    I am not sure how much of the US educational product would allow for options other than following a set course structure.
    Often used so the whole class in a US educational setting can feel they are been educated about computers.
    A slow pace of education, not much maths, all about the gui and getting something done in a short time.
    Of historical interest might be some aspects of a card in Hypercard https://en.wikipedia.org/wiki/... from Apple.

    Most people who are smart find some programming language they can use e.g. Basic, Ada, Pascal or something Apple, todays apps or Windows supports.
    People who are not smart then just use what other people create for them.
    If a person needs C, take the time to learn C. If a person can present a flow chart, work with a smart person to turn that into C.

    If this is a marketing test to see what exists and what is needed, consider the many marketing lessons of Hypercard. What it did, what was done with it and why people now just use the maths and code for their Apple, MS or app needs.
    Circuit board design tools might be a starting point to replace the circuit board part with more of a gui, chart feel.

    --
    Domestic spying is now "Benign Information Gathering"
  7. Automate by Dialecticus · · Score: 2

    My favorite is called Automate by LlamaLab.

  8. Wikipedia has a category 'Visual programming by Anonymous Coward · · Score: 2, Informative

    Category:Visual programming languages

  9. Re:Absolutely, but by Z00L00K · · Score: 2

    UML is useful to identify which objects you are working with in the code but it's not good to describe the information flow in a system.

    The worst problem with UML is that it also can tie together objects with each other - or even worse, create objects - that from a superficial glance seems to be related but when you look at the information flow you see that the only thing they have in common is that they are related from a very specific perspective, much like two stars that looks close to each other from the viewpoint we have here but in reality they are many lightyears apart.

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  10. Time marches on by Waffle+Iron · · Score: 4, Insightful

    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.

    1. Re:Time marches on by 93+Escort+Wagon · · Score: 2

      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.

      1) They said that, but no one I knew actually did it.

      2) Column 7, not 8.

      --
      #DeleteChrome
  11. Also by Reverend+Green · · Score: 2

    Does anyone know of a tool that will allow me to write a novel by scribbling with crayons in a coloring book?

  12. Re:PureData by mkendall · · Score: 2

    I think pd, like LabVIEW, primarily shows the flow of data, not execution. They are data-flow diagrams, not flow charts in the traditional sense.

  13. EasyFlow from HavenTree by mnemotronic · · Score: 3, Interesting

    I'm a visually oriented person. For big-picture I can digest flowcharts and data diagrams easier than textual representations. I routinely use Visio. In the MSDOS days I used Interactive EasyFlow from HavenTree of Canada. The copyright notice / license agreement was worth the price of admission.

    --
    The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
  14. LEGO Mindstorms/LabVIEW by Roger+W+Moore · · Score: 5, Informative

    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.

    1. Re:LEGO Mindstorms/LabVIEW by thegarbz · · Score: 2

      With limited power comes limited opportunity to screw things up. "programming" by bolting together functional blocks with lines are the preferred ways of programming safety systems for this reason, and the IEC standards put very different requirements on programs written this way compared to those written in freeform code.

    2. Re:LEGO Mindstorms/LabVIEW by dbIII · · Score: 2

      I have been using LabVIEW for ~15 years

      That's starting five years after I stopped showing it to students because it was teaching them bad habits.
      I'm not just guessing here.

      It's a throwback to analogue computers without the careful mathematical optimisation that was usually employed before plugging in the cables.

    3. Re:LEGO Mindstorms/LabVIEW by Anonymous Coward · · Score: 2, Informative

      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.

  15. DRAKON Editor is exactly what you asked by TuringTest · · Score: 2

    The open source DRAKON Editor allows you to draw classic flow charts and generate template code in various target languages that follow the defined flow.

    It comes with the additional advantage of having been engineered around ergonomic practices, which makes it avoid the classic pitfalls of using flow charts. A flow diagram typically becomes a tangled mess, but DRAKON layout guidelines provide a structure to build diagrams in any scale.

    The DRAKON language was created by people in the Russian space program as a way to avoid errors in defined procedures, and it was crafted and refined following the Russian school of Human-computer interaction. The flow diagrams built following their easy-to-learn layout guidelines are the most easy to read that I've ever seen.

    --
    Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
  16. Re:That's how they teach programming.. by dbIII · · Score: 2

    If you think they were not conservatives then you have a lot to learn about politics.
    What Christopher Hitchens wrote about Bill Clinton is a good start.

  17. Re:Congratulations, you just invented... by TheRaven64 · · Score: 4, Informative

    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.

    --
    I am TheRaven on Soylent News
  18. JBoss Tools Integration Stack by NetFusion · · Score: 2

    There are quite a few JBoss based tools that will let you do this and then auto deploy the app on tomcat etc

    https://tools.jboss.org/featur...
    https://tools.jboss.org/featur...
    https://tools.jboss.org/featur...
    https://tools.jboss.org/featur...
    https://tools.jboss.org/featur...
    etc

    I use JBoss rules visual flowcharts editors for tweaking and testing a prek-12 vaccine compliance engine.

  19. BPEL environments by laughingskeptic · · Score: 2

    There are many flow chart based Business Process Execution Language (BPEL) coding environments, including multiple open source options: http://orchestra.ow2.org/xwiki... , https://eclipse.org/bpel/ .

  20. Re:Visualization? by Bengie · · Score: 2

    People with strong abstract reasoning make use of nearly all parts of their brain at the same time and the different parts are more highly connected to each other that people with lower abstract reasoning. It was difficult to see this with older brain scans because high levels of abstract reasoning cause larger neural-activity bursts but of shorter duration. One of the first parts of the brain to connect to the frontal lobe is the visual cortex. It is not far fetched to think that people visualizing logical problems is probably a side effect of the visual cortex helping with the processing of the logic. Below a certain threshold, the different brain regions are quite isolated. Once this inflection point is reached, it snowballs very quickly, reinforcing itself.

    Most of this is from research in the past few years from advancements with brain scans. There has been a large surge in research in relation to abstract reasoning and meta-cognition, which is starting to look like a power curve with a long tail. To make matters worse, there seems to be no way to teach someone else abstract reasoning. Learning abstract reasoning above the norm seems to be a self taught. Most people haphazardly acquire some abstract reasoning skills, but above a certain meta-cognition level, people can purposefully exercise abstract reasoning entirely by reflecting on their own thoughts. Some propose that reflecting on thoughts increases the interconnections among the brain regions, allowing for better pattern matching from the different regions working in unison instead of individually.

    There have been some experiments that showed certain mental exercises could increase one's ability to score higher on a particular abstract reasoning test, but the benefit did not transfer to other abstract reasoning tests, meaning the mental exercise made the person more efficient that particular test, but not actually better at abstract reasoning. Like I said, no known way to increase abstract reasoning except introspection.