Thursday, March 13, 2008
General Purpose Languages, DSLs, and (Visual) FoxPro
A lot of people ask me why they should pick .NET over VFP or vice versa. "Why should I use .NET when VFP can do everything I need?", some people say. And the answer is: If VFP does everything you need it to do, then stick with VFP, for crying out loud!
So when exactly does VFP everything you need it to do? Well, here is one way to answer that question:
In the world of software development, there are different types of programming languages. Some are general purpose languages (GPLs) and other are domain specific languages (DSLs). Both types have been around for a long time, but only relatively recently have we started to think about it in these terms. Here's the definition for both types:
- General Purpose Languages
GPLs are languages that have been created with very broad goals. GPLs are usually relatively close to the OS or the hardware in the sense that they are designed to make the CPU do just about anything a computer can do. Examples of GPLs are C++, C#, Visual Basic.NET,...
- Domain Specific Languages
DSLs are created with a much more specific goal in mind. A DSL could be used to manipulate data for instance. Or perhaps they are geared towards creating high performance 3D graphics. Or maybe they are even specific to a point where they solve a very specific business problem, such as workflow, or optimizing power plants. DSLs can be written languages, or they can be graphical languages driven by diagrams. Examples of DSLs are T-SQL, (Windows) Workflow Foundation, HLSL (High Level Shader Language), the .NET Windows Forms Designer, and many very specific things used in specific businesses.
So an interesting question is this: Is VFP a GPL or a DSL?
I would argue that VFP is a DSL. A very large one, admittedly, but still, VFP was created with a very specific goal in mind: Creating data driven business applications on the Windows platform. To achieve this goal, one could argue that VFP is a combination of multiple DSLs: The VFP DML (Data Manipulation Language) to handle data. Then there is the UI definition part driven by SCXes and VCXes. Then there is the report writer. That sort of stuff.
Of course VFP has been extended over time. VFP works on the web mainly by means of COM interop or third party products such as Web Connection. VFP can also import Win32 API features through a special layer. We can talk to SQL Server and then even apply the VFP DML on the retrieved result set. However, all these things are add-ons to the original idea. Everything VFP does natively was specifically created for VFP. When you pop a button on a form, the button is created by VFP. VFP is not driving a standard Windows button, instead, it creates its own.
VFP also can't easily take advantage of general purpose APIs. Just because Windows offers a Direct 3D API doesn't mean that API is easily usable from VFP. Sure, it can probably be done if you tried really hard, but it isn't what VFP was designed for. Just because WCF makes communication in complex systems really easy doesn't mean VFP can easily take advantage of all the compelling WCF features. Just because Microsoft now provides a great platform to create code that can have (security) rules applied to the code's execution, doesn't mean VFP can take advantage of that, and so forth. I once created a monopoly-like graphical game with FoxPro 2.6, and I managed to pull it off, but it sure wasn't what VFP was really good at.
So the question simply is: Is the problem you are trying to solve with your application a problem that matches the domain VFP was created for? VFP was created to build monolithic business application with data that was either local or on a local network. And VFP is really, really good at that. Everything beyond that gets more difficult. You can still pull off a COM based multi-tier system or even a web app, but it sure isn't as easy as it was to build a DBF-based Windows desktop application.
If on the other hand, your problem is slightly different, then VFP is probably not such a good choice. Many modern applications have the need to scale very well, work in a distributed fashion, interop and integrate with various services, run secure, run in a fashion that can be managed by administrators, use modern UIs as provided by WPF, Silverlight, or ASP.NET (Ajax), have to be easily deployable (ClickOnce), run on mobile devices, and generally, do things we didn't worry about 5 or 10 years ago. The visual power and visualization requirements for modern applications have skyrocketed. Amounts of data have grown huge. Applications need to be available online and offline. And so forth, and so forth.
So that is one way to look at the big picture. There are other questions you can ask yourself too. Market pressure for instance. Is your competitor killing you because you are still in a COM or VFP world and they are not? This is a scenario we see every day. But that is a completely different story altogether... :-).
Posted @ 2:14 PM by Egger, Markus (firstname.lastname@example.org) -