>This leads me to wonder why most of the discussions center on .Net? It is true we are losing VFP but why does everyone assume .Net is the only way to go. I never see anyone discuss other alternatives.

Yes, we could discuss python here as Thomas mentionned! the Dabo effort has met limited success here.

Python has A LOT IN COMMON with VFP except it is not a "supported" software. I have spent sometime with it (and i still do). I'm currently reading the wxpython book. Worth it.

Python has a clear syntax (not à la ruby...) but, yes, no clean and unified environment, limited documentation and few commercial events that are mostly targetted at engineering staff.

I was at europython and did not like it. Cool and smart people but no business drive nor interest in the kind of issues we - VFPers - tackle.

The issue here is that future ex-VFPers will move into many distinct sub-tribes, none of them using a tool with a clear and productive path for the style of win32 client applications we use to develop:
- those stopping the development of win32 client stuff,
- those moving to C#, might be worth if you develop packages, otherwise productivity will get a very severe drop,
- those moving to Basic,
- those moving to python,
- those quitting development.

C# as a replacement for delphi or C or java, why not? C# as replacement for the smart VFP interpreter?

More than three months full-time learning and you're not even slightly productive, even die-hard programmers. That certainly makes some sense for MS in terms of getting a complete monopoly, over bodies and brains.

But for programmers that's a joke, yes and a bad one. "open source" is alas the only long-term solution for this industry. Whether we like it or not. I personnaly do not like it. But well what other way to "sort-of" control the way this industry evolves?

François