Slashdot Mirror
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.
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.
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.
...you just invented pseudocode!
Rhapsody can do this, and has been around for about two decades. It was previously owned by I-Logix, and then Telelogic.
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
...or a deadline. Only the lack of experience and combined with the pressure of time can make people ask such stupid questions.
Plus Simulink coder.
Google Scratch. 2.0 makes it turing-complete but it's not exactly API compatible
SCADE from Esterel Technologies does exactly that.
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.
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.
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"
Node red... drag & drop programming in a web browser.
https://youtu.be/fV78MQks6BI
Pega software from Pegasystems does that - although it writes code in java.
There's a reason people don't .... It's terrible. LabView is a mess, and AmigaVISION was charming ... 25 years ago.
Mostly random stuff.
My favorite is called Automate by LlamaLab.
Category:Visual programming languages
Yes, BPMN is basically a flowchart framework for Business Processes. Note that since the top level steps are very general steps, there is also the ability to plug in more specific code to handle the details of such a step.
There have been many efforts; however, most of these efforts to make pictorial code executable are hampered by the inefficiency of creating and maintaining the pictorial code. Apparently people are better at writing in text than dragging around boxes in a GUI editor. I believe this is due to the presentation of the text being easier to read in bulk, even if it is less visually appealing. Others may have other opinions. Mine is based on anecdotal evidence, as I can get three or for functions on the screen at the same time easily, while I can only get a few dozen nodes of a flowchart (which might be half a function) on the screen at once.
Scratch (or the improvement BYOB, Bring Your Own Blocks) does pictorial programming; however, they use an improved visual language, as compared to the traditional flow chart. I've used it for some just beyond trivial toys that I share with my daughter. I can say that it is easier to start writing something in Scratch, but after you have more than four functions, it is harder to verify your program is what you desired overall.
For trivial academic problems that nobody really cares about, yes. For hard problems in real world situations that real people care about paying money for, no. UML and its kind are good for documenting a simplified slice of a complex system so engineers can understand the requirements and start writing real code. But to be precise enough to generate code, well, you might as well just write code.
And there have been other attempts...most I can't remember now.
The problem is never the "writing of the code", imo. The trouble is that most people don't/can't critically think and aren't disiplined enough to debug.
They're not flow-charts, but the PureData programming language is provides executable diagrams. Pure Data (or just 'Pd') is an open source visual programming language for multimedia. Its main distribution (aka 'Pd Vanilla') is developed by Miller Puckette. Pd-L2ork/Purr-Data is an alternative distribution (originally based on the now unmaintained Pd-Extended project), with a revamped GUI and many included external libraries.
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
In liberal schools.
Draw a line between 2 boxes. Score 100% and a science degree from Evergreen College!
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.
Does anyone know of a tool that will allow me to write a novel by scribbling with crayons in a coloring book?
There are a few. https://sourceforge.net/projec... has good results
Don't ask me how I know about this, but weblogic (now oracle) process integration ide allows some code to be generated from flowcharts. It is horrendous code and the usefulness of what it can do is very low, but it can do some of it.
MY OTHER COMMENTS
All higher level logic ends up having side effects, just in order to be convenient, and relevant the way we use analogies/language.
You'd end up with even bigger problems with flow charts, because the labels you'd add would end up confounding your expectations as you build more and more.
The only way to avoid that is using very simple concepts in your flow chart. At that points, you're just creating circuits, which are not just below regular code, but below even assembly code in terms of the layers of abstraction you have to mentally juggle in order to build any complex logical relationships.
You could follow this same path by saying "couldn't we just ask a series of yes/no questions and create programs with that?" ... and eventually, you'd find you're just coding in a difficult kind of binary.
And yeah, with development, you could make rather sophisticated programs easier with either method mentioned - but to build a culture around such methodologies, you'd not only have to spend far more resources, but also ignore the very reasoning that lead us to bypass these approaches when they've come up before. And also, you ignore why those approaches always seem to lose out to building on modifications of what works most flexibly, rather than what you'd imagine is most natural.
Ryan Fenton
I know FreeDFD to convert from flow chart to code, but it was just the project of a young student. It isn't maintained. Her a video in Spanish
I know PSeInt to convert from pseudocode to code, but it is also a small project the project of a young student. It is still maintained.
If somebody have to program a utility like that, it would be nice to be based or included in the project Dia2Code that actually generates code from uml DIA diagrams.
Excuse my poor English
Flow charts are no more expensive than code. They just layer a visual syntax on top of the underlying forms instead of a textual syntax.
You should be asking for tools to command the underlying forms that don't require you to input all the syntax; tools where you can describe how you want something to work in broader terms and let the software write the syntax, handle the scheduling optimization, prevent the bugs and security holes, and make sure all the corner cases and failure modes are covered.
Where's that tool?
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.
I was pleasantly surprised at how easy it is to use Unreal's Blueprint Visual Scripting. You can essentially program an entire video game using flow charts. And it's very simplified since it is context-aware, so you only see functions / variables that are applicable
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.
https://en.m.wikipedia.org/wik...
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
Pips can do the flowchart thing for you: http://pips4u.org/copy_of_getting-pips
A critical requirement when programming is the ability to compare different versions of the same code. This is quite easy to do with text. With diagrams, it becomes much harder to do.
Depending on what you are building you might want to check out Blueprint for Unreal Engine. I have made a working VR demo with this visual scripting tool, best of all its free!
Siemens' simotion mechatronics computers could be programmed by drawing flow charts, ow writing "STL" which was based on Pascal.
The idea behind the flow charts was that electrical engineers could understand them, and thus program PLC's.
To their credit, this worked somewhat.
To their discredit, once said engineers were introduced to the concept of objects, they lost their shit and got completely confused because of how ill suited it was for OOP.
Raptor is a teaching system using flowcharts to create programs. You are welcome to use it, I'm sure. However,
with 50 years of computing experience behind me, my personal feeling is that you are barking up the wrong
tree. As a teaching system, I have found Raptor less than useless. For nontrivial programming, I have found
flowcharts less than useless. I have found flowcharts of some use in dealing with very small segments of difficult code,
or overall system structures. YMMV.
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.
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.
Well there was that first programming assignment in CS 101 Introduction to Computer Science where one did a flow chart (neatly using a plastic template), then wrote (as in pencil on paper) code on a Fortran Coding Form (graph paper like showing the important columns), and then after manually stepping through the code (simulating it) to debug it one typed the code on the punch card machine, submitted the punched card deck, and waited for a printout to be delivered to see if it compiled and ran and generated output. Repeat as necessary.
After this first assignment and the posers dropping the class they handed out the interactive accounts for the terminals. And the coding forms were then used as ad hoc graph paper and the punch cards as bookmarks; the plastic flow chart template going into the drawer with the slide rule my dad gave me many years earlier.
Scratch is a language to learn programming, that's does by ... *wait for it*... drawing flowcharts.
IEC 61131-3 defines several graphical programming languages for PLC.
https://en.wikipedia.org/wiki/...
General purpose graphical programming language would be a major PITA. I cannot imagine anybody using it to write complex software.
http://www.khoral.com/
For image processing.
VisionMachine, a visual programming environment with gesture recognition and an LLVM backend: https://www.youtube.com/watch?v=RV4xUTmgHBU
Making space invaders: https://www.youtube.com/watch?v=TZ3Fqm5koOY
Audio synthesis: https://www.youtube.com/watch?v=0HhX1rctz9Y
Gesture recognition: https://www.youtube.com/watch?v=FEmE4LeTqPU
Just a prototype for now. Will start a Kickstarter/Patreon if there's enough interest.
I was in a project several years ago where we implemented the main workflow as runnable diagrams, so the domain experts could collaborate with us directly without knowing how to code. In that case we used BPEL as the underlying language, autogenerated by the ActiveVOS tool (no manual code editing needed). Today's BPMN 2 includes workflow primitives (it used to be diagram-only), so it could be used instead of BPEL (skipping the code generation step). Our diagram-based program was easy to explain, easy to debug, easy to test, and had a nice audit trail that showed us where in the diagram errors happened (including relevant data).
Obviously under the covers we also needed some normal coding (lots of Java to handle DB transactions, and we also had a rules engine). But having the top-level program that had the details the customer cared about run directly based on the diagrams saved a ton of time, and years later the person that took over that system told how easy it was for him to maintain.
In an earlier job we did something similar for the US Air Force, where our diagrams were directly runnable (allowing a commander to diagram a battlefield scenario to test and compare software). We created a custom runtime and diagram editing toolkit, since no standard or tools existed yet. Today, it's better to use a supported standard, since you can find tools cheap or free.
First of all, Unreal Engine's blueprint system is quite excellent, but is also specific to its domain of being a game engine. But you can make your own blueprint modules in C++, so no reason you couldn't make boring business software with it.
But there's already a great tool for boring business workflow, and that's BPMN. I've recently discovered it and it's so much better than endless meetings where no one knows or can agree about what is fully going on. I only have experience using it to model software at a high level, but there are advanced instances of using it to control actual systems. Plus, it's open source. You could do all kinds of crazy stuff for better or otherwise, like putting an animated Nyan cat in your workflow or having a task switch the lights on. Check out http://bpmn.io/ (open source!) and their associated commercial entity, Camunda.
There is a Developper engine called "Flowcode" which allows to do programs for microcontrollers (PIC, AVR, ARM) using flowcharts. It's quite expensive (given that PIC/AVR dev tools are free).
Basically, you've some "macro" blocks for more high level functions (like displaying on an LCD screen), rest is flowcharts.
There is a program, originally developed at IBM, that does exactly this. In its present form, after IBM open-sourced the code, it's called OpenDX. However, it is used in a very specific environment. The treatment of data into graphical images. It's less than trivial to understand how it works, and the code is pretty outdated (e.g. no parallelization). However, it's good at what it does and I used it in several scientific publications.
In the good old days of mainframes and 8 bit computers yes, you could plan your entire program in your head and from a flowchart before a single card was punched. Toda'ys software is too complicated for that though. Want an example of a graphical flowchart design tool like you describe? LEGO MINDWORKS for their robotics kits. Yes it works but it's as painful as an arrow in your liver. I don't even think it's good for teaching kids because they very quickly outgrow it. Give me a text editor any day... and fortunately now there are text editor equivalents for LEGO MINDWORKS too.
I wrote part of a system for "programming" using flowcharts back in 1975 as my diploma dissertation. I didn't bother to try completing it afterwards, because it became obvious there are two problems:
1) A flowchart for a useful program, with legible annotations, needs a big canvas. Simple loops and if clauses are fine, but as the program logic increases, it's hard to lay it out as a pretty picture. Source code is much more succinct and easy to comprehend. A big chart ends up with lots of parallel lines, and it's quite difficult to see what's connected to what.
2) Flowcharts aren't really that much use for describing complex systems. Think of drawing a chart for say an HTML renderer for a Javascript component. It's going to be messy.
FWIW, AFAIR I proved that a goto-less program was equivalent to a flowchart without crossing lines. Of course, back in those days there was no need for exception handling ;-)
Early in my career, 1992 onwards, I made multimedia (when that was still a cool new thing!) training and presentations in Macromedia Authorware which largely followed a flowchart metaphor - the idea being that it would help non-programmer content specialists to make multimedia training. There was some bigger power under the hood since you could add pascal like scripts to the icons. Very unfortunately the scripting language didn't support functions and procedures, you had to go to the icons flow for that.
Still I made some pretty nice for the time multimedia training and reference programs, helped by a graphical designer for a slick look. In addition we recorded professional voice overs, and even had fullscreen video, these required Realmagic moeg-1 overlay cards.
Macromedia was bought by Adobe, mainly for Flash, and eventually Authorware was discontinued. A pity that it wasn't open-sourced, the product / environment still had good promise.
Node-Red is a flowchart based IDE backed by IBM and based on Node JS. It can produce pretty usable programs.
Yes there is. It's called CASE* and/or BPM* and/or DMI*. (Computer Aided System Engineering / Business Process Modelling / Direct Manipulation Interface).
The Problem with many of these Systems is that writing code often is quicker and easyer. There are special scenarios where the tool mentioned above can be used and are extremely effective (well-built cleanroom ERP setups, cleanroom UI toolkits (end-to-end Visual Basic (guess why it's called visual), Glade, QTCreator, JBoss BPM, Flash IDE, Squeak, etc.). Systems like these can speed up development by orders of magnitude, but they have their own learning curve and are very often sneered at because they aren't "real development". Flash being a very good example of this.
The biggest problem with these systems is, that you have to be very good at OOAD and abstraction before you can go back to drawing neat pictures and most people skip that step, drawing up shit and giving these systems a bad reputation.
Bottom line: Yes, these systems exist, but they haven't really gone mainstream yet. Maybe when the web decrappyfies and AI an VR take of they will. But even then a good PL will be a good competition still. I can type a model faster in YAML than I can draw it, thats a plain and simple fact.
We suffer more in our imagination than in reality. - Seneca
I guess you may find something interesting in PWCT wich stands for programming without code technology. I did not really used it, but its creator said that it can output code in c and python and some other languages. And that it is usable for advanced systems (e.g compilers)!
When you finally have the language, you will realize that the hard part is not the syntax, but the logic. And that dragging boxes is way slower than writing keywords.
This stuff has been around since the 1990s if not before. I didn't use it but around that time some of the guys in my office used Excelerator. They didn't like it much.
Clarification: are you asking if something does it, or if something does it better than a monkey could code it longhand?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
it's similar to flowcharts, and it's adapted for Americans, so anyone 10 years of age can pick it up pretty much.
As AI and computer science continues to improve, we or our grandkids will see the day when we will look back on the way computers are programmed today the way we look back now on when computers were programmed with patch cables or punched cards.
One day people will interact with machines like we do with other people. Computers won't be programmed, but trained - and that'll include the low level stuff too.
The days of compilers and linkers are closer to their end then most here realize.
It can be done... but the process is rather complex internally (tracking connections, blocks of code, conditions)...
But why? Entering the graphics is complex (the editing), and inherently slow (having to use mouse/trackpad/touchscreen, then type the text for the blocks...)
Text entry is much faster.
Flowcharts can be useful for EXPLAINING code to someone not knowledgeable in programming. But not much else.
I don't know the reason, but there is one, and it must be a pretty good one. That is enough proof for me.
Only for the last 30 years. And far more complex items than simple logic, fiendishly complex systems can be quickly generated from controls block diagrams using packages like SIMULINK, Many times, its too fiendishly complex to use in an end-item but certainly for simuations it can be very effective, It also has endless frustrating bugs, but that's not inherent in the concept.
(Posting AC due to the rant nature of this post, but it hits a bit too close to home.)
A note on graphical programming environments and large-scale projects.
I work in the automotive industry. The fact that departments that write software for the electric control units still filed under "Electronics" rather than "Software" says a lot about heritage: until quite recently, engineers developing "code" for cars and other vehicles were control/mechatronics or electronic engineers.
In the 1990s software began to make its way into cars (often due to increased demands on emission restrictions). Automotive companies noticed that neither the control/mechatronics nor electronics engineers on the market and within their organizations seemed to be able to produce programs that were maintainable -- i.e. spaghetti code, non-existent version control, testing, etc. Salesmen pounced on the opportunity, and we got Simulink.
Simulink's promise is that "well, your engineers might not be able to program using code, but hey, they all know circuit diagrams -- let's let the program using those! Software is simple anyway: if you are able to express yourselves in circuit diagrams, you can do anything. And its graphical! Shiny!!"
And yes, in toy examples or in trivial lab control scenarios, Simulink and LabView work. In behemoth software projects, they do not, but after a few years (and big efforts by Mathworks and LabView to push their products into universities) we now had a large workforce that had
So Simulink grows. Simultaneously, the software stacks in the industry grow exponentially (in terms of compiled code size, we have about three orders of magnitude more code today than 15 years ago, and no sign of slowing down).
Problems occur -- problems with scaling that the software industry have solved in the 1980s (and again in the 1990s, and again in the 2000s). How do you reasonably version control Simulink models? They are in practice binary blobs that compile down to less-than readable C/C++ code. How do you diff a graphical giant model? How do you even collaborate within the same project if there is no reasonable concept of branching and merging? How do you write sufficient tests for graphical programs? In another graphical program that generates code over which you lack control?
Those are unsolved questions, or at least not solved in an acceptable way. When asking Mathworks engineers regarding this, the response behind the lines is often "Why oh why do you write such giant projects in Simulink?", and indeed, why? A workable diffing tool has been vaporware for at least a decade by now. There are third-party solutions -- let's just say that they are not that useful (expensive, though).
Imagine developing the Linux kernel
and then you have the world of graphical programming in large-scale projects.
My company is starting to feel the pain in a very real way, and there is a surge to move towards writing C again, hiring software engineers this time. Turning a ship with tens of thousands of engineers who have made their careers using Simulink since they left school is a very painful experience, but either we absorb the pain, or we accept exponentially growing software issues in cars in the wild and the costs that entail.
It's a drag and drop environment with lots of options and the more software installed, the more options. So, that technically means you can't make an "automation" without hoping that the other person has the same applications. But, as long as you use what comes with a Mac by default, you'd be alright. Xcode developed software can be all drag and drop. There are some other "drag and drop" related software that are game engine related like Game Maker (Game Editor for open source clone), Unity3D, and Unreal Engjne. Matter of fact, Blender's Game engine is unique in that it's written in Python, so you could use its chart-like style (they're obsessed with nodes) to create something.
Agilent VEE is pretty close to top-down flow charts. I've used it for years. Mainly used for test and measurement like Labview
And you whipper snappers wonder why we old guys are grouchy? Because you keep re-inventing the wheel thinking that you are smarter than everyone else.
Enter the CASE tools -> https://en.wikipedia.org/wiki/Computer-aided_software_engineering ...from 1968
Take a look at www.outsystems.com
The C# code is generated from a visual model which is a flowchart.
e.g. https://www.outsystems.com/platform/
Try Flowgorithm
http://www.flowgorithm.org/
scratch: https://scratch.mit.edu/ I once saw a person designing a SAP (https://www.sap.com/index.html) system connecting modules with graphical arrows, you only needed to write code if specific details were needed.
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.
I think scratch is a flow chart-y language. Certainly is colorful.
Of course, I wouldn't do anything serious in it. It's just a nice way to introduce a pre-teen to flow control and language basics.
Help! I'm a slashdot refugee.
Flowcharts have been used to generate working code for at least 50 years. I did some in 1965. Totally useless, does not work well, never will. If you want to code, learn the language. Learn how to program. Get some training and peer review. Above all, find something wirthwhile to spend your time on. The fact is, most people can't code very well, and they never will be able to, just as most can't sing operatic arias, or play pro basketball. This is not anyone's fault. This is just the way it is, and there is nothing anyone can (ever) do to change. it.
Scratch from MIT might be what you're looking for too. https://scratch.mit.edu/
Must be. Why i've not seen anyone use a flowchart since they were forced to in school. No sir, the _best_ way to code is just sit down with an idea and start banging out code. 'cause that's just the best way and everyone can do it. Yup, bang away run the code look at the errors correct them bang away run look ... repeat until you get something that works as hoped once. Thinking about your code before coding? For absolute ninnies, not even noobs. And if you doubt the quality of the product well my friend you just have a browse through github or through the reams of quality apps in the app stores.
Besides you're hinting at something like turning documentation into code and that's just frickin' heresy. Ain't nobody got time for documentation if you're following the preceding coding process properly. Documentation is for the next sucker who looks at your code and who cares about them? Dumb question, dumb idea, now shut up with the questions and bang out some code loser.
"Consensus" in science is _always_ a political construct.
The popular one in the DoD and Intelligence Community is Feith System's Workflow IQ
Besides you're hinting at something like turning documentation into code and that's just frickin' heresy.
Python doctest allows you to write example code in the documentation and then execute the example code as test cases. Useful for simple functions but a bit hairy for complex functions and classes.
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/ .
It meant "Software Through Pictures" but we knew it affectionately as "Software Through Pain"
https://en.wikipedia.org/wiki/...
Do you know what a function or a class is?
http://flowgorithm.org/
It converts flowcharts to C#, C++, Delphi/Pascal, Java, JavaScript, Lua, Perl, Python, QBasic, Ruby, Swift 2, Visual Basic .NET, and Visual Basic for Applications (used in Office).
A lazy manager's dream; Disneyfication of complex stuff and let minions graft away.
Visual programming works well until tedious stuff like exception handling and complex transaction processing kick in.
Once I observed a well spoken, nice and bright guy implementing a relatively easy web service in something called TadeXpress. Every issue that could have come up did. Performance, exception handling, inability to easily link to stuff I wrote. Eventually TadeXpress was kicked out and good old programming was reinstated.
As with anything, the devil is in the details. Visual programming still isn't done well. If it were most of us would actually be using it.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
If you can't visualize the code, you can't write it. I don't care how you see it, but you must see it.
Granted that was twenty some years ago, granted, but it was enough to give me insight into the concept.
Basically, it sucks.
A picture may be worth a thousand words, but that doesn't make pictures a substitute for language, as anyone who's tried to deal with a stroke victim will attest. Flow charts may have their uses, particularly to describe complex and somewhat arbitrarily constructed processes, but they're a lousy way to describe algorithms and calculations. That's why most people don't use them anymore.
Diagrams of various sorts are useful tools in communicating with other people and in noodling about processes. But that doesn't make a diagram a practical, comprehensive solution. And invariably somebody adds code generation capabilities to things like UML diagramming software. The labor saved is never very significant, because it automates a process that's easy for a competent programmer.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I recall back in the day of paper magazines seeing ads for a tool that claimed you drew flowcharts with decisions and it created a program. Long time ago...back when you had Dr. Dobbs, Programmers Paradise, etc. I always wondered what happened to that tool and the oodles of others that seemed to be unique for programmers.
How do you think kids learn programming these days.
Yeah, now I remember that Mindstorm programming thing. It was kind of interesting, but again you couldn't push it too far. You could write maybe a modest sized program that way, at best. For the intended purpose it was reasonably well-suited, but I'd note that people quickly outgrew it as well. The other thing to note with Mindstorm was that is was purely a single-threaded and very linear kind of a thing. That put some pretty heavy constraints on what you could actually do with it.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
If you are fluent in JavaScript then take a look to NodeJS based NODE_RED.
Show me a tool that can take a relatively complex text-based program, render it as a flow chart, and then only using the flow-chart, convert it back to the same textual program - I won't hold my breath.
Flowcharts are high level abstractions that leave out far too much detail. A program written in text has all the details.
Things done in a single line of code would be represented in the most complex fashion in a flow-chart, if at all (like closures, list comprehensive, Elvis operator assignments, etc.).
I would note that both of those are interfaces to Smalltalk, though it's not clear to me that they need to be.
OTOH, I remember back long ago trying to program in Prograf, and there was an MSWind database system that was also programmed only graphically. YUCK!!! It wasn't that the logic was any harder, it was that you couldn't see nearly enough of the program to write anything sensible. Text can be a lot more compact, so you can see an entire function at once. Graphics takes up hugely more room, so you can't. And somehow when you collapse a portion of a graphics system it isn't as meaningful as when you collapse a function with a sensible name.
I think we've pushed this "anyone can grow up to be president" thing too far.
Yes, you can write C using a flow chart. Unfortunately the flowchart requires at least 193 spatial dimensions.
Take a look at LabView. It is drag-and-drop, but you still have to know what you're doing. It's oriented to automating experiments in the lab, but is a true programming language. And, although I haven't tried it, am told that it can compile programs (which typically run inside the LabView environment) into binaries.
One of my students made an accounting, inventory, and customer database program for his business, for example, in LabView.
To add a historical reference for a couple of software dev tools I thought were cool in the early '90s:
Mainstay Software released VIP Basic and C (Visual Interactive Programming) for the classic MacOS. You drew the flowcharts, they cranked out the source code. I have no idea what the quality of the code was, but for budding Mac devs, I'd guess it gave them a starting point.
Luke, help me take this mask off
This has been done numerous times by various companies and none of them ever achieve main stream success. SSIS might be the most successful for it's specific purpose.
A decade ago MS LightSwitch was a thing: https://msdn.microsoft.com/en-us/library/ff851953.aspx... It might still be a thing I just haven't kept an eye on it.
As far as I can see, no one have mentioned http://www.flowgorithm.org/ - which as far as I can tell is the exact answer to your question!
Well at least the last part: "draw a flowchart, and have that flowchart turn into working C code"
In Flowgorithm you draw a flowchart, which can be executed! And turned into source-code from whatever language you desire (well, most, it supports C#, C++, Delphi/Pascal, Java, JavaScript, Lua, Perl, Python, QBasic, Ruby, Swift 2 and Visual Basic.)
As many other have commented; flowcharts was never *that* useful when developing. But I've often used flowgorithm when I need to quickly make a diagram explaining a particular behavior. Much faster than Visio (at the cost of you can not change the layout/position). I find the UI very well made.
In many machine learning frameworks, the programming effort is to create a computation graph which can be efficiently implemented on a GPU. The Tensorflow API says "TensorFlow computation graphs are powerful but complicated. The graph visualization can help you understand and debug them".
It is a pity they provide no direct visual way to manipulate the graph, as well as view it.
It is strange to have to write code to put other code into a graph for later execution.
The language is called Blockly, and it translates into other languages with a click. While not exactly a flow chart, Blockly appears to be puzzle pieces.
Yes - the proprietary webMethods Flow language has a visual editor where you use flowcharts to program. Note, programs don't exactly look like flowcharts - just rectangles with lines between them. Programs are stored as XML files on disk. At runtime, the XML is mapped to Java operations.
I remember using fairly early UML modeling tools back in the early 2000's, but there were earlier incarnations of the concept. TBH I never found UML all that compelling. It has some uses, but truthfully a well-written description of some software and API documentation is far handier than any amount of UML.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
ObjectVision was designed to build working code just by drawing flow charts. For the very small subset of things it could do, it worked fine. But for anything else (like renaming a file, for example), you had to write "normal" DLL entry points, which you could call from ObjectVision.
It was a perfect illustration of why you DON'T want to write code this way.
You mean like LabVIEW?
We had a grad student who did his thesis on flowchart programming at Brown U. -- in 1966. You drew flowcharts on the IBM 2250 display and the underlying code could be FORTRAN, PL/I, or System/360 Assembler.
I did a system for the Navy in the early 80s that let you code sonar systems for the AN/UYS-2 in dataflow diagrams. It's still in use.
https://msdn.microsoft.com/en-us/library/bb483088.aspx
I was on a digital turbine engine controls team (jet engines!) and we needed to translate a graphics control system illustration into working realtime control software at Bendix, now part of Allied Signal / United Technologies I think.
We developed an amazing ASCII Art-like graphical design interface to program it. In that each control point in the reference diagram had a corresponding computer graphic control point. Some control points allowed inline assembly, but all in a visually easy to inspect manner.
The goal was to be able to quickly and unambiguously show exactly what code corresponded to reference design specification, critical for customer and flight worthiness approval.
Most web development needs to execute 1000 times faster than critical engine control software development that CAN NOT fail or easily be fixed after release. So I'm not sure contemporary web developers would necessarily be more productive with graphical programming, but I can say that it made defects and inconsistent code much easier to review and inspect.
Yes, for example this: http://www.andescotia.com/prod... which is a modern implementation of Prograph.
Kinda. For very simple data-flows, SSIS can do that from drag-and-drop chart building that resembles UML. For more complex things, you will still need to write some basic SQL in SSIS.
https://www.youtube.com/watch?...
This is exactly what you are asking for. Had a small hand in this product's creation it's very slick.
Murphy was an optimist
Finite state machines are "box and line" drawings much like flowcharts, but are much, much more powerful -- like flowcharts on steroids. FSM's are visual representations of logic and they are also executable models which can be directly transformed into production code in model-driven development / architecture. Anything that has logic to it can be modeled with FSM's, so it's possible for example, to model a business workflow using an FSM and then use that FSM of the business process to begin the software development process. FSM's are graphical mathematics, so there is a direct way to apply mathematical concepts to your code structure based off the graphical FSM diagram. UML does have statecharts (based off Harel statecharts), which are FSM's with the concepts of Venn diagrams added. I personally prefer Moore models of FSM's for modeling website behavior. Mealy models of FSM's are also available. Petri nets are closely related, but slightly different, and can be used to model concurrency along with UML statecharts. A truth table format also describes the same logic. The three graphical FSM notations (UML / Harel statecharts, Moore models, and Mealy models) as well as Petri nets can all describe the same things in different ways. I just released a class on Udemy about engineering models for software & web developers that lays the groundwork for these concepts and places them in relationship with all the other engineering models software & web developers can use. My name is Ken Krauss and the class name is "Intro to Engineering Models for Software & Web Developers" on Udemy dot com. Use code "SLASHDOT" for more than 50% off regular price. I have more classes planned on the topic as well.
The answer is yes, its called BizTalk.
I have used 2 systems that were based on flowcharts. The first one was called Octane that used Visio flowchart elements to develop sections of code we used for middleware. Problem was it was so damn slow and we had to go to tons of training just to do simple things. I hacked thru the system and could see it was just generating javascript on the backend. So I just wrote the javascript directly. Funny thing is that the parser would then auto generate all the flowcharts for me. The second is DirectShow for video on Windows. The GraphEdit program lets you visually draw the flowchart of media objects (files, streams, encoders, decoders, effects, etc) and just connect them. You can then use to chart to generate code.
Flowcharts, as I was taught them, are almost completely useless. They suck at design, documentation, and every other use I've seen. There are times when some sort of box diagram is useful for design and/or documentation (it's normally useful to keep the design notes around), but actual flow charts? I haven't seen a good use for them in well over forty years.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
http://velocio.net/ace/
Try explaining H.264 encoding without a flow chart.
I am very small, utmostly microscopic.
For trivial applications. I suppose non-trivial apps are possible too, at least in principle, however the amount of work you'll do defining your app in pictures probably isn't worth it.
If you program with crayons, you get crayon-worthy output.
As Camembert mentioned, Authorware was one of the first to let e-learning developers build flows and then publish the code. Though it was really easy to use it was pre-www and a Flash-like plugin was required to have it stream. Low bandwidths at the time also meant it was really only useful for intranet applications. Since then, the founder of Authorware created ZebraZapps, which is a SaaS tool using a more robust flow charting to output code either as .ipa or .apk apps or as Flash. They're working on an HTML5 player version so that people won't be forced to distribute to desktops via Flash, but authoring still requires the plugin.
I once worked on a project that did exactly that - you drew a flow chart by dragging flowchart elements into a grid, and then connecting arrows between them to indicate flow. A rounded start bar was required to indicate the beginning of the program, and after that it could go through any number of rectangular or diamond blocks. You can give each block a name, then double click it to "zoom in" to that block and develop the code within it. Once drilled in a new blank grid would appear, and you could drag in different operations -- read a value, write a value, add, subtract, etc. So for example you could read a counter value, send that the a plus operation along with a constant of 1, and send the output of that to a write counter value. The contents of a diamond block used a special return operation that would set the true/false direction of the program. You could even do parallel programming, after a fashion, by using a double horizontal line to spawn multiple "threads" that would execute simultaneously (actually cooperatively). It was actually a fully featured language, and except for setting labels you didn't even need to use the keyboard at all to code. The target of this was embedded controllers like PLC's, and this was back in. And this was back in the early 90s.
I had to use this software called Plantworks which used a graphical flowchart programming environment.
It was awful. Run away from any programming language like that.