>By the way, everyone, join me in congratulating Ed on receiving his Doctorate in Computer Sciences from Yale. Way to go Ed! Or should I say Dr. Rauh? :-0
>

That's fantastic! Congratulations Ed!

>
>
>>>>
>>>I agree with your position on this issue. However, I also am not reallly interested in seeing VFP go .NET as the features we would lose in this are not limited to macro expansion (ME). There is a lot more about fox that would need to be compromised.
>>>>
>>>
>>>Agreed. In all material respects - VB .Net is VFP sans the data specific parts of the language..
>>
>>Here, I disagree; it's a strange bastardization of VB-like syntax wrapped about a p-code based threaded interpreter; in my view, it has the feel of Java or Eiffel, substituting a VB-like syntax into the interpreted object language setting. Almost an attempt to conceal its real language roots, wrapping the object language in more familiar keyword names. Unfortunately, while it may make the apparent code expression have a more easily recognized set of operators, their behaviors vary from the comfortable syntactic form of the previous version of the language. The result is considerable frustration, stemming from "What in ^&*$%# is wrong here? It used to work like this..."
>>
>>The syntactic resemblance between C++ and C# is a lot closer than VB 6 is to VB.Net - in fact, an OO language is masquerading in the cloak of VB. That's why the existing VB community is disturbed, much as died-in-the-wool xBASErs were frustrated by VFP and Clipper 5.2 when they appeared - moving into the new paradigm made huge chunks of familiar code stop doing what we expected, and going to the new approach forced us to unlearn lots of comfortable strategies before we could grok how the new stuff acted.
>>
>>In this respect, moving beginning developers straight to C# ended up letting promising developers become productive faster, as they didn't have habits and instinctive practices to change. The syntax is (opinion) cleaner, more consistent, and equivalently capable (opinion more expressive, making it more capable) to VB.Net. Since both shared a common runtime environment, data representation and interface, and allowed for a common debug environment, we have more developer resources available, since unless a module needs internal maintenance, a different language can subclass, wrap or adorn a CLR-based service or class, at least in theory. C# is a more natural fit for me than VB.Net at least.
>>
>>
>>>But for a fox developer to dismiss .NET is a very large mistake. I've been around long enough to remember the mainframe cobol programmers who said the pc was just a toy and would never amount to anything. Many of them found themselves out of work a short time after they said that.
>>
>>There are things that CLR languages will do that we won't - in addition to threading issues, lower service call overhead since they may not need to rely on as much InterOp service, which has a cost in performance, lower install complexity (for the executables) and portability to non-Wintel platforms that offer CLR support should be seen easily. It depends on how far from the Wintel architecture the CLR languages function; remember, Java and C++ are examples of languages which in theory you "write one and run everywhere"; the reality is that while it's doable if you rely on a common subset of functionality, perhaps enhanced by portable common libraries, the vast majority of these apps are platform-limited, and the reality is far closer to "write once and debug everywhere."
>>
>>>Even for the developer who intends to stay with VFP as their primary tool, it will become necessary for them to access .NET stuff from fox. When our clients find out that their systems can do this or that, they will demand that we supply the feature in the systems we build. The time to learn how to do this is NOT when the client asks, but rather before the client asks.
>>
>>I think that broadening our perspectives is a necessity, since so many parts of the environment require language skills other than VFP - login scripting, ASP, and system maintenance are examples.