>Fred,
>
>I'm not talking about an app generator, nor anything like it.

Neither am I. I'm talking more like in the movie Minority Reports, where Tom Cruise is manipulating things virtually in thin air. <g>


>What I am saying is that it baffles me why after 20+ years of development, things are in such a sad state of affairs in the software world. Computers were supposed to make our lives easier!

>Yes, I can burn production grade DVD's on my home computer and I have access to more information (through the internet) than I ever dreamed possible. Yet, to develop a simple application I need to learn the .net classes, (or other class set) and then learn the language of my choice, (C#,VB or any of the other ports or choices), a set of reporting classes, a set of data handling classes, and either write my own framework or learn someone elses, not to mention the acutual business model that prompted the need for the software in the first place.


True enough. The in-depth knowledge required to even do something as simple as a "Hello World!" program is staggering.


>In the current development model, these products may be developed and sold by different companies and have dis-similar styles and dis-similar goals. Since we will be using a disconnected set of software options it will be a nightmare to keep the whole mess rectified over a long haul. You think dll hell was hard, wait until we have to start dealing with upgrades to each individual set of classes or softare packages. .NET 2.0 may or may not be compatible with LINQ 1.0 and when you move from .net 3.0 to .net 4.0 will link 1.0 still be compatible. How long after .net 4.0 will linq be compatible. How about when you decide that a great third party set of classes is just what you need but they are not up to speed on .net 4.0, but the new features in linq .2.0 are just what you need and it requires .net 4.0.... and so on.
>
>.NET hell. It's will be the future!, You won't even have a say in when Microsoft upgrades the .NET framework. Windows Automatic Updates downloads updates to the framework and you don't or won't know about it until your customer calls and say's your software is no longer working.


Certainly going to be interesting in those circumstances. Guess who will have to deal with the fallout? (You (that's the collective all of you) and me)


>At least in VFP, most of what we did was in the same product and we could choose when to send out an upgrade to the runtime. In VFP, we have a programming language, a UI, native data handling, native reporting, the ability to connect to almost any data source and options for incorporating addtional classes when needed. When you upgrade a combined language, data handling, UI and reporting, about the only thing you have to worry about is if the third party classes work properly or if the user's current OS is compatible with your software.


Not that VFP didn't have its own learning curve, but yes, it was much simpler than .NET.


>In .NET, you get programming language, UI, and a set of generic classes and that is about it. Everything else is dependent on a third party or a disconnected product from the same vendor.
>
>As an example:
>Let's assume I went to my FORD dealer and purchased a truck. With the new software model, I would only receive the body and frame. It would then be up to me to purchase and (somehow) install an engine, suspension, a wiring harness, an interior, safety features (air bags and such) as well as a set of tires and then it would be up to me to somehow get everything to work together properly and then get the vehicle past emissions inspections and federal safety inspection. How is this better than just purchasing a completed truck.


Pretty good and true analogy. Don't forget, the road would also be subject to change in their model. ;)


>I'll say it again, in my opinion, the .NET programming model takes us backwards, NOT forwards. Over the last few years (and the next few years) ODBC, OLE, ACTIVEX, COM, COM+ and any number of other hot MS creations have been or will be phased out.
>
>Yet, the one thing you can still do is:
>
>"USE c:\mytable.dbf" and have instant access to your data.
>
>I don't see any reason why Microsoft could not create (or advance) a complete and comprehensive AND CONNECTED one product solution to what should be a simple process.
>
>It will be many years before we get back to the simple and efficent software development enviroment we already have in VFP. MS could have added to VFP: greater than 2 gig support, 64 bit support, native encryption for security, classes slimilar to .net, and on and on. In their infininate wisdom, they decided not to. Instead, we get .NET. A horribly disconnected and bloated set of software solutions.


I think Microsoft's target audience is the Fortune 500 (or even bigger) Enterprise type companies. They seem to have forgotten the "little guy" and what got them started to where they are today. They've lost touch with the real world.


>Welcome back to the stoneage.


You may be right after all.