Successful Non-programmer, 5GL, Visual, 0 Source Code or Similar Tools?

Question

Can anyone give me an example of successful non-programmer, 5GL (not that I am sure what they are!), visual, 0 source code or similar tools that business users or analysts can use to create applications?
I don’t believe there are and I would like to be proven wrong.

At the company that I work at, we have developed in-house MVC that we use to develop web applications. It is basically a reduced state-machine written in XML (à la Spring WebFlow) for controller and a simple template based engine for presentation. Some of the benefits:

• dynamic nature: no need to recompile to see the changes
• reduced “semantic load”: basically, actions in controller know only “If”. Therefore, it is easy to train someone to develop apps.

The current trend in the company (or at least at management level) is to try to produce tools for the platform that require 0 source code, are visual etc. It has a good effect on clients (or at least at management level) since:

• they can be convinced that this way they will need no programmers or at least will be able to hire end-of-the-lather programmers that cost much less than typical programmers.
• It appears that there is a reduced risk involved, since the tool limits the implementer or user (just don’t use the word programmer!) in what he can do, so there is a less chance that he can introduce error
• It appears to simplify the whole problem since there seems to be no programming involved (notoriously complex). Since applications load dynamically, there is less complexity then typically associated with J2EE lifecycle: compile, package, deploy etc.

I am personally skeptic that something like this can be achieved. Solution we have today has a number of problems:

• Implementers write JavaScript code to enrich pages (could be solved by developing widgets). Albeit client-side, still a code that can become very complex and result in some difficult bugs.
• There is already a visual tool, but implementers prefer editing XML since it is quicker and easier. For comparison, I guess not many use Eclipse Spring WebFlow plug-in to edit flow XML.
• There is a very poor reuse in the solution (based on copy-paste of XML). This tampers productivity and some other aspects, like fostering business knowledge.
• There have been numerous performance and other issues based on incorrect use of the tools. No matter how reduced the playfield, there is always space for error.
• While the platform is probably more productive than Struts, I doubt it is more productive than today’s RAD web frameworks like RoR or Grails.
• Verbosity

Historically, there have been numerous failures in this direction. The idea of programs written by non-programmers is old but AFAIK never successful. At certain level, anything but the power of source code becomes irreplaceable. Today, there is a lot of talk about DSLs, but not as something that non-programmers should write, more like something they could read.

It seems to me that the direction company is taking in this respect is a dead-end. What do you think?

EDIT: It is worth noting (and that's where some of insipiration is coming from) that many big players are experimenting in that direction. See Microsoft Popfly, Google Sites, iRise, many Mashup solutions etc.

Answer 1

Yes, it's a dead end. The problem is simple: no matter how simple you make the expression of a solution, you still have to analyze and understand the problem to be solved. That's about 80-90% of how (most good) programmers spend their time, and it's the part that takes the real skill and thinking. Yes, once you've decided what to do, there's some skill involved in figuring out how to do that (in a programming language of your choice). In most cases, that's a small part of the problem, and the least open to things like schedule slippage, cost overrun or outright failure.

Most serious problems in software projects occur at a much earlier stage, in the part where you're simply trying to figure out what the system should do, what users must/should/may do which things, what problems the system will (and won't) attempt to solve, and so on. Those are the hard problems, and changing the environment to expressing the solution in some way other that source code will do precisely nothing to help any of those difficult problems.

For a more complete treatise on the subject, you might want to read No Silver Bullet - Essence and Accident in Software Engineering, by Frederick Brooks (Included in the 20^th Anniversary Edition of The Mythical Man-Month). The entire paper is about essentially this question: how much of the effort involved in software engineering is essential, and how much is an accidental result of the tools, environments, programming languages, etc., that we use. His conclusion was that no technology was available that gave any reasonable hope of improving productivity by as much as one order of magnitude.

Answer 2

Not to question the decision to use 5GLs, etc, but programming is hard.

John Skeet - Programming is Hard
Coding Horror - Programming is Hard

5GLs have been considered a dead-end for a while now.

Answer 3

I'm thinking of the family of products that include Ms Access, Excel, Clarion for DOS, etc. Where you can make applications with 0 source code and no programmers. Not that they are capable of AI quality operations, but they can make very usable applications.

Answer 4

How about Dabble DB?

Of course, just like MS Access and other non-programmer programming platforms, it has some necessary limitations in order that the user won't get him or herself stuck... as John pointed out programming is hard. But it does give the user a lot of power, and it seems that most applications that non-programmers want to build are database-type applications anyway.

Answer 5

There will always be "real" languages to do the work, but we can drag and drop the workflow.

I'm using Apple's Automator which allows users to chain together "Actions" exposed by the various applications on their systems.

Actions have inputs and/or outputs, some have UI elements and basic logic can be applied to the chain.

The key difference between automator and other visual environments is that the actions use existing application code and don't require any special installation.

More Info > http://www.macosxautomation.com/automator/

I've used it to "automate" many batch processes and had really great results (surprises me every time). I've got it running builds and backups and whenever i need to process a mess of text files it comes through.

I would love to know whether iHook or Platypus (osx wrapper builders for shell scripts) could let me develop plugins in python ....

There is definitely room for more applications like this and for more support from OSX application developers but the idea is sound.

Until there's major support there aren't many "actions" available, but a quick check on my system just showed me an extra 30 that i didn't know i had.

PS. There was another app for OS-preX called "Filter Tops" which had a much more limited set of plugins.