I'm not sure we're talking about hte same thing here and you typify exactly what Claude is talking about. You associate .Net with Web apps only which is very wrong. .Net will capture much of the Fat Client market as well, although this may be much slower than the Web market. And this has nothing to do with Web forms or anything related to Web technology at all.

I agree with you on HTML and even DHTML as a lousy front end for most applications. This is why I have been focusing for years on distributed applications, which can do quite nicely with local *or* Web access and can do so very well even over a slow connection. But .Net includes the tools to build rich client applications. The forms engine is quite capable - in fact way more powerful than VFP and VB, but it's very clumsy and a lot of stuff takes a fair amount of code. The .Net team should get a clue by looking at some of the nice features of the VFP forms engine - like how easy the databinding works without any dependencies on specific technologies. We can bind to objects, tables, arrays, ADO - anything at all and it all uses the same code. That kind of stuff is either impossible in other languages or requires all sorts of code or setting of myriads of cryptic properties (in .Net that is).

The biggest problem with the .Net forms engine is that it's very slow right now. Even slower than VFP forms which are about the slowest thing around in the MS tools. Luckily this isn't as big of a problem as it used to be now that we have 1ghz machines, but that's more of an excuse for slow code to not get noticed <s>...

I suspect that's because the focus of .Net is going in the Web/Distributed areas rather than Fat Client development, but that will change over time. I've said this many times, but I think once the full brunt of Web Services catches on with the general development community, Fat/Rich Client apps are going to come back in a big way with the distributed features built into a traditional rich interface. In fact, the CLR will speed this process because since everybody has the runtime downloading applications will be fairly small and self contained. With all the COM registration issues gone applicatinos once again can become fully self contained and easy to install/uninstall.

As to the Java/Perl issues - To people developing solutions with MS tools this is unlikely to be a big issue. Java claims to run cross platform (even server code) but in most cases doesn't not even across various similar Unix flavors.
OTOH, the MIS big shots who follow the party line will trump this up against *any* MS solution whether it has merit or not. Seen it a million times. If people want to spent millions of dollars on jobs that should cost under $100k that's their problem... I can't tell you how many porting 'attempts' I've seen from lug head management decisions that canned perfectly working applications for some pie in the sky multi-platform Java solution that either ran out of money before it got done or never got finished because the dev companies couldn't live up to their design specs. No doubt there are also success stories with Java - both large and small. But I've personally witnessed my share of VFP apps that were moving from VFP to Java - several of those companies died and went bankrupt because of that decision! Those that made up spent a fortune. If a quarter of that money would have been spent on the existing VFP projects the apps would have more than met the requirements set for the migrations and ended up with a more maintainable app to boot. But that's bad management decisions for you...

There's some merit to Java/Perl portability etc. But do you really want to build a business application front end in Perl???? I don't think so. Java at least is semi-high level. C# is in the same boat as Java...

>VFP is a full-featured programming language. It is my programming language of choice. It comes complete with a supper fast native database engine. It is a value that hard to beat. Compare its cost to the cost of buying a complex enterprise class database that requires additional outlays for the front end programming language. When you consider the additional cost in terms of money, time, energy and aggravation of programming a front end product, you can then truly appreciation all VFP provides.

We agree here. I look at different technologies all the time, and still I'm jaded <g>... I like VFP because with it I can build apps large and small, and tools, and little hacks in an instant - much faster than I could (even given I was more proficient at the tools) with anything else. Reduction of code more than anything - in light of .Net this is significant, because the CLR makes a lot of things a lot more verbose than previous similar COM based code.

For VFP Web apps the only possible problem could be scalability on the very high end. As I mentioned to Claude I think the vast majority of applications people build will not ever hit any sort of scalability issues on today's hardware. And if you do you can always scale out to multiple machines using load balancing services. The technology exists to build mass market access Web applications with VFP today that can handle just about any amount of traffic.

The possibilities of VFP applications are pretty much endless even in light of new technology emerging.


+++ Rick ---