I'm sure that could happen. But I've also seen lone, self-taught developers writing very sophisticated apps to do specific tasks, in VFP.

What domain-expert-written apps have, that developer-expert-apps rarely have, are those aspects of domain knowledge that make the differencefor those who will be using the apps. As we're all pretty much aware, knowledge exists separately from the articulation of that knowledge: the domain expert will look at the form they've created, feel there is something wrong with it, identify it and then fix it. And that will occur over several iterations. Put that in a an "expert does all the development" model, and you have a communications nightmare, if there is any complexity in the domain being modeled. Articulation is always iterative, gets better with repetition, and so the meetings go on and on: the idea the client can "approve a story" ignores the likelihood that if the story were to be rewritten each day for 5 days, it would like continue to change, as details became assimilated.

Where domain experts hit a wall it's one that the expert-developer can help them with. In my case, it typically means writing a component that let them do the same things next time, but easier.

So, tools that domain experts who are not expert developers can use in my experience lead to better apps, provided there is on-going technical guidance (and framework development) by someone versed in the technical side of things.

What does not happen, looking back over 10 years of working with domain experts, is that they become technical experts. Even if they are capable of designing huge and complicated applications, they don't delve into the technical aspects of things. They learn what they have to learn, and leave the technical specialization to someone else. Many times I'll look at code they've written and say "oh, there's a property we can set that will take the place of those 20 lines of code." They then take that and use it.

So I'm all for it, if it allows manager to develop apps. I can write the framework or components needed to get technical details correct, and they can do the rest. It's a great division of labor.

>I could waaayyyy off, but I think KittyHawk is a .net written almost entirely RAD development system designed to hook the younger crowd (as in younger than teens or around the teen years and managers who want to do their own programming). To me the question is, can you take a KittyHawk app and redesign or improve it via any of the existing .net tools ??? I see possibly a lot of mid-level or higher managers doing fancy screens with little business logic and then handing it over to a developer to fix it or improve upon it when they got to the point of no return...
>
>
>
>>Yes, but the announced plan (by Paul Vick, who was on the VB team at the time) in 2007 was that the VB that shipped with VS2010 was to be a dynamic VB, codenamed VBx. That didn't happen; so will we see it, perhaps as the language underlying Kittyhawk? If anyone knows, they aren't telling. <s>
>>
>>>Isn't it in the list under CLI languages?
>>>
>>>Snippet:
>>>
>>>VBx: A dynamic version of VB.NET built on top of the DLR. See VBScript and VBA as this could be thought of being used like a Managed VBScript (though so far this name has not been applied to this) and could be used to replace VBA as well.
>>>
>>>
>>>
>>>>From the list, I see that VBx (the dynamic VB that was planned, in 2007, to be VB10) disappeared, unless I've missed something.
>>>>
>>>>Will we ever see it?
>>>>
>>>>>Here's a partial list of .NET languages.
>>>>>http://en.wikipedia.org/wiki/.NET_languages
>>>>>
>>>>>>Of course, as I point out to Craig in another post, .Net of today is not the .Net of 2001. Languages being created on the .Net of 2010 could not have been developed on the .Net of 2001, and only with great difficulty on the .Net of 2005.
>>>>>>
>>>>>>To think that .Net consists of C# and VB.Net (and maybe F# for the functional static programmers) is to miss the point of how .Net has evolved in the past 5 years. The speed difference between static and dynamic languages is basically eliminated by innovations in the DLR, based on real-world testing. So now it's down to what language does the job better for a given individual, in a given context: there is no more straight-jacket.
>>>>>>
>>>>>>The predictable result (from systems theory) is that differentiation in languages will lead to consolidation into sub-species. It will be interesting to watch over the next 10 years to see what language emerges in the dynamic + data sub-species.
>>>>>>
>>>>>>Hank