J# Is Put Out to Pasture, and No One Notices

After last week’s announcement of the end of the line for Visual FoxPro, I found it entertaining to read that J# suffered a similar fate, two months ago!  J# is Microsoft’s implementation of Java syntax on the Common Language Runtime.  It was never promoted as a primary .NET language.  It was intentionally a clone of Java so that Java developers could move painlessly onto the .NET runtime.

Cheers,

++Alan

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

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.

++Alan

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.

DO CASE

  CASE NOT DoThis()

  CASE NOT DoThat()

  CASE NOT DoTheOther()

  OTHERWISE

    returnVal = .T.

ENDCASE

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.

++Alan

UML Sucks (Really!)

I recently received a comment on my blog about a comment I made on another blog.  Ain’t the Internet great?

Here’s the response I sent:

Hello Nick,

Thanks for alerting me to the need for a contact link on my blog. 🙂

While I don’t use UML, and neither do any of my coworkers, I have mixed feelings about the need for it.  It seems perfectly reasonable that we should agree as an industry on a common set of symbols to represent OOP concepts, but UML has a typical “design by committee” feel. 

In his comments to the “5 Books” post, Jonathan Allen brought up something that I was aware of,  but never expressed precisely.  He said that the object model is the most malleable part of the design.  This is absolutely true.  This is actually the conceptual basis for iterative, agile practices.  The most critical aspect of the initial design, in my experience, is the interface between the UI and the object model.

While changing the UI is frustrating for users, it is not a technical challenge.  Refactoring the middle tier requires discipline to avoid introducing errors, but should not affect other parts of the system.  It is a well designed interface contract that makes for an extensible system.  This is why SOA with its service contracts is appealing.

Unfortunately, UML doesn’t address interfaces (or at least poorly addresses them).  It seems obsessed with minutiae in a parody of academic distraction.  The only time I see UML in my daily development is in technical books and articles, and even then a Visio diagram would usually work better.

With regards to your objective of developing “ways to improve UML interaction to be more practical,” I encourage you to ignore UML initially and define your problem clearly.  It seems to me that the problem does not involve UML, but the need for communication between developers, sometimes from different cultures, and on separate continents.  You are most likely interested in the visual display of information as it pertains to object oriented analysis.

If I am correct in my assumptions, then I do have some resources to recommend.  As I mentioned in the blog comment that you referenced, Peopleware is essential reading for understanding the human interactions surrounding software development.  For understanding objects, and by understanding I mean grok in fullness, I have found nothing better than The Object Primer.  Finally, when it comes to the visual representation of information, there is only one person you need to study, and that person is Edward Tufte.  Tufte makes mincemeat of systems such as UML.

If you are looking for a software solution to capture design ideas, then you should be familiar with mindmapping applications such as Mindjet or FreeMind.  I also have begun using Microsoft OneNote and have found it useful.

Cheers,

++Alan

Please Don’t Name a File Setup.exe

After doing all the downloading from my previous post I have one big request from the software development community.  Please don’t name your install file Setup.exe.  Try instead Setup<Application Name><Version Number>.exe or some varient of that.

I just downloaded the Windows SDK and the file was named setup.exe.  I download all files to the same directory, and decide what to do with them from there.  I don’t want to have to rename your file in order to prevent it from overwriting another file with the same name.

While I’m on this little rant, I’m tired of iTunes always downloading with the name iTunesSetup.exe with no version number.  It seems rude to me for Apple to assume users want to overwrite the previous version they downloaded, and thus lose the ability to roll back to a previous version if they don’t like the upgraded “features.”

Thanks, and have a nice day.

++Alan