We demo'd a software called filebound earlier this year when looking at a document management solution and it left a hell of an impression on me.
Most business systems are built off of the concept of the "enterprise infrastructure" being the printing press for the front end infrastructure, and the back office being the back end infrastructure. When the Xerox printer was first introduced, you had a "rapid prototyping" system for business processes inwhich the xerox machine represented the front end and back office being the back end.
The "Next Gen" of business systems and processes was computerization and mobilization. We had mainframes and then the litany of "enterprise" architectures such as .net\SQL, Java\Oracle, LAMP, or SAP, and "rapid prototyping" architectures such as Paradox, MS Access, and so forth. That produced an alphabet soup of system types, jargon, TLA's, and business processes and lots of profound thought into designing businesses.
These "program a flowchart" languages we've seen, which are largely driven by certain MS SQL server features, are really great at building business processes because all of these systems have always had menu's, forms, data, and reports as the building blocks of the business process. By flow charting the business process as part of the programming, you end up with better visibility by management into the flow of the business system. The revolutionary item with filebound is backing up the flowchart with the data (so we know how things used to be done), being able to show changes to the flowchart and make notes (are we repeating the same mistakes?), being able to separate structured and unstructured data (hint: your "enterprise class" business system should be rigid and scalable, and should is your data structure), supports modularity (filebound in particular supports vb and powershell scripts as blocks in the chart), all while proving a certain degree of access to management to build and play with things like the original xerox machine did. Filebound also has some really nice automation capibilities; e.g. you can sit one end-user with minimal education and have them configure the system to structure data out of e-mail, e-mail attachments, or scans, and you can report on their accuracy and any errors that occur as examples, all using some pretty advanced OCR. Building forms is click and drag as well. Best part is, if management needs to really understand the system, print out the flowchart on 11x17 and hand it to them. Even the oldest coot will "get it".
Not that I'm plugging their software in particular, but when I saw a few short demo's, it left a real impression as to the future of business system programming. Imagine taking several flowcharts and exporting them as a business process; management would become very familiar with the data structure and system structure and where it's deficits and benefits are, and that is a good thing because you are forcing them to understand the structure of their business.
There's always going to be a place enterprise class business systems because scalability and rigidity are features. When the auditors show up, they know what great plains database tables to go look at. That's a benefit to them. When you have all sorts of things modified, they begin asking lots of rough questions.
"Real programming" is going to live everywhere else there aren't business systems and there's a lot of places where it'll fit in. You are not going to be able to build cad to cam software using a flowchart. No freggin' way. Try doing nested tree's. HA!