Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Another reason you *should* to go dotNET
Message
From
29/05/2004 03:04:24
Walter Meester
HoogkarspelNetherlands
 
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00906864
Message ID:
00908407
Views:
26
Hi kevin,

>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.

I won´t deny that .NET has gotten more focus off companies. That is basically where Microsoft is positioning .NET for.

>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?

IMO, AVALON, YUKON and LONGHORN will have tremendous impact on how we develop applications. .NET is just a step in between as I see it. How this will affect current .NET applications be developped, I´m not sure and AFAIK, Microsoft is not sure either. This is personally reason enough to wait a few years before seriously considering the .NET alternative to VFP.

Me going over to the .NET forum and telling this would be the same thing as going to a VB forum and telling them that VB6 is the end of the line, before Microsoft made this publically known: Not going to be constructive.

>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).

So you did invest a lot of time in writing classes, evaluating third party controls and learning .NET. Time that I personally do not have. I need to stay productive to meet deadlines.
When the time comes that VFP does not offer me any work we´ll evaluate the situation and see what we´ll do. There is no rational into FUD.

>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.

I guess that is true, and if you´re a consultant that is hopping from one project to another then I think learning .NET is not a waste of time, *if* you can afford to do so.

>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.

Why. I don´t see any advantage for those who learn it now or those who will jump when neccesary. The learning curve has to made somewhere and you better learn somthing when you need it than a few years in advance, Possibly learning techniques that are obsolete when you really are getting productive with it.

There is really no need in telling people what to do. They can take care of themselves very well. There is no need to spread FUD up here about VFPs future. It is more harmfull to VFP than you can imagine. I´m specifically upset with people saying this because IMO they are very harmfull to the VFP community.

>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.

A self forfilling prophecy. JVP, also suggested people should learn VB. Well, knowing the facts about that now, you can see hat harm it can do.

>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 think the people up here are smart enough to ensure their security one way or another. Your way of learning .NET is one of many others. For example, Build a few applications and sell them commercially with maintenance contracts is another.

>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.

I takes many years to become an expert. Though I regard myself an expert in VFP, I don´t know all aspects of developping applications in VFP: I don´t do anything with the web. I´d rather deepen myself in those technologies within VFP than looking at other languages. Currently Im learning a lot about healthcare aspects and technology, interfaces and Hl7. Technologies that are language independed, and for my profession more important than learning another language. It would probably take me a few month to reasonably find my way in c# to build applications. OTOH, it takes years to learn enough about healthcare to call me a healthcare IT specialist.

>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.

I think developping languages is the right term here. Yes, I´m married with VFP and as long as it is a good marriage I won´t divorce, or look too much to other women. When it becomes obvious that this marriage comes to an end. I´ve got to take the proper actions. Whether this is .NET or something else, we will see then.

>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.

I think the key here is flexibility, performance, ease of use, out of the box and comfortability.

>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.

Anyway you put it. .NET is not data centric whereas VFP is. This is a huge difference IMO. There are many VFP complex data hanlding commands that do not have a .NET equivalent, hell you can´t even do SQL wihtout relying on the database backend (No SQL on local cursors). This makes building data driven applications harder and more time consuming (at least in building the classes which can handle this complexity for you). OTOH, I will acknowledge that there not too many examples to find for real data driven designs.

>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?

The critic is certainly true. This is one thing in VB that is much easier than in VFP. OTOH, you´ll have to look at the significance of it. Building a fll in C/C++ might solve the issue for you. O.K. it takes more time, but really how many times do you really need to do this?

Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform