Walter,
I can only speak for eastern part of the U.S. in general, and specifically the Northeast part of the country - more and more companies are looking to convert apps and build new functionality in .NET. In the last 6 months, I've had direct communications with 5 organizations who are looking to do so. I personally know two other developers who have had similar experiences. I've spoken with professional recruiters who have had similar observations.
You said that it's a waste to spend time on a technology that is 'known to go down the drain' (and I'd also ask you to qualify that statement with details). Why don't you go over to the .NET forum and make that claim? Does that mean that the amount of time Kevin McNeish spent on the Mere Mortals Framework for .NET (and the time and money invested by his customers) was a waste?
Yes, I fully agree that the databinding in .NET isn't great. If I could have a genie come and grant me three wishes, one would likely be to have the guys who designed data binding actually write a data-driven app with the capabilities they designed. Believe me, .NET could have been much better from a RAD standpoint. I don't dispute that one bit, and there are many aspects of the VS.NET IDE that I find disappointing.
Toward that end, I spent time last year and early this year building some functions to 'bridge the gap'. So right now, I can build a 'mom and pop' app in about the same amount of time that I can in VFP. Not only that, I actually have.
I'm more judicious than I used to be about third party controls - but I will say that I've had fewer problems with third party .NET DLLs (and I've evaluated many) than I ever had with OCXs in VFP (and I fully realize that's more an issue of OCX authors...with few exceptions, most only care if they work in VB 6).
We didn't lose one contract - we lost multiple contracts. I've seen the writing on the wall. So have many. That doesn't mean that one can't sustain a good career in Fox right now. But what it does mean is that more and more new development projects are being done in .NET in companies where Fox had a presence. That is a trend that will continue.
It may be a few years before the majority of people see it - but those who are taking steps to learn it will continue to be at potentially greater advantage. Take a look at message 908188, posted by another forum member. (The author of the message may disagree with everything else I'm saying here, but I've referenced it as yet another example of the reality of the market.) You can acknowledge the market trend, or you can stick your head in the proverbial sand.
I don't like to drop names, but this was the general message from JVP a few years ago, and he was 100% correct. I've read through most of his posts for the last several years on this topic. Early on, I didn't agree with him. Then I realized I was disagreeing because I felt very threatened.
I was being facetious in my last comment. My point is that not learning a second technology right now could have an impact on one's security tomorrow. I don't accept the belief that one can't be an expert or at least very strong in multiple languages. My calling cards are VFP, C#, ADO.NET, Crystal, T-SQL, and Office Automation (with thanks to Tamar/Della's book on that last one). Yes, I agree that being able to do design work, needs analysis and requirements, leading a team, are all important skills that are independent of technology. As a consultant, I have to wear many hats, as most of us do.
But I think that some people have become so married to one technology (in this case, Fox) that it makes it difficult for them to learn other ones. Just because a technology doesn't explicitly support REPLACE ColumnData WITH ColumnData + 1 FOR
, or LOCATE FOR AND , doesn't mean it can't be effectively simulated, and that you can't learn something about the technology along the way.
Those have been offered as examples of huge shortcomings of .NET for certain applications. Having replicated those functions and having put together some of 'those' types of apps in .NET, those are facile and knee-jerk arguments.
And I'll rephrase an argument I made before - if a VB developer criticized VFP because API calls were so much 'cleaner' and because so much code had to be written in VFP to replicate the same functionality, why would the argument be any different?
Kevin
