I probably deserved that for not explaining myself more clearly.

My opinion of 4GL/RAD tools is not merely about the generation of code.
In fact, code generation is the least of my requirements. What I want out of a RAD tool is an integrated environment to control the entire product lifecycle from cradle to grave. CASE/ER/UML tools to get a view on the requirements. Prototypes generated from these requirements which can then be used as a template for a later build. Integrated version control and project
management tools. Aids to producing technical and user documentation as you go. I want to have my cake and eat it.


As regards my comment on frameworks, what I meant was actually that the 3rd party frameworks do not really inspire me. I been using one of the better known ones for over twelve months in my current job, and agree with my colleagues, who have been using it for over 3 years, that you spend most of the time either working around its limitiations or trying to figure out whats going on. Hardly my concept of RAD. The demos and docs of the others that I've downloaded, whilst having some redeeming concepts, are generally of the same ilk. One of the problems appears to be overloading of properties and methods making for complexity (anyone remember KISS?). I tend to get lost when my PEM sheet entries get into 3 figures. I always thought one of the benefits of OO was abstraction, making for black box programming.
Oh well...
Now, having you own framework is a different matter, but even this only helps in code re-use, and I want tools to aid me in conceptualisation (is that a word?)

However, I do feel you have a somewhat FoxPro bias towards other products. I remember the 4GLs of old, 15 years ago, I used Cognos PowerHouse, Oracle SQLForms and Informaix 4GL, but when I saw what you could do with Foxbase 2.1, I switched to PC development. However, modern tools like some of the ones I mentioned hardly bear any resemblance to those simplistic products.

>proportion of these developers who wish FoxPro to become as RAD-ish as you >describe is 5 percent or less.
Granted, if they lost the current features, but I find it difficult to believe that given the opportunity, 95% of people would do things the hard way. Are we all supposed to be masochists? Ahh! I've got it! We are all code junkies addicted to typing For..Next loops and With EndWith constructs.


>For further evidence of this, consider that VFP is probably the most open >product imaginable for extension by wizards and builders, not to mention >its fully documented and stable and native metadata structures. Creating >an application development wrapper/venir for FoxPro to do exactly as you >describe could not be easier in any other environment.
And yet it has not really been done, though VB, Java and C all have significant RAD toolkits, albeit at extortionate costs.

>VFP also has possibly the most competitive third-party framework market in >the known universe.
True, but that could also imply a lacking in the base product. On the other hand, I sometimes wonder whether its that someone has taken the time to write a framework for their own purposes and then tried to flog it to everyone else who can live with their coding style.

>Yet none of these framework vendors has chosen to take their offerings as >deep in this direction as you would like. The reason is simply that there >is very little demand for this type of development in the VFP community at >large.
I suspect the requirements I have in mind are somewhat more difficult to implement than a few addons in foxpro code.

>Why? Because the sort of RAD you describe is really useful for beginners >doing simple, predictable sorts of applications. There is very little >market for this.
Oh please. Most commercial development is simplistic. I want the RAD to do that for me so I can concentrate my woefully lacking brainpower on the nitty gritty, mean and nasty stuff.

>Moreover when you use such development systems, and need to extend beyond >their basic assumptive limitations, you are deep in doo-doo. I've seen >this many times: you can create a shell with standard functionality easily >enough, but when you try to create extensions that deliver some sort of >real competitive advantage for stakeholders, it's really tough, sometimes >impossible.
Can't be worse than trying to use the hooks in the framework I use. You cannot even mix and match forms and controls from different sources without serious grief.

>Moreover the view of RAD you describe is twisted and false. Pure snake >oil.
Granted the tools aren't everything, but they sure could help

>For the modern definition of RAD, the wholistic view, and in my opinion the >correct software engineering view, see the great book Rapid >Development by Steve McConnell.
Bin there, done that, bought the tee shirt. Also read Yates and Demarco and spent a couple of years at colege studying SSSADM, SMDM and Prince.
Plus, all the obligatory UML courses at Rational UK.
Most of the methodolgies come down to the same common sense applicable to building anything complex, whether a piece of software or a suspension bridge. The earliest steps (e.g. design and planning) should be the most careful, because each following cockup has a cumulative effect on the rest of the lifecycle!

BTW midly curious, whats the **--** for?

Regards

Malc
(Trading in the asbestos for shuttle armour)