>I don't feel like I have to provide any proof of what I said because it was merely a prediction in a thread that had already gone hypothetical, but I suppose I can try.
>

You do not need to offer proof per se. Rather, in order to boost the credibility of your position, you do need to offer the basis you use to make the conclusions you make. While I may not agree with the rationale, I may nonetheless have to accept it as rational. i.e., while I may disagree, the reasoning may be sound and rationale. If you don't offer the basis of your reasoning, it is hard, if not impossible to properly evaluate your position. Further, productive discussions cannot exist.

As your career progresses, you will find the answer and conclusion is not nearly as important as the rationale and means you use to arrive at that conclusion. Your credibility and the degree to which people will take you seriously will depend on it..

>
To me, its an evolutionary process, if we use the same thought process and designs to develop frameworks for new ways of developing applications, I feel that a failure has occured. So, instead of your typical frame work consiting of object managers and a standard set of base classes, I envision something else. It could be any thing, but my guess is something that you can drag and drop and draw lines between that generates VB.NET, C#, or even MSIL code directly.
>

Based on this passage, the critical element of a "new generation" of frameworks is code generation capabilities. It has been pretty well demonstrated that "code generators" don't work that well. For one thing, a code generator cannot predict the endless scenarios the code will be deployed.

IMO, the next generation of frameworks, which I see .NET being part of that class, takes care of the "plumbing". In addition, a rich set of classes exist that I can implement. Also, a lot of the mundane details - such as deployment, etc are taken care of. I don't see coding as a mundane task - and I don't mean to insinuate that you think it is a mundane process either.

With all of this said, I don't agree with your premise that "code generators" via a drag and drop interface makes for the next step in the evolutionary process. FWIW, code generating frameworks via code templates exist today and have existed for quite some time...


>Heres why, it all has to do with what I see in Web Services. If there are a gazillion sweet Web Services available, and only geeks know how to tap into them, they've failed. However, if my mom can sit down at a computer, and design an application by drawing a picture something like:
>
>Application, I want you to download all the files off my digital camera when it gets plugged in, send them to Kodak to get them processed, drop the finished photos in My Pictures, and record this in My Document\myphotos.xls spread sheet so I can review it later with every other batch I've done.
>
>that would a success. Thats a simple example, but a start.
>

I could go after this on technical grounds. However, I will first go after the point on economic grounds. How many non-programmers out there have a need to develop an application like this? My guess is not that many. Therefore, the time and expense to develop a framework that would provide this type of capability would be an unprofitable enterprise if your premise is the correct end.

If a non-programmer wanted to develop applications, they would be programmers. < BG >..

The fact is, developing an application that you describe would not be that difficult. If you break the problem down, you will see all the technology required to develop such an application exists today. IMO, the next generation frameworks make it easier to build the components for the type of application you describe. For example, I should not have to worry about obtaining and registering external controls that manage the winsock connection, file transfer, etc. At some point, I will need to write the code that leverages the functionality in my specific sitation.

Using this as a backdrop, what you describe makes for a good product specification - not an application development framework specification.

<<
Once that architucre is in place, it could be strecthed to design bussiness applications. Something like:

Application, when an order is placed that meets the specified criteria of 200 or more hamburgers, I need you to search the Web/UDDI, find someone selling enough meat at the cheapest price, bid on it, send me a .NET/AOL alert whereever I happen to be if the seller accepts or rejects my offer, get the appriate number of buns from my standard bun seller, make sure I have enough fixings in stock, have the supplies sent to manufacturing when they arrive, put this customer in my frequent fryers database and the sales person who made the deal should get something special and notified through email.
>
>Wierd, and probably not that logical when perishable goods are involved, but I think there's room for products like that, which will be the successor of what we think of as frameworks. From there, its only a matter of time that full business applications can be written, and databases can be designed in this way. All you need to do is slap on a glitzy UI builder and editor and we've got it.
>

These type of systems exist today. Have you ever heard of or studied Just in Time Inventory concepts? The question is not whether a framework can build this system for you. The question is whether frameworks exist to make it easier and more efficient to build these type of systems.


>
With the openess of the CLI and .NET in general, I think its possible. Wether or not that happens, I'll stick by what I said in my orginal post: if you are waiting for .NET application frameworks and only looking for somethign comparable to what already exists, you'll be missing the action.
>

.NET by itself brings more to the table. It would not take a lot of work to build a .NET app framework that would provide more capability than what is currently available. Between providing more capability and what you describe above - let's just say that a lot of ground exists...


>
No, but them I woudln't really know. 50 years ago they were thinking about flying cars and video phones, I'm pretty sure that someone promised in the same era that a computational device that was easy to command woudl exist.
>

Your 50 year context was in the province of programmers. Here, you have extended the premise a bit.

>>As far as the non-developer is concerned, as commercial frameworks become available, I do agree that it will be easier to put *rudiementary* apps together. Of course, you can do this today with Access...< g >
>
>Eh... sort of.

You can build rudimentary apps with zero code provided by the developer in Access - period - not sort of... In the Que Book Absolute Beginner's Guide to Databases - which I just finished and is due to be in bookstores in March - I prove this point - that you can build rudimentary apps in Access with no programmer provided code. Keep in mind that I use the word *rudimentary*