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
Plus Simulink coder.
Google Scratch. 2.0 makes it turing-complete but it's not exactly API compatible
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"
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
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.
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>
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?
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
Which leads to the case that people have a hard time to break down a problem into components that are easy to maintain and test.
But in many solutions there's also the problem that those that codes don't even understand or know the environment the system is going to be used in. Like the fact that there's sometimes icy roads - explain that to a person in Bangalore where the only place you see ice is in drinks.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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
If you think conservatives are the best at selling out, you probably need to learn more about Bill and Hillary Clinton.
lucm, indeed.
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.
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/
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.
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.
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.
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.
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.
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.
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
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."
I don't know the reason, but there is one, and it must be a pretty good one. That is enough proof for me.
Technology Pega is a Business Process Management system.
Good for the scope that it is in. But would get cumbersome when things get too complex where you need to edit the Java code for the stuff that is out of its bounds.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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
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.
Scratch from MIT might be what you're looking for too. https://scratch.mit.edu/
Incorrect. Spectacularly so. There is hardly anything less conservative than a family that has made politics it's profession of choice for more than a century.
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/...
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.
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.
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.
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
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.
"Ah, If only I had a nickel for every time a slashdotter said AI would never be reliable..."
"OK, ordering 384,243 nickels from coins-r-us. Warning. Your account will be overdrawn after paying rent at the end of the month. Please replenish funds."
Someone had to do it.
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.
They'll still be programmed. Programming is the breakdown of a problem into it's logical ornithological pieces. Coding is what will go away, and I can't wait. Even if you get rid of coding, you will still have the problem that most people can't program. Training is statistical in nature. Great when you want statistical results. You still have the issue of being able to determine if the data you have is actually representative of the results you want.
I've worked enough with customers, and a lot of other programmers, and people typically can't clearly describe what they want done. They will have all kinds of contradictory or logically impossible requirements.
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.
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.
They are specialized tools and then they are generalized tools. Programming language are general tools like a hammer, screwdrivers, a knife. Where most all problems can be solved with them, but it may take time. Specialized tools say a wood lathe can do a lot less things but what the do the do very well. However always having the right tool for the right job can get expensive. And from the sound of the article the poster wants a general purpose development language designed with flowcharting.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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
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
Try explaining H.264 encoding without a flow chart.
I am very small, utmostly microscopic.
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.