John, over at gonzomaximus, asked me to respond to his latest post ("The future is cloudy") - I would have directly on this blog but he has comments disabled, so here I am.
I think part of the confusion may have been from my previous post about his World of Tomorrow where I commented that there are a lot of free or low-cost how to's for DotNet.
Since he did ask, I will respond point by point. I certainly don't expect this to become a "read here, read his response, read my response, etc" but I think it's useful to see where this is coming to. (and hey, John - when you get some free time - why not come onto the FoxShow and really tell us how you feel!)
1. Yes, we know you're crazy - oh you said BORDERLINE crazy - sorry, I'll take that back.
2. I agree that to effectively use DotNet, you DO have to get into it a fair bit and likely a lot further than most FoxPro developers ever delve into FoxPro. Just yesterday, I was at a developer strategy meeting and one of the invited guests commented on how to really get the greatest benefit from DotNet, you need to learn how how DotNet handles multi-core, multi-threading, WPF, etc, etc. (I'll come back to that in a minute) It's not simply a "build your app" approach. Another case in point, I just did a Microsoft E-Learning course (a great learning resource) on upgrading from VB 6 to Visual Studio 2005. The basics of OOP and projects aren't anything new to VFP developers - what was interesting however was the attention spent on garbage collection and stack vs. heap, etc. This was in a fairly introductory course, in my opinion (why I took it is a different story) - so I was surprised to see that level of content.
But then, I thought about how frustrated FoxPro developers get when they have to debug stuff that cause C5 errors and have to learn about garbage collection. So it IS valuable to learn.
Also, while many FoxPro developers can make a great application without really getting further into Windows details, some of the really cool things we've seen recently are thanks to developers getting further into the Win32 API than most would want to.
3. I completely agree with John that the majority of FoxPro developers started because they wanted to solve a business solution whereas the majority of C++ developers started out wanting to become developers. But Dotnet also attempts to resolve some of the things that C++ developers need to worry about, via C# and the CLR. Yes - there are still some things that you need to be aware of, but you don't have to be aware of EVERYTHING as you had in the past.
4. Why would you want to mix XAML and VFP? I think there are a few reasons and YES - the pure geeky "fun" of it is one but the other is something I've commented on in the past. With a good understanding of XAML (or XUL or anything similar), where you can essentially build the foundation of a user interface with basic XML, what is possible? You can build your front end for a web app and then still maintain your backend with whatever database you wanted to. My personal enthusiasm comes down to something I LOVE to do with my own VFP applications - and that is to make it extendable (extensible?) at the user level - support dynamic scripting, runtime manipulation and more. If I could find a way of letting users design their own forms at runtime (ok, actually I HAVE done that within VFP), or better yet, find a way that I can make design changes dynamically, I think that's a win-win.
Unlike many developers, I tend to take a "get in, get out" approach to consulting. Every business (that contacts a consultant) has a problem that needs to be solved - sometimes they are big and do require a lot of analysis and project management - but othertimes they are small and don't need the "body shop" approach - they need the "here's the problem, let's get it solved" - and in those cases, I'm intrigued by the possibilities that XAML does offer.
(now I'm not a XAML expert, and I may have a lot of this wrong, so don't hold me to this as the approach but ---) Consider a VFP business component that also had the ability to send down a custom UI using XAML and then it could be customized for whatever platform it needed to be on. What possibilities are opened up to you if you could CHANGE what your application looked like dynamically without recompiling? (here's where I'm sure others will weigh in and tell me - you wouldn't be able to do that - but if I can do it in VFP, I'm sure there's a way to do it elsewhere)
5. Why not Adobe Flex/Flexbuilder? Why not Filemaker? Hey - everything's a tool and you pick the tools of your choice. I've glanced at Adobe Flex, I'm also intrigued by other RIA environments (Gears, etc) - certainly Silverlight isn't the only choice but it is ONE.
John - your main point "that .Net architecture just doesn't work the way most VFP developers are comfortable with." is valid. Of course, it's a marketing exercise to push VFP developers to the DotNet platform but there's a valid reason for doing it beyond "your application works - why change it?" The reason was brought up at the strategy meeting I mentioned earlier - yes, VFP SP2 is coming out ( Rick Schummer has Milind Lele saying that VFP would only get the "Works with Vista" logo - not Certified for Vista) - so what would happen if a future SP of Vista breaks something in VFP 9 SP2 apps (similar to the visual glitch that many have recently commented on) - would Microsoft issue a HotFix for it?
And while they have recently changed their approach to Google Desktop search, would they do it for a set of loosely-related apps for a handful of businesses?
It's this argument that many consultants will and do use against VFP's continued approach as a platform.
I'm all for finding the right tool to do the job - and Visual FoxPro is the right tool for many jobs - because it gets the job done FASTER and usually better - and I'm sure we'll all sit back and wonder about whatever happened to with a variety of other tools (I still miss NextStep).
So back to am I missing your point? (a LONG WAY back - jeez this is a long post)) - no, I'm not - I'm getting it but Microsoft is offering a suite of development tools to move from beyond the current Windows desktop to a specific future they are building (updated from: believe is coming) (64-bit, Web x.0, mobile devices) . Other vendors are also doing the same based on what they feel is happening. The sad thing is that Visual FoxPro won't be there to make it easier on developers to build the solutions that will need to be built.
But hey, let's not just write about it - come onto the FoxShow and let's talk about it! (when you have time , of course)
I think part of the confusion may have been from my previous post about his World of Tomorrow where I commented that there are a lot of free or low-cost how to's for DotNet.
Since he did ask, I will respond point by point. I certainly don't expect this to become a "read here, read his response, read my response, etc" but I think it's useful to see where this is coming to. (and hey, John - when you get some free time - why not come onto the FoxShow and really tell us how you feel!)
1. Yes, we know you're crazy - oh you said BORDERLINE crazy - sorry, I'll take that back.
2. I agree that to effectively use DotNet, you DO have to get into it a fair bit and likely a lot further than most FoxPro developers ever delve into FoxPro. Just yesterday, I was at a developer strategy meeting and one of the invited guests commented on how to really get the greatest benefit from DotNet, you need to learn how how DotNet handles multi-core, multi-threading, WPF, etc, etc. (I'll come back to that in a minute) It's not simply a "build your app" approach. Another case in point, I just did a Microsoft E-Learning course (a great learning resource) on upgrading from VB 6 to Visual Studio 2005. The basics of OOP and projects aren't anything new to VFP developers - what was interesting however was the attention spent on garbage collection and stack vs. heap, etc. This was in a fairly introductory course, in my opinion (why I took it is a different story) - so I was surprised to see that level of content.
But then, I thought about how frustrated FoxPro developers get when they have to debug stuff that cause C5 errors and have to learn about garbage collection. So it IS valuable to learn.
Also, while many FoxPro developers can make a great application without really getting further into Windows details, some of the really cool things we've seen recently are thanks to developers getting further into the Win32 API than most would want to.
3. I completely agree with John that the majority of FoxPro developers started because they wanted to solve a business solution whereas the majority of C++ developers started out wanting to become developers. But Dotnet also attempts to resolve some of the things that C++ developers need to worry about, via C# and the CLR. Yes - there are still some things that you need to be aware of, but you don't have to be aware of EVERYTHING as you had in the past.
4. Why would you want to mix XAML and VFP? I think there are a few reasons and YES - the pure geeky "fun" of it is one but the other is something I've commented on in the past. With a good understanding of XAML (or XUL or anything similar), where you can essentially build the foundation of a user interface with basic XML, what is possible? You can build your front end for a web app and then still maintain your backend with whatever database you wanted to. My personal enthusiasm comes down to something I LOVE to do with my own VFP applications - and that is to make it extendable (extensible?) at the user level - support dynamic scripting, runtime manipulation and more. If I could find a way of letting users design their own forms at runtime (ok, actually I HAVE done that within VFP), or better yet, find a way that I can make design changes dynamically, I think that's a win-win.
Unlike many developers, I tend to take a "get in, get out" approach to consulting. Every business (that contacts a consultant) has a problem that needs to be solved - sometimes they are big and do require a lot of analysis and project management - but othertimes they are small and don't need the "body shop" approach - they need the "here's the problem, let's get it solved" - and in those cases, I'm intrigued by the possibilities that XAML does offer.
(now I'm not a XAML expert, and I may have a lot of this wrong, so don't hold me to this as the approach but ---) Consider a VFP business component that also had the ability to send down a custom UI using XAML and then it could be customized for whatever platform it needed to be on. What possibilities are opened up to you if you could CHANGE what your application looked like dynamically without recompiling? (here's where I'm sure others will weigh in and tell me - you wouldn't be able to do that - but if I can do it in VFP, I'm sure there's a way to do it elsewhere)
5. Why not Adobe Flex/Flexbuilder? Why not Filemaker? Hey - everything's a tool and you pick the tools of your choice. I've glanced at Adobe Flex, I'm also intrigued by other RIA environments (Gears, etc) - certainly Silverlight isn't the only choice but it is ONE.
John - your main point "that .Net architecture just doesn't work the way most VFP developers are comfortable with." is valid. Of course, it's a marketing exercise to push VFP developers to the DotNet platform but there's a valid reason for doing it beyond "your application works - why change it?" The reason was brought up at the strategy meeting I mentioned earlier - yes, VFP SP2 is coming out ( Rick Schummer has Milind Lele saying that VFP would only get the "Works with Vista" logo - not Certified for Vista) - so what would happen if a future SP of Vista breaks something in VFP 9 SP2 apps (similar to the visual glitch that many have recently commented on) - would Microsoft issue a HotFix for it?
And while they have recently changed their approach to Google Desktop search, would they do it for a set of loosely-related apps for a handful of businesses?
It's this argument that many consultants will and do use against VFP's continued approach as a platform.
I'm all for finding the right tool to do the job - and Visual FoxPro is the right tool for many jobs - because it gets the job done FASTER and usually better - and I'm sure we'll all sit back and wonder about whatever happened to with a variety of other tools (I still miss NextStep).
So back to am I missing your point? (a LONG WAY back - jeez this is a long post)) - no, I'm not - I'm getting it but Microsoft is offering a suite of development tools to move from beyond the current Windows desktop to a specific future they are building (updated from: believe is coming) (64-bit, Web x.0, mobile devices) . Other vendors are also doing the same based on what they feel is happening. The sad thing is that Visual FoxPro won't be there to make it easier on developers to build the solutions that will need to be built.
But hey, let's not just write about it - come onto the FoxShow and let's talk about it! (when you have time , of course)
Powered by ScribeFire.
Comments