Tracy,

in one of the follow-ups a much better syntax for the C# version was presented - you might look that up.
>
>I don't see that as an overwhelming rave for Python over C#. I see it as a preference. I agree with the ease of programming in VFP. I also agree with his statement: Since it is a general truism in the software industry that the number of bugs per thousand lines of code is constant irrespective of programming language, the more you can get done in fewer lines of code, the less defects you will have in your software.

In these type of discussions most of the time it is "my [type of] language against yours" istead of trying to identify divergent factors or traits, which are more or less pertinent to your project.

There is the "quicktest"-factor (just to avoid any discussion on "scripting" <bg>) vfp shares with python, ruby, groovy and javasript sought for non waterfall-scenarios.

There is the "safety" factor of design by contract java and .Net excel in - usually a growing need with growing size of enterprize/developer team. BUT: adding XML config /"system" files into the equation opens a backdoor exempt from such rigorous checks. As this seems to scratch a big itch in static languages, why not include such a *possibility* into the language proper instead of "retrofitting" it via external files ?

The scripting languages usually have one highly tuned data structure: with vfp this is local tables/cursors, with python dictionaries and tuples. At least it lessens the danger of the novice to pick the wrong structure <g>. But after seeing apps using about between 10 and 30 controls all bound to small cursors for each cbo/listbox and capable of N screens you want rub the dev's nose on the fact that small cbo's can be fed from a common table into arrays on each cbo, eliminating about 150 5-item cursors when a number of screens are up. But for experimental data munging vfp is still the best. But for most biz apps a simpler object model is good enough.

On the other hand on Joel's comments was a rant about the proliferation of *servers* needed to house and administer the uncontrolled growth of tiers in a large system - bureocratic brittleness can creep up everywhere.

Vfp's container/embedding hierarchy is IMHO one of the things easy to overlook - but it can cut both ways, if you program too much "knowledge" depending on the parent into your contained objects.

The same goes for the rapid screen painting: directly coupling/binding backend fields is a MS fallacy seen in many examples<g>. And every time I encounter a 100+line screen event, I wish for something less "easy".

You might look up articles "python is not java" and "java is not python, either" on how it is best to change your coding style with the language used - some of it maps nicely the differences found between .net and vfp.

regards

thomas