John;

Those developers who do not listen to your words and apply what you have stated will suffer the consequences.

Tom

>Hi Mike..
>
>First off, let me say that it was nice to finally meet you in person @ the summit.
>
>I definitely agree that Web Services/SOAP will play an integral part in application development in the future. Web services, IMO, solve many more problems than they create.
>
>As far as VS .Net is concerned, I do believe it *is* the future. Having dived into the product, I believe it now more than ever. And keep in mind, I was one of VS .Net harshest critics. Beta 1 sucked! Beta 2 and the RC's are distinctly different and evolved product!
>
>History has demonstrated that people who are early adopters of MS technology, those who "ride the wave" do well. The big difference this time, IMO, is that from a technical standpoint, VS .Net is better than anything MS has produced in the past.
>
>Why am I so optimisitic?
>
>
>1. VS .Net is the culmination of a long-held strategy
>
>Some 8 hears ago, Roger Heinen - then MS's VP of database/developer tools announced the unified tools strategy at the 1993 Fox Devcon in Orlando. 8 years later, after a series of incremental steps, we are there. This has been the end game and MS has been comitted to it. For a long time, MS has preached language independence. They have preached to think in terms of "objects". From a practical standpoint - it was difficult to be language agnostic because the various language environments had disparate object models. This gets to my next point...
>
>2. Complete object/language independence
>
>Take the System.Windows.Forms namespace. When you learn it or any of the other classes in the .Net framework, you have learned it - period. Regardless of whether you implement the classes in C#, VB, or any other language that is built on the CLR - the object paradigm remains constant. This fulfills the promise that was made 8 years ago. When thinking of consistiency, one must also look at the environment itself...
>
>3. Consistiency in the development environment
>
>Whether you are building a windows app, web app, or a mobile app - the development metaphor remains constant. In days gone by, you would have to go to a clunky tool like Visual Interdev or some other tool. Today, you get to work with the same basic designers.
>
>4. The Development IDE
>
>The way help and docs are integreated into the development IDE is nice. The ability to click back and forth between pages - one that contains a help document or a whitepaper on the MSDN site is very nice.
>
>5. Integegration with the OS
>
>The ability to create windows services, integrate with perfmon, the event log is now a snap. These items, while doable - were not as easily accomplished as they should have been.
>
>There are more reasons for optimism - but these are the big ticket items.
>
>The important time period is not today. Rather, it is 18 months from now. Right now, folks will take a big dip in productivity. Anytime there is a fundemental paradigm shift - such as the case with VS .net - you will definitely take a step or two backward. But, if it results in taking 10 steps forward - it will be well worth the investment
>
>In 18 months, I imagine there will be several VS .Net frameworks - ala the frameworks in Visual FoxPro. I think there will be a slew of controls ala Sheridan's VBAssist tool that will make the development environment more productive.
>
>As far as today is concerned, it requires some imagination and some effort. An example involves tooltips. Today, we simply populate the tooltiptext property on a control and enable tooltips in the form. In the System.Windows.Forms Namespace, you have to instantiate a tooltip object and reference the form control that is to leverage the tooltip object's services.
>
>Seems pretty non-intuitive - but from an OO perspective, it is probably more thoerhetically correct. Once you get the hang of things, you find it to be a very predictible environment.
>
>Another example..
>
>Right now, we are used to having a rich langauge with lots of functions. I think C# only has about 45 keywords. Let's say you want to convert the following string to a datetime type: "12/31/2001"
>
>In VFP, we would issue this code: CTOT("12/31/2001")
>
>In VS .Net (and I emphasize VS .Net, not a specific language because this sort of thing is in the framework - not a particular langauge) - you would invoke the services of the Convert Class
>
>Convert.ToDateTime("12/31/2001")
>
>Whether you are working in C# or VB, the syntax is basically the same. The only noteable difference is that C# code must terminate with a ;. Bascially, everything is a freaking object! If folks have embraced objects - they will LOVE the environment. If folks have stayed largely procedural - it will be a challenge.
>
>Data and data binding right now is a bit kludgy. It is a PITA. But - it can be done. This is one area that I beleive will get a lot of attention by vendors.
>
>The important point at this juncture is that the proof of concept has been made. From here on out, things will only get better, more efficient, more optimized. I do believe in prognosticators like the Gartner Group - when they say that 95% of windows development will be in VS .Net. IMO, developers who are not tinkering around with VS .Net ,learning how it works (and getting frustrated with how it works at times!!!) - are making a BIG MISTAKE.
>
>Developers who are banking on Web Services being the critical thing in VS .Net - IMO - are also making a BIG MISTAKE. Web Services are but 1 piece in a big puzzle. There is no question that VFP being able to consume and create web services is a good thing for VFP. Reality however is going to dictate this: for every 1 VFP/Web Service job - there will be 1000 VS .Net jobs. I think it is a grave mistake for folks to not make the investment now so that in 18 months, that person - like everybody else, can get his/her own slice of the pie. The nice thing now is that people have the luxury of time. People can go at a leisurely pace learning how VS .Net works. 18 months from now, folks will be ready to work on a project.
>
>Am I advocating people shift away from Fox? No way. But, it would be folly to think that there will be nearly as many VFP jobs as VS. Net jobs. To not make the commitment now - to both learn VS .Net and to learn how VFP can work with VS .Net is a bad career move. If I were to quantify the time investment, I would use the 80/20 rule. In my education efforts, I would spend 80% of my time learning VS .net and 20% learning how VFP can work with VS .Net
>
>VS .Net is the future of Windows Application Development. To believe anything else - I say to them...."Denial is not just a river in Egypt..."