Navigation


VFPConversion Blog

This blog is dedicate to the adoption of technologies such as Microsoft .NET or SQL Server in addition to Visual FoxPro. Expect posts on this blog to be fairly technical, as this blog is geared towards developers, testers, and technical decision makers.

Content Area Footer

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 (markus@code-magazine.com) -
Comments (1)




Comments:

RE: General Purpose Languages, DSLs, and (Visual) FoxPro
Tuesday, April 15, 2008 7:26 PM by RVBoy

What you say seems very true for end-to-end scenarios where the developer and customer are creating the whole enchilada of database, middle tier and front-end. However, market leaders are increasingly promoting delivery of many previously lucrative development scenarios using an ASP model in which customer choice may be limited to the front end. Providers can use pretty much whatever they like behind the curtain while offering all sorts of commodity front-ends or an API to satisfy any number of customers. That's what we do today. We offer web/VFP/winforms and even WPF frontends to consume services produced by a server app written in an unstated product in which customers have absolutely no interest. In this environment, people with solid niche functionality written using OO and tiers may be able to retain existing middleware indefinitely, just as banks did with their ancient Cobol for decades.


 

 

 

 

 

 

 

Syndication RSS 2.0 RSS 2.0

All My Blogs:
My personal blogs:
Dev and Publishing Dev and Publishing
Travel and Internat. Living Travel and Internat. Living
Other blogs I contribute to:
Milos Blog (US) Milos Blog (US)
VFPConv. Dev Blog (US) VFPConv. Dev Blog (US)
VFPConv. Dev Blog (DE) VFPConv. Dev Blog (DE)

 

Blog Archives
All Blog Posts

2009
    February (1)
2008
    November (1)
    October (2)
    April (1)
    March (1)
2007
    August (1)
    July (1)
    June (2)
    March (1)
    January (1)
2006
    December (1)
    November (2)
    October (1)
    September (1)
    August (1)
    April (3)
    March (2)
    February (1)
    January (1)
2005
    December (2)
    November (3)
    October (2)
    September (7)
    August (3)
    July (4)
    June (12)

 

 

 

This Blog is powered by MilosTM Collaboration Components.