Wednesday, March 14, 2007

The Fox is dead. Long live The Fox.



# 

I suppose once Wally blogs about a topic, it has broad developer interest. I read the news on Visual FoxPro specific blogs earlier in the day, and I emailed the story to my coworkers.  Today, Microsoft announced the end of active development on Visual FoxPro.

Personally, this is not a surprise in any way.  Ever since the announcement that VFP would never move to 64bit, I've known this day was coming. Furthermore, I spent a day with the Microsoft PM for VFP in January, and he gave no indication that the future would be any different. With that said, I want to share my thoughts on what this announcement means for Visual FoxPro applications and developers.

On a DotNetRocks episode, Don Box was asked if COM is dead.  His response applies to Visual FoxPro as well.  Don replied, "COM isn't dead, COM is done."  That is the best summary I can think of regarding this announcement.  Visual FoxPro isn't dead, Visual FoxPro is done.  We can certainly unpack that in a number of ways, but I will mention two details to back up that statement.  Microsoft is releasing service pack 2 for Visual FoxPro 9 to make VFP fully Vista compliant.  Microsoft has developed a set of .NET managed extensions to VFP named Sedna, and released these extensions as shared source. 

So, we have a stable, Vista certified platform with a bunch of Microsoft developed hooks into the .NET framework.  They have provided VFP developers everything they need to maintain their existing apps on the most recent version of Windows, and they have provided the tools to extend those apps using .NET.  Now, I don't think anyone is suggesting green-field development with Visual FoxPro, but any existing investments are fully support until 2015, and extensible with development tools that are under active development.

Furthermore, Microsoft has provided a plethora of materials to help experienced VFP developers leverage their existing skills while moving to a new language and development environment.  Here are some of my favorites:

  • .NET Samples for Visual FoxPro Developers
    This is a nice collection of solutions introducing VFP developers to .NET basics using Visual Basic.  I recommend VFP developers download these samples along with Visual Basic Express.
  • Visual FoxPro Toolkit for .NET
    I love this toolkit, although I've never actually used it.  Let me explain, this toolkit provides a DLL which users can register to access VFP syntax within Visual Studio in either C# or VB.  I've never actually done that.  I use the help and the provided source code as a reference when I want to learn how to do something in .NET for which I already know the command in VFP.
  • Interop Forms Toolkit
    This is super cool.  This toolkit was developed for VB6, but works great in VFP, or any other COM enabled language.  It provides a set of COM wrappers around a Windows Forms component, so that you can launch a .NET form from within your VFP app.  This solution is rock solid and fully supported.
  • Interop UserControl
    This last tool is my very favorite.  It is not currently supported, but I've been in touch with the developers, and they are making progress on it.  They have even fixed a bug that I experienced when using this in VFP!  Quite simply, this is a project template which enables you to create a .NET user control, and register it as an ActiveX control, allowing you to display new .NET features within existing VFP forms! This is truly the secret sauce for extending existing VFP applications.

Let me explain the title to this post.  Truth be told, Visual FoxPro development will continue beyond Microsoft's current product timelines, but it will  not be called Visual FoxPro. Henceforth it will be known as LINQ, ADO.NET and SQL Server.  Members of the Visual FoxPro development team have been working on Visual Studio and SQL Server technologies for years.  Today's announcement means that they will be doing that full time. 

Alan Griver gave a presentation on LINQ at the East Tennessee .NET Users Group in January, and he made the best association I've heard for the connection between VFP and LINQ.  Alan said, "In Visual FoxPro, all data is converted to a common format called a cursor, and all data operations are made against the cursor, then updates are sent to their data source.  With LINQ, we replace the cursor with collections of objects."  That statement helped seal my enthusiasm for LINQ and the future of data access in Visual Studio and .NET languages.

I must emphasize that there is nothing to be afraid of.  There is no bad news today for VFP developers.  There is no conspiracy against Visual FoxPro.  This is a natural and logical business decision by Microsoft.  All the resources you need to continue developing data-driven software using RAD tools are available today, or coming in the next release of Visual Studio.  Let today's announcement be a reminder to you to download some code samples and read some articles so that you will be prepared for Orcas.

I want to close with a quote from Visual FoxPro MVP Craig Boyd, "If Microsoft is trying to kill VFP, then they're doing a piss-poor job of it." Amen, Craig.

Cheers,

++Alan

 Thursday, February 08, 2007

Speaking at NashDotNet



# 

I'll be speaking at the Nashvile .NET User Group tonight.  The topic is Windows Services, but I'm sure to get into my opinions of developer tools. :-)  If you are in the area, stop by.

++Alan

 Saturday, December 09, 2006

Lambda, It's not a Fraternity



# 

I did not study software engineering, or computer science in school.  When I began writing software for a living, I thought this was a liability.  I had a good long conversation over a bottle of Oban that changed my mind.  My good friend Wade has a BS in Computer Science and a MS in Industrial Engineering.  He also has plenty of bona fides in industry.

I expressed my concern about lack of formal training to Wade, then asked what he had learned in his CS studies.  His reply could not have pleased me more.  He told me that he came up with his own language and compiler implemented in Pascal.  I asked if this experience had directly contributed to his career, and he replied that it had not. 

While I believe credentials are important at the beginning of a career, I am more interested in what a job candidate has done than what they have studied.  I also knew then that despite having a MS in Education, I had learned the majority of what I found to be useful knowledge in that field through my own reading and experience.

That is why, dear reader, I was able to march boldly into a career in which I had no formal training and thrive.  I stopped seeing my lack of credentials as a liability.  I was already producing working software at my job, and I was studying like a fiend at home.  This continues to be my practice, and I have never regretted my lack of academic credentials, until now.

I like to follow the news at Reddit.  It seems there are a bunch of alpha-geeks who hang out there, and as a result there are an abundance of links relating to Lisp, Haskell and other "exotic" programming topics.  I read these articles out of curiosity, but I never found an application for the features that were promoted as world changing.

One of the topics that I have found particularly interesting is functional programming.  I don't fully understand it, but I have some idea of how it differs from the imperative programming that I do every day.  Recently some terminology from functional programming has popped up in my "normal" programming studies. 

Microsoft is currently cooking up an extension of it's ADO.NET data access technologies called LINQ.  This is a very interesting development, and I have been following along without actually trying the technologies yet.  One concept that shows up in functional programing and LINQ is that of Lambda Expressions.

This is where my lack of formal training shows up.  I never studied Lambda Calculus, and Joel Spolsky had me convinced that it was a useless pursuit anyway.  Now I have a keen interest in the application of Lambdas in my work.  I will attempt to share what I have gathered on the topic, as it pertains to practical software.  Any correction or clarification of this discussion is welcome and encouraged.

My current take is that Lambdas are a way of expressing value without actually storing the value in memory.  This preserves all meta-data about how the value was derived and how the values used to calculate our current value were derived.

At any point then, we can evaluate the whole thing and output a value, but we don't store the value explicitly.  The first thing I can relate this to is function pointers in C.  A pointer can point to the address of a value in memory, or the address of a function.  That's a rough association, but I need to start somewhere.

Another parallel I see is to dynamic evaluation at runtime.  I program daily in Visual FoxPro, and when I work in C# or VB I pine for the dynami