There are a lot of great tools for building simple forms that talk to databases and generate reports. At some point when it comes down to the things that separate this from from all other forms already created someone needs to actually build the form. It's a boring few minutes and then it's done, but then they want to change something and someone needs to fix that. And so it goes.
You missed the point. A skilled, creative programmer will write their own utility or framework to generate the boring stuff. Assuming they've done that well, feeding the form specification to your form compiler is all there is to it.
I think your missing the point. We already have form generates so filling out a from specification is what the programmer is doing. At some point there is nothing left to abstract and you need to specify what's happening. Doing that is programming and it's boring. For any complex system it becomes repetitive in novel ways such as: What's the best layout for the form? What data are we willing to take? etc. And once that's done you are always going to need to fine tune it which is boring.
PS: The logical next step would be to hand the customer your form generating software and get them to solve their problem, but that just ends up with someone debugging a horrible Access database. (Or whatever system you build.)
In summery: Specifying a specific form specification to collect or show useful information is programming. (Say that 3 times fast.)
Defining the specifications of a form could be considered programming, as is defining formulas in a spreadsheet application. In this thread, I don't believe the definition of programming includes Excel users.
Creating an application for building forms (e.g., Wufoo) is programming, building a form with Wufoo is not.
Note, I like the idea of getting non-programmers involved in programming activities. However, just because you work as a programmer and get stuck with things a non-programmer can do doesn't mean programmig is boring, it means you have a boring job.
If your using Excel for simple data entry that's one thing, but like most advanced forms of this idea it's got a Turing complete scripting language. Access works the same way. If you know nothing about programming you can quickly create a huge mess that almost works.
I think you get the same then for any significantly advanced Form generating software. At some point you need to link 2 elements and do some math and you end up starting the whole ball rolling again. How would you build the "perfect" form generating software for a Pizza Topping Selector so the client can change any part of the interface in any way they want at any time and have any discount they want for any list of toppings? ... Great now is your form generator simpler than just writing the code?
PS: You can talk about just the GUI but tools like visual studio are already have GUI tools for building GUI's.
I think your pizza topping selector example is dead on. Because yes, that's your task as a programmer. You deliver a pizza-topping-selector-configurator that has all the flexibilities built in that the client needs and it will be easier to use than actually writing code.
Your job is also to extend said configurator when the client has new ideas (e.g. a new rebate system) but your job should not be to carve the forms for individual pizza's (which probably change by the season) into code. That's exactly where I would draw the line, thanks for providing this example.
Let's say they want the ability to have themes which automatically occur for special events. Now you have the back end (keeping track of the order), GUI (what the user sees), interface builder, script builder (Interface for deciding which themes show up when), topping interface (name, cost, picture), Discount builder (for groups of toppings and groups of pizza's).
But, what is this script builder and what is this interface builder, and discount builder? Well we want scripts that can change the interface and add the holiday special toppings, and change the billing information. And we want a nice interface for changing the look and feel of the website. Great, but who is going to use them and what are they going to be doing?
A: The most flexible interface is always code. It's also to complex for the average user to understand. So we constantly get this pattern n * Developer > Script builder > Script Selector > User. The secret is creating the most useful easy to debug scripting language. You want them to say 2 weeks before Easter and they don't have to worry about when the full moon is.
PS: Once you realize your building a scripting language it's a good idea to consider what type of language your building http://www.paulgraham.com/langdes.html because while it might be fastest for your script to be written in the same language you code in your users want something that looks no more complex than BASIC. (See: Excel) However, if they want you to build the script's then you can just use your language / IDE and EVAL the script.
