Saturday, November 01, 2008

Recent Adventures in Podcasting

I managed to continue my quest for over-exposure at two events in the month of October.  If you have any interest in my take on software development, conferences and developer community, then check these out.

First, I sat down with Andrew McNeil of the FoxShow over breakfast in Mesa, AZ. Andrew and I were both speaking at the Southwest Fox Conference for Visual FoxPro developers. I thought the conversation came out well:  FoxShow58SWFox.mp3

Next, I sat down with Chris Williams for his Nine Questions series. Chris sent me a list of questions to answer back in June, and I never responded. While he had the video camera in hand at PDC, we sat down to do the video interview. Again, I'm happy with the outcome:



 Friday, October 19, 2007

Southwest Fox Day 1

I flew into Phoenix Thursday, and lost most of the day to travel + jet lag.  I did get to hang out with Craig Boyd and Bo Durban briefly.  Bo and I made a trip to the airport to pick up Dave Bernard.  Bo rented a sweet Shelby Mustang convertible for the week, so it was a fun trip.

Friday morning I was up at 5:00 am.  Traveling west makes me feel super human. :-D  I wanted to be certain that I had everything ready for my afternoon pre-conference session on test-driven development (TDD).  My concern was that I might not have enough material to fill four hours.  As it turned out, I could have filled an extra hour or two! 

Apparently my preparation payed off for attendees.  I got lots of positive feedback on the session.  Steve Bodnar has a very flattering review here.  I really enjoyed making the audience tell me what to type.  I let them set the requirements, then reason about how best to tackle the problem using TDD.  I had blast, and I'll probably continue to do talks on agile methodologies. 

At the speakers meeting, I was surprised to hear that I would be giving a keynote address with Craig Boyd!  I've never shied away from an opportunity to get in front of a crowd, but I thought that I might hear of this before the day of the event!  Craig and I spent the next hour getting our ideas together, and talking ourselves into a frenzy.  We are both totally stoked about the project we are working on.

Our project is called VFP Studio.  We are using the Visual Studio 2008 Isolated Shell to build an IDE for building Visual FoxPro projects inside Visual Studio.  We have plans to include reg-free COM for enabling click-once deployment of Visual FoxPro applications.  We are working on a VFP project type, so that we can add a new or existing VFP project to a Visual Studio solution.  We keep coming up with exciting possibilities for this project, and we will be announcing more soon.

While the other two keynote demos were definitely more mature than ours, I'm very excited that we were able to take this opportunity to announce what we are working on. By announcing the project last night, we were able to reach the most people who would use VFP Studio in one room.  Ken Levy, former Visual FoxPro PM and current community program manager on the Visual Studio Ecosystem team, was present at the keynote, and helped clarify what Craig and I were doing for curious attendees during the reception.  I can't wait to see what we have to share at next year's Southwest Fox conference.

My conference photo album is here.


 Tuesday, October 02, 2007

Loose Ends

I'm picking up some loose ends this week.  I've had a couple of projects "in process", read totally ignored, for a few months.  This week I'm getting back in the groove and making progress on both of them.

First, thanks to some insistent encouragement, read nagging, from Craig Boyd, I have the VFP Build Target code up on CodePlex.  The initial commit should be seen as a design document.  I didn't write the initial implementation, Paul Witt did.  Paul is our configuration manager at DPRA and as such, he's responsible for the builds. 

After a conversation and an exchange of links to documentation, Paul built a working implementation of the VFP Build target to be called from Team Build.  Paul discovered that the build would hang if there was a problem with the build, because VFP was showing a modal dialog.  Paul set up a timer to call a separate program to kill the, now hung, VFP process.

I took Paul's code and removed the parts specific to our build process, and attempted to simplify the structure.  I also converted the build task class to C#.  Now that it's posted, I'll create some unit tests and documentation, so others can begin playing with it. 

My other loose end is my foray into the wilds of VSX.  I began an earnest investigation into the new Visual Studio extensibility features, but I got sidetracked by two exciting opportunities.  Neither opportunity played out, but I learned some things from the process.

Late last week, CoDe Magazine published VSX CoDe Focus magazine.  You should check it out.  In two weeks I'll be doing a talk on VSX at DevLink, so I will be spending my free time making sure I'm up to speed on all the latest updates.

If you are interested in influencing the future of Visual Studio Extensibility, be sure to take the survey.


 Thursday, September 20, 2007

Fox Forward Shows Some Love

Kevin posted the news today that Dave Bernard won best presenter at Fox Forward 2007.  I didn't make it in time for his opening session on Instrumenting Your VFP Application, unfortunately, but I did see the first and last halves (in reverse order) of his Does Your Application Understand You? session.  Dave is doing some very exciting things with technology, and he has an easy going style when presenting.  Well done!

My Red, Green, Refactor: Test-Driven Development with FoxUnit session won the best use of technology award.  I was shocked, given the innovative approaches I saw during the conference.  It is quite an honor to be recognized by my peers in this way.  Thank you to everyone who voted, and everyone who attended for making this year's Fox Forward the best yet.

On the first evening of the conference Stephen Bodnar asked me what the difference was between my Red, Green, Refactor session at Fox Forward and my Test-Driven Development pre-conference session at SouthWest Fox next month.  My flip answer to his question is:  about two hours.  :-)  The longer answer is that I will be able to help attendees in Phoenix overcome some of the more challenging hurdles to starting TDD. 

At Fox Forward, I mentioned an approach to test driving the UI, but I didn't have time to demonstrate it.  I talked about refactoring legacy code to support unit tests, but again, no time for a demo.  In Alpharetta, I didn't even touch on the subject of mock objects.  In short, there's lots more to unpack in TDD than I can address in a standard 75 minute session. 

In fact, my repeat presentation was the last session of the day on Saturday, and the entire room kept their seats for ten extra minutes while I gave an extended demo of TDD with FoxUnit.  Kevin came in to collect the projector and everyone was still listening to me talk!  If you are signed up for the pre-con in Phoenix, or if you are considering it, I promise to give you your money's worth.



 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.



 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 dynamic evaluation available in VFP.  While most loosely typed, or duck typed, languages can perform dynamic, runtime evaluation, VFP has true macros, and I miss them when they are gone.  Could it be that LINQ will allow me to interpret, compile and evaluate expressions (code) on the fly in .NET?

It is not only my study of LINQ that has piqued my interest in lambdas.  I have lately been pondering a problem in my free time.  I do this even though no one has assigned me a task.  When I find an interesting problem, I wonder how I would solve it.  I suspect most software developers do the same. The problem is this: How would I implement a long running (hours or days) process so that changing inputs and/or constraints do not require that I re-run the entire process to get the new results? 

My first reaction is to store all interim calculations in a data cube, so that I can recover as much of the previous work as possible before I have to recalculate.  This is a reasonable approach to a point, but I cannot calculate all possible outputs in my original run, so I will only be able to go back to the point that outputs begin to change, and re-run the process from there, and in some cases this would mean running it from the beginning.

It seems that in this scenario the business rules, or constraints, matter as much as the explicit inputs. In fact, the business rules are inputs to the expression building engine, while the data inputs are passed to the built expressions.

I conceive of this like a query execution path in a SQL engine.  Once the system has determined how best to evaluate the query, much of the work is done.  You can then change the inputs to the query and the server will evaluate it the same way it did before.  My hypothetical, long running, complex process benefits from a similar approach.  Determining how best to evaluate the inputs is half the work, and this is defined by the constraints in the same manner as the table schemas and indexes determine how a SQL engine will evaluate a query.

It now appears imperative when executing a long running process with high CPU requirements that we record how we solved the problem as well as what the solution was.  In this way we could run the process from the start with new inputs and simply re-evaluate the pre-built expressions.  We could also change our constraints and only rebuild the expressions affected by the changes. 

This approach also allows us to solve the problem iteratively.  By setting thresholds on how detailed we want our expressions to be, we could form estimates, and then run the process again building ever more detailed expression trees, asymptotically approaching a precise answer.

This appears to be what functional programming is built on.  This lack of "side effects" also has other practical advantages such as thread safety and high parallelizability.  At least one functional programming advocate is willing to argue that these advantages qualify functional programming as a silver bullet.

 In this context, a silver bullet means that the technology provides an order of magnitude improvement in productivity and or performance.  This is a bold claim, but some of the arguments are persuasive, if not for a full order of magnitude, then for significant improvements. My favorite argument from the above linked essay applies directly to my hypothetical long running process:

The order in which statements are executed, and hence the execution trace of the program, is completely irrelevant. Thus execution order is revealed as a major source of accidental complexity which Brooks mistook for essential complexity, but which is eliminated in pure functional programs.

 If execution order is truly inconsequential, then we can modify our constraints and inputs constantly in order to arrive at the optimal result.  It remains to be seen if I can design a solution of this type in .NET with the new LINQ extensions, or whether I'll need to dive into Lisp, Scheme, Haskell, Erlang et. al.  One thing that is certain, is that I'll find out, and I'll share my understanding here.  Now, if you'll excuse me, I have some reading to do.


Everybody's Got One

I like to write code.  It isn't the best way to solve every problem, but when it is the correct solution, I love to lose myself in code.  Unfortunately, I seldom start from a clean slate.  Most tasks involve correcting, extending or interacting with "other people's code."

This is why the post My Personal Pet Peeves I See in Other People’s Code by Ramon Leon was so much fun to read.  I know where he's coming from, and I enjoyed his ho holds barred ranting.  Sometimes you just gotta' let it out.

Still, I found myself arguing with Ramon in my head, "Hey, that's the way I write code.  There ain't nothin' wrong with that!"  Except, maybe, just maybe, there is, unless there isn't.  My point is that while we all have opinions, it is a slippery slope to create too may concrete rules regarding style.  Like the pirate's code, "they're more like guidelines."

So, what follows is my rant about Ramon's rant.  If I don't argue with one of his points, then the reader should assume that I share it.  Let's get started:

Ignorant Prefixing:  I agree, except in cases where there is already a large code base using this style of naming.  Then the rule for consistent style takes precedence.

Single Exit Points:  I largely disagree.  If a method is small enough to fit on a single screen, it is simple enough to have a single exit point.  My one exception is to put something like the following at the top of a method:

If (noChanceInHell) return false

1000 Line Methods:  I like the rule of not having to scroll when reading a method, although in practice, I break the rule as often as I comply.  I wholly agree that the method name should be the only documentation needed about the purpose of a properly atomic method.  In fact, more developers need to read chapter seven of Steve McConnell's excellent Code Complete to learn how to properly name routines.

Declaring Variables at the Top of a Method:  I agree with the dictum to declare variables at the minimum scope, but when the minimum scope is the method,  as opposed to a loop, then I like to see them declared, and initialized, if reasonable, at the top.

Error Code and Switch Statements:  I like to return a bool from my methods.  Many routines are just initializing some environment for the Main Event®.  In such cases I will use the following structure:

LOCAL returnVal as Boolean

returnVal = .F.


  CASE NOT DoThis()

  CASE NOT DoThat()

  CASE NOT DoTheOther()


    returnVal = .T.


RETURN m.returnVal

The reason I can do this, is that I program primarily in Visual FoxPro.  You just can't do this in VB and C# switch statements.  I am bitterly reminded of this every time I work in either of those languages.

I admit to ignorance of the Samurai Principle, and I can definitely see it's application, but there are many cases where I would rather check for a boolean result than do yet another try catch (YATC).

Overall, Mr. Leon's rant is well informed, entertaining, and educational.  Highly recommended.


 Wednesday, September 20, 2006

FoxForward Conclusion

I skipped morning sessions on Saturday so that I could prepare some changes for my demo that my coworkers recommended.  I did make it to lunch, however.  <S>

In the afternoon, I saw David Stevenson's sessions on the CursorAdaptor and XMLAdaptor respectively.  David showed some interesting functionality he had implemented in his CursorAdaptor subclasses.  I'll need to wade through the code to fully absorb what he showed.

David's session on the XMLAdapter started as I would have expected, comparing XMLAdapter functionality with CursorToXML() and XMLToCursor().  Things got more interesting when he began working with the XMLTables and XMLFields collections directly.  By the end, he was loading schema-less XML with embedded elements and showing us how to use Xpath statements to map this format to related cursors.  This tip alone is worth the price of admission to this conference for any developer who has spent his time trying to solve the conundrum of emended elements without foreign keys.

Saturday evening at the Ale House I tried a delicious local brew called a Sweetwater420.  I also had a great time talking with other attendees.  I especially enjoyed meeting Ed Leafe.  Ed is the author of the Business Object base class in CodeBook.  I have spent many hours studying that code and learning from it.  It is satisfying to have the opportunity to thank someone in person for helping me along my way.

While we were talking at dinner, I was reminded that Ed is the source of one of my standard practices.  It was in Ed's code that I first saw the GarbageCollect() method which NULLs out any properties with values of VarType = "O".  These days I use Bindevent() to bind destroy to my CollectGarbage() (renamed to fit the coding standard :-) ) method in my base classes.  orphaned object references are one of the most frustrating problems to debug in FoxPro, and this simple fix removes them forever.

Next I moved to Craig Boyd's booth, because I hadn't had the opportunity to do more than introduce myself to him.  Craig is a passionate guy, and we got into a discussion of the FUD (fear uncertainty and doubt) being spread by some parties regarding Visual FoxPro and .NET.  I love these type of discussion.

Sunday morning was showtime for me.  I spent the morning testing my demos one more time.  Saturday night, I discovered a bug involving spaces in a file path, so I felt it was prudent to test everything one more time.  Although my session was sparsely attended, the audience seemed truly interested, and actively engaged.  I enjoyed this session, even though I was the presenter.

After my session was lunch, where I won a VFP hat!  I spent some time on the back patio listening to Ed Leafe and John Koziol swap stories about conferences past, and ask each other "where are they now" about members of the VFP developer community.  This was a nice bonus.

The last two sessions, for me at least, where Craig Boyd's discussion of cryptography, and Bo Durban's discussion of the new GDI+ classes from the VFPx project.  These were both awesome sessions.  I already use Craig's vfpencryption.fll in my work, and he showed me many new uses for it.

I've been working with GDI+ lately using both the flat API, and the VFP foundation class.  Bo's session showed me that I need to stop wasting my time and focus on the VFPx class library.  There is more in there than I can possibly relay.  Bo had a nice interface to launch samples and then show the code.  When I got home, I downloaded that library and found that the form Bo used is included in the .zip file.  In fact, there is a .APP file you can run and see most of what I saw without driving to Atlanta.

The biggest surprise to me was that the library included a class for accessing resources in uxtheme.dll.  I have seen several attempts by VFP developers to produce custom controls that reproduce the visual style of Windows XP.  The problem with every implementation I had seen before, was that they mimicked the default blue theme.  If the user ran a different theme, the Visual FoxPro control would not display the new visual style.

By documenting the API to uxtheme.dll for VFP developers, the VFPx developers have made this issue a thing of the past.  I have already begun implementing a Theme Explorer UI in the style of the VB app that pointed the way for the VFPx team.

Speaking of VFPx, an audience member offered to help work on one of my proposed Team Foundation Server tools after my session.  I told him I would speak to Craig about putting it in VFPx.  Craig told me where to find the application form.  I've since submitted my application, and I hope to be contributing to VFPx soon.

In summary, I think Kevin Culley did an outstanding job of putting this conference together.  I predict that in the coming years there will only be two VFP conferences worth attending.  Southwest Fox in the West, and Fox Forward in the East.  I know I'll be back next year.


 Saturday, September 16, 2006

Fox Forward Day 1

Fox Forward 2006 - Alpharetta, GA USA - September 15th-17th

A coworker and I drove down to Alpharetta, GA Friday afternoon.  We arrived only 20 minutes late for the reception, despite the best attempts of Atlanta traffic to make us later. :-)

The hotel is comfortable, with large rooms; no complaints.  At registration, I met Kevin Cully who organized the event.  He reported that he had 55 attendees registered.   That was good news to me.  For a first time conference on a niche topic such as Visual FoxPro has become, that is a respectable level of interest.

After my first beer... er, I mean after the reception, I attended Bo Durban's session on Creating custom report controls and customizing the report designer.  This was an eye-opening session for me.  I have not touched a VFP report since VFP 9 was released, so I hadn't seen the COOL new features available from the report listener class.

Bo showed us how to hook into the report rendering to draw directly on the report with GDI+.  Next, he showed us how to use GDI+ to completely replace a shape on a form with whatever we want.  Bo demoed replacing with Rich Text, and an ActiveX control.  I told Bo he got me excited about reporting, which I never expected.

The keynote was given by Craig Boyd.  I've read Craig's blog for over a year, and knew to expect an enthusiastic advocate for VFP development.  Craig delivered in spades!  VFP World Domination was a 75 minute cheerleading session about the power and potential of the Fox.  I left the session very fired up about what is possible with this tool. 

Craig showed off several of the tools and examples he has created.  He is a terrific resource to our community.  One of his examples gave me a possible solution to a tool I have been contemplating.

Following Craig's keynote, several of us went to Taco Macs for "refreshments".  I am thrilled about this conference, and very honored to be allowed to speak on Sunday morning.


 Monday, August 14, 2006

Speaking at AFDUG

I'll be speaking tomorrow, August 15, 2006, at the Asheville FoxPro Developer User Group on integration of Team Foundation Server and the Visual FoxPro IDE.

Meeting is at 6:00 PM at PowerChurch Software offices.


 Monday, July 03, 2006

ORM and the Fox (Part 1)

I have been moving quickly between tasks since my return from Boston.  I'm finally taking some time off for the Independence Day holiday.  Floating in the pool, I keep finding the subject of Ted Neward's essay coming to mind.  It appears I still have something I want to say about ORM.  In this series of  posts, I hope to explain why Visual FoxPro has more mojo for resolving Object Relational Mapping issues than any other technology, of which I am aware.

At the speaker's dinner for the Atlanta Code Camp, I discussed LINQ with Charlie Arehart, and Wally.  I brought up the doomed Object Spaces project, and quoted Ted Neward's pithy line that "Object relational mapping is the Vietnam of computer science."  It is a good line.  It is also true, as much as a pithy metaphor can be true.

Now that Ted has expanded his metaphor, we can see the limitations of metaphor in general.  I recommend Jeff Atwood's analysis of Ted's essay.  I agree with everything Jeff has written there.  Primarily, I agree that Ted tried too hard to stretch his Vietnam analogy which distracted from his primary, quite sound, thesis that "there is no good solution to the object/relational mapping problem."  Full stop.

Despite any over-reaching in support of his Vietnam analogy,  I must state clearly that Ted Neward is possibly the most qualified person in the industry to make the criticisms he does of ORM.  Here's a short bio with his credentials.  Suffice it to say that he is not arguing from a position of ignorance.  Ted works with many technologies, and has seen the limitations of ORM manifested in different languages and platforms.

To continue with my love letter to Ted, he acknowledged something that few people in the industry are even aware of.  Visual FoxPro eases the dissonance between objects and relational data better than any other technology on the planet.  I first came to this realization upon reading this post by Joel Spolsky in 2004.  Joel identified the impedance mismatch between objects and relational data as a shortcoming in all modern programming languages.  Joel didn't bother listing VFP among "modern high-level programming languages."

I'm not going to bitch and moan about the low profile of VFP.  I know what it can do, and it's been earning me a decent living for years.  I just can't believe other languages have not done a better job of "borrowing" the best of what VFP does.  I'm damn tired of all the LISP articles on Reddit telling me how I'm missing out because my language of choice doesn't have feature foo which LISP has had since the '60's.  I also take issue with Paul Graham's essay about the RAD nature of LISP for startup companies.  Any experienced VFP developer could easily make the same arguments in favor of the Fox.

When I first saw Ted's mojo comment, I felt vindicated.  I made a quick post, and forwarded the link to "the Craigs".  I secretly hoped they would write this argument for me.  Fortunately, I have to sort this one out for myself.  I am currently developing an object interface to encapsulate a VFP cursor.  This is totally unnecessary in Visual FoxPro, but I need to leverage my object model from .NET, so I must encapsulate all the tasty VFP goodness behind a COM interface.  This is the ultimate test of VFP's ORM mojo in my experience to date. 

It is my contention that the "secret sauce" to VFP's ORM mojo is the cursor.  A VFP cursor is a data structure like no other.  Most non-VFP developers associate VFP with the DBF storage format.  People seem to assume that it is "just" a database.  Visual FoxPro does have a very powerful in-process data engine which includes a wickedly fast ISAM storage format, but it can use data from any source as a cursor with that same data engine.  This is where we find the secret sauce. 

Other languages need to map data from relational sources to primitive types such as arrays or dictionaries (collections).  The ADO recordset is actually an object oriented implementation of VFP's cursor engine.  The ADO.NET dataset takes this further to include relations in the definition.  Strongly typed datasets are a particularly easy way to handle data in managed code.  The advantage that VFP has is that it handles data in cursors natively.  That is what it is made to do.  Handling data in a columnar format, and setting relations between these table-like data structures is the core of the VFP mission.

VFP developers use SQL commands as first class citizens of the language.  They are handled by the runtime in the same manner as conditional and looping statements such as IF and FOR.  There is no conceptual difference to a VFP developer between addressing a local variable, a property on an object, or a field in a cursor. 

Let's pause for a moment and refine our terms.  Here is what Whil Hentzen has to say about VFP cursors in his excellent (though out of print) introduction to VFP development Fundamentals: Building Visual Studio Applications on a Visual FoxPro 6.0 Foundation:

We’ve been using the term "result set" to refer to the collection of records created by the execution of a SELECT command. While Visual FoxPro is "record oriented" in that we can move from record to record as we desire, other languages that use SQL do not have this capability and can only address a block of records as a single entity. As a result, all SQL operations are oriented toward manipulating this "set of records." They refer to this block of records as a "cursor," which stands for CURrent Set Of Records. A cursor is a table-like structure held in memory; it overflows to disk as memory is used up. In some cases, such as queries that essentially just filter an existing table (in other words, no calculations or joins), Visual FoxPro opens a second copy of the table in another work area and then applies the filtering condition to present a different view of the table as the query requests it.

Cursors have two advantages. First, they are fast to set up, partly because of the possible filtering of an existing table, and also because of their initial creation in RAM. Second, maintenance is greatly reduced, because when a cursor is closed, any files on disk created due to RAM overflow are automatically deleted.

I hope it is clear from the above that any data that can be understood conceptually as a row/column data source can be handled very elegantly by VFP.  The key point to recognize is that the data runtime and the language runtime are one.  They even share a common garbage collection mechanism, which you can read about here.  VFP developers are able to enumerate, search, sort or perform set based operations against one or more cursors without making a context shift from the surrounding procedural code.

Cursors are not perfect.  They are not objects, and can therefore not be passed around by reference.  There are two workarounds for this conundrum: ADO recordsets, and XML.  I use XML exclusively.  I no longer consider ADO recordsets to be a maintainable solution.  While the shortcomings of XML are well documented, the flexibility is irresistible.  Furthermore, the VFP XmlAdapter class makes it a snap to translate between cursors and XML, and even take and apply diffgrams.  Therefore, I use XML whenever I am passing data across object/process boundaries, and I convert the XML to VFP cursors within my object interfaces. 

In the next installment on this subject, I will address the object component of Object Relational Mapping.  For now, I hope that I have clarified that Visual FoxPro is not "just" a database.  From my perspective, it is primarily a runtime library for the Visual FoxPro language which seamlessly blends typical imperative programming constructs with relational data handling.