>>>We may be guilty of not willing to let go off a good hammer, even when everybody else is switching from nails to glue. Because it's still a good hammer. I'd actually rather like to have screws and a driver instead, glue doesn't hold that fast nor long.
>>
>>I have an impression, Dragan, that you are condemning things before you know/learn them.
>>
>>I'm not sure whether extrapolating memories of another day is always a good thing. The world has changed since GWBasic
>
>Well in another message I said that I like to have strong typing when I need it, even if it's on by default - that's cool - it's just that I don't think it's the best and most important thing to have, and that I would absolutely hate it if I couldn't turn it off when I need to.
>
>Other than that, I gladly went into roleplaying, just to present the view. My programming habits aren't that hardcore; I am actually a proud chameleon programmer, more or less fitting into any naming convention, environment and whatnot. But in a free discussion like this, I tend to express my preferences.
>
>And C# is not a bad language, it's just a bit too much oriented towards the apps Microsoft wants to make, but it looks flexible enough to be able to do other things just as well. But I simply don't trust Microsoft. Once there's a C# by a different vendor, and that vendor doesn't have to play catch up with M$ every few months (i.e. the specs are public and the code developed for one compiler runs the same when compiled on another), then... I may change my mind.

I understand your hesitancy in selecting another MSFT tool. It is a scary proposition for anyone who has used a MSFT tool in the past, let alone VFP.

However, I am surprised at your disenchantment with C# (not sure if that is the appropriate word). I really like it. It is pretty easy to switch to from VFP. It is the framework which takes some time to get used to and informed about. In some ways it is much easier to work with than even the old foxbase was when I first started with it in the early 80s. There is so much information online and so many examples to look at plus intellisense is there which pretty much prompts you along the way. The compiler points out missing implementations so you don't overlook that as well.

What I have noticed more than anything is not a lack of available examples of typical implementations online, but rather a lack of examples of using different types of patterns. Just as with VFP the majority of developers didn't develop physically separate ntier apps, the same is true of .net. There are a huge amount of examples of typical data manipulation and web apps, but not of different patterns and true multiple tier separation or even SOA. One example is my recent research on using entity classes in an ntier design with reports in SSRS and Crystal in .net. I found very little help out there and had to invest a huge amount of time testing it myself and getting it to work. Now I am running into that with the MVP pattern. It's out there, but there is a lot of hemming and hawing over it, a lot of blog information not really inline with the standard, and not a lot of true standard implementation available online to look at. Even the MSFT wizzes will differ on their implementation suggestions. The same is true of method driven or event driven design. Sheesh. One expert says go this way, another one states no go this way. Everyone has the inside scoop on MSFT's future plans yet their recommendations are different. So essentially no one knows anything.

Back to your hesitancy on using an MSFT tool: I'm not sure any other tool would have more support, more users, more information available, or more longterm investment. If there is anything that is guaranteed these days, it is change. But don't worry, I don't think it's that far off to a day when programmers will be obsolete and users and business execs will be designing their own interface and databases with point and click by answering a few simple questions and dragging and dropping their controls on a web form.

Maybe we should all just become moose hunters :o)

(Just wanted to add one really big (HUGE) pet peeve of mine in VS2008. You can't set a breakpoint on a value such as a form prop and stop processing in the debugger whenever the value changes from any where in the solution like you can in VFP. That drives me nuts! You can set conditional breaks at a specific point, but that is not the same - not at all)