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

Sunday, November 09, 2008
Visual FoxPro: A Dynamic Language?

Over the recent months (or even years), a development paradigm has gained importance that has been around for a while, but hasn't been nearly as popular as it is now: Dynamic Languages.

What exactly is a dynamic language? DLs are languages that are not staticly typed. In most static languages, one creates an instance of an object and at that point, one knows the type of an object and what methods and properties it has. For instance, in C#, we could write this to create an instance of a form:

Form form = new Form();
form.Show();

The fact that form has a Show() method is clear based on the definition of the "form" variable to be of type (class) "Form" (Form form). In fact, the compiler can look up the definition of the "Form" class and verify that it indeed has a Show() method that takes no parameters. If so, the code compiles and runs fine. If such a method isn't found, the compiler refuses to compile the code. This is a great too to improve code and runtime quality of your application.

Dynamic languages approach the process a bit different. They simply allow calling methods on an instantiated object during runtime, with no check members during compile time. Conceptually, we could write this in pseudo-code like so:

form = new Form();
form.ShowNow(); // May or may not work during runtime
 

In some ways, this is actually similar to how Visual FoxPro works, where the same code could be written like so:

LOCAL oForm = CreateObject("Form")
oForm.Show()

No compile-time check is performed in VFP to see whether the Show() method exists or not. It simply invokes the method dynamically at runtime. If it exists: We are all smiles. Otherwise: Crash and burn!

So does that mean VFP is a dynamic language? Well, no, not really (or only partially). The question we need to ask ourselves is "why do dynamic languages make sense in some scenarios?". And the answer to that lies in the ability to add "stuff" dynamically. There certainly is no benefit in not knowing whether a method call will work or not when there is no way to add a method dynamically. Which could happen in the above scenario only if we instantiated a different object. We know Form objects in VFP have certain methods and there is no upside in the compiler not being able to check that, unless we have the ability to really add new things dynamically. In a true dynamic language, we should be able to do something like this (pseudo code again):

form = new Form(); // Has no ShowNow() method!!!
form.ShowNow();    // Crash and burn!
form.ShowNow = function {
                   this.Visible = true;
               }; // Now we have a ShowNow method!
form.ShowNow();   // Works

As you can see, this code doesn't really look like VFP and there is no support in VFP for things like function pointers, delegates, anonymous methods, or lambda expressions (these are all techniques that could be used to create something similar to the above example). VFP does have the ability to add properties dynamically and such, but it is a awkward approach and I have never seen an app that makes large scale use of it, or even bases its entire architecture on it, as would be the case in dynamic languages such as JavaScript, Ruby, or Python. (If you have an example where this is the case, I'd be interested to hear about it).

So is VFP a dynamic language then? Well, it is to a certain extent (examples include dynamic member invocation or eval and macro abilities), but in a lot of ways, VFP takes a static approach without static typing, rather than a true dynamic approach. Some of the basics are dynamic, but the VFP paradigm isn't and VFP lacks some core concepts of dynamic languages such as object alteration during runtime (changing the inheritance tree for instance, or adding lambda expressions).

In .NET, languages such as VB and C# fulfill some dynamic criteria (especially VB gets close in the technology it provides, although not necessarily in how it is used in the wild). C# 4.0 will offer explicit support for dynamic concepts that can co-exist perfectly with the static concepts C# is known for (this is something that gets me very excited). Also, IronPython and IronRuby, two new .NET languages from Microsoft are specifically designed to be dynamic languages only.  

Posted @ 3:56 PM by Egger, Markus (markus@code-magazine.com) -
Comments (14)




Comments:

RE: Visual FoxPro: A Dynamic Language?
Sunday, November 09, 2008 4:54 PM by Alan Stevens - alanstevens@gmail.com

Markus, While I agree with your thesis that VFP is not a totally dynamic language like javascript, Ruby and Python, most VFP developers still rely heavily on dynamic features of the language such as runtime evaluation/invocation and duck-typing. Also, the VFP Command Window is the best REPL I've ever seen. :-D ++Alan


RE: Visual FoxPro: A Dynamic Language?
Monday, November 10, 2008 2:22 AM by andreas

Markus, I don't know if I missed something but what is the point of this post? Just to talk generally about dynamic languages or to proof that VFP is not a dynamic language compared to .NET languages? I agree that VFP is not a fully dynamic language and this is a fact. But also a fact is that VFP capabilities for years now, are future capabilities for .NET !!!


RE: Visual FoxPro: A Dynamic Language?
Monday, November 10, 2008 10:20 AM by Markus - megger@eps-software.com

Alan, yes, agree totally. Lots of good dynamic features in VFP. Runtime evaluation is probably the one feature that most people ask me about when moving from VFP to .NET. In fact, one of our VFPConversion tools is an Eval() function that can execute VFP as well as C# and VB expressions in .NET (without the need for the .NET runtime). Anyway: Those are killer features in VFP. Markus


RE: Visual FoxPro: A Dynamic Language?
Monday, November 10, 2008 10:23 AM by Markus - megger@eps-software.com

Andreas, this post was to answer some specific questions I get from VFP people all the time. I am not arguing one way or another. This is only a technical explanation post. Markus


RE: Visual FoxPro: A Dynamic Language?
Thursday, December 04, 2008 9:03 PM by Dennis Kean - dk@data-lite.com

I don't know where this uninformed idea comes from, but VFP is perfectly able to bind an event to an object and make it behave as if the method is in fact attached to the object. Furthermore, you can redesign one or more of these methods compile them on the fly and alter the behavior. And best of all you can allow VFP to crash and burn and recover via discovery of the error, seamlessly bind the .shownow() event, execute it and prevent the crash! VFP dudes know that as ON ERROR! I have written apps where the user can be using the VFP app testing code on itself, (a live system), without crashing on the new code and able to keep going until the end of the day! The macro execution and eval() function, the ability compile on the fly and a host of incredible possibilities exist in FoxPro. You can use FoxPro to create new command words in the language, ON THE FLY! Try that in Python or C#. Python and .NET can kiss VFP's footprints. It is a tragedy that MS has destroyed this astonishingly elegant language. But ignorance of the masses allows MS to sell you a bag of marbles worth a lot less for more money! So, why not. Dennis K


RE: Visual FoxPro: A Dynamic Language?
Friday, December 05, 2008 10:48 AM by Markus - megger@eps-software.com

Denis, you are right in that VFP can do these things, but that is not what I am referring to above. Markus


RE: Visual FoxPro: A Dynamic Language?
Saturday, December 13, 2008 10:50 PM by MG

Markus, After reading through your blogs it is clear you are hyping Visual Studio and .NET. You and the team you are working with are way too intelligent to actually believe some of the rational (which boarders on excuses of why it is ok that .NET in some ways is inferior or still in the catch up stage to VFP) for making the switch and jumping on the Visual Studio .BLOAT bandwagon. I wonder why developers are so accepting of the .NET platform? In your case I narrowed it down to two possible reasons: 1) Money: Clearly you have a financial motive for doing so, given that is what your company is about, selling products and services to ease the pain of migrating to .BLOAT. 2) Boredom: Perhaps you are so in "like" with the challenges of learning new technologies and seeing what it can do, you have lost sight of what is in the best interest of the customer. In other words you want to use the customer's budget as a playground to fullful your own technical fetish. Case and Point; Their is an entire market segment mainly compromised of small to medium size companies who desire an internal custom lan application to assist in managing their business not some over size enterprised based solution which is what really what .BLOAT is gear towards generating. For the majority of these accounts I walk into, VFP or VB would be the perfect solution given it's low cost of ownership and ability to run on the older hardware platforms that the customer currently has. Moveover, Visual Studio's lack of a "true data centric language" equates to a longer development cycle for these data intensive applications. Which is mind blowing to think that FOXPRO for DOS required less code and in some cases was better suited for the basic task of manipulating data then any technology Microsoft currently has available under the VS umbrella including LINQ and developers are fine with it! I just don't get it? I fail to understand how becoming a COG in the Microsoft spin machine is hardly serving the best interest of the development community as a whole? In some instances Visual Studio is not the "right" development tool but given Microsoft's decision to kill off tools such as VB and VFP we are stuck with no alternative. Lack of a competing product is never good for anyone involved. Perhaps the next time you write a blog or spin Visual Studio maybe you should perform an ethics check before guiding people down the Visual Studio path or at a minimum be a bit more frustrated and truthful with the facts that 100's of lines of extra code are needed to implement some of the same functionality that was built in to VFP and missing from Visual Studio along with have to deal with the burden of forcing the customer to hand out thousands of additional dollars in licensing costs and new hardware to put in a .BLOAT application that could have been implemented just fine using VFP.


RE: Visual FoxPro: A Dynamic Language?
Sunday, December 14, 2008 12:21 AM by Markus - megger@eps-software.com

Der MG, whoever you might be. I am not sure how your comments about bloat and data centric languages relate to a post about dynamic languages. In fact, there are many dynamic languages that aren't even based on .NET and I am just using the ones in .NET as an example, since that is what I am familiar with. I am sorry Microsoft has stopped developing VFP further, since this is clearly bothering you a lot since you are venting in this fashion. You are certainly entitled to your own oppinion. There are reasons why the industry (with .NET or otherwise) has moved on beyond data centric monolithic languages. But there are many systems (including VFP as probably one of the best if not THE best of them) that are available and VFP will not stop working. So if you do not want to give .NET a spin (as you clearly seem to have no interest in as indicated above) why not just keep using VFP? It is a very mature and good product in what it does. Within its paradigm, there is really very little I can think of that needs to be added. So why not just stick with that? Nobody forces you to do anything else, you know.


RE: Visual FoxPro: A Dynamic Language?
Sunday, December 14, 2008 11:50 AM by MG

Hi Markus, Perhaps my comment wasn't clear as it was regarding your blog in general not about this specific post. Can you please remind me again what one of those reason are, why the industry has moved beyond monolithic languages? Which I'm not sure vfp falls truely into that category but for the sake of argument we can go with the assumption. The reality is, the main reason 'Microsoft" has moved on thereby forcing the industry to move on is solely for finacial gain. Their goal was to end royalty free distributions and tie custom applications to the operating system VIA the .BLOAT framework to further protect their windows monopoly. There is a podcast and blog, I believe by les pinter, where he overheard a comment directly from Bill Gates about VFP taking away from his SQL Server licensing base. Moreover while technically VFP will run the bottom line it is becoming less compatible with newer technologies and products, for example excel and SQL Server data types. This trend is likely to continue. Personally I really don't care if I use foxpro or not, I do care a great deal about the cost of the alternative, using the right solution for my clients and the extra amount of work Visual Studio causes. These factors directly impact my business. And yes I was forced into Visual Studio, it dont believe it is wise to start a new application using a discontinued development platform and despite my opinion of Microsoft I have alot of clients that require Microsoft based solutions. Personally if I could I would never use Visual Studio as it is the wrong platform for most applications. I highly doubt an auto company would stay in business long if they dropped their car line and only offered semi-trucks with only an AM radio with no heater and air condition. That just doesn't make sense. Yet that is exactly what is happening with development tools offered by microsoft. There is a one size fits all development tool paradigm that not only is accepted, people are cheerleading the product. This logic defies reason. Implementing an enterprise based solution for a mom and pop shop is like pounding a campbells soup can into the eye of a needle. Microsoft created a huge void for smaller desktop based applications which the industry as a whole fails to care about. Unless people start speaking up and calling a spade a spade Microsoft's decision to develop whatever garbage they want and spin it as a development tool or framework is going to continue. I don't understand how a product with less core data access functionality, higher cost of ownership and require more work for to complete are task is progress... Maybe I'm the only programmer left writing desktop applications for the mom and pop niche that actually cares about my clients and not working on some cool enterprise based application where VS is probably the appropriate development environment. Thanks for your time!


RE: Visual FoxPro: A Dynamic Language?
Sunday, December 14, 2008 3:44 PM by Markus - megger@eps-software.com

MG, check out the articles section on this site as well as others, where we discuss various scenarios. I am not sure why you call it ".BLOAT". Check out our Xiine application. It is a very rich and sophisticated app and it fits entirely on a 3 1/2" floppy disk (!!!). Not that I still use that, but it clearly shows that the "bloat" argument (which I haven't really seen by anyone else... kinda out of left field, this one is...) You can't do that in VFP. Not even close. As for the royalties: There is no royalty payment in .NET either. SQL Server costs money, so if you use that (whether from VFP or .NET) then you have to buy licenses. Not sure how this relates to a ".NET sucks" argument. And if you want to use a royalty free database, then you can use SQL Express or SQL Compact, both of which work well in the scenarios they are made for. They have limitations for sure, but so does VFP (2GB limit for instance... SQL Express goes beyond that although size is limited). If you want to build mom & pop apps, then you can probably use VFP, .NET, or quite a number of other environments and you will be quite happy. There is no reason why .NET couldn't do it. VFP will be suitable too however. The point is: That today, the problems many of us have to solve is maintainability, connectivity, scalability, productivity (combined with the other issues), interoperability with just about anything, and so on, and so on. If you are not facing these problems, then that doesn't mean other people aren't. I feel that just because you want to cater to smaller scenarios, doesn't make people who are thinking about bigger scenarios a [jerk].


RE: Visual FoxPro: A Dynamic Language?
Tuesday, December 16, 2008 2:07 PM by MG

I think everyone would agree on these basic principles that a framework should eliminate redundancy, be concise and force consistent application design. Given .NET is natively redundant and not concise (I think it has 70,000+ methods) it naturally fails the 3rd test of forcing a consistent application development patterns. Therefore if you want to refer to .NET as a framework then you must also consider it BLOAT. If you refer to .NET more it terms of what it really is, wrappers or an interface, then bloat would not be appropriate. For Microsoft’s spin machine a framework is the sexier term therefore for me so is BLOAT. Besides technical semantics do we really need 5 different data access technologies and each of them contain a certain suck factor and none of which can natively be used in the middle tier without the use of helper objects as in the case with LINQ for example to handle the data context...How can anyone not consider that bloat! Here is a thought why not build one data access methodology that works, can't be done you might say. Well it was under a DOS platform nonetheless! The .NET framework version 3.5 is approximately 230 MB I guess when you say your application fits on a 3.5” floppy you are assuming all the correct components are installed on the workstation otherwise you would not need the link on your download page that includes your exe with the .NET framework which is about a 238 meg download hardly fitting on a floppy disk. The same argument you are making can be said about VFP if the machine has the VFP runtime already installed just copy the application exe generated by vfp onto a floppy disk and the user is ready to go! Your point is moot. SQL server express is limited to 5 users (I believe) which is far more limiting then 2 GB of data storage. Restructuring tables to keep them under 2 gig is not rocket science. There is not a legal way to avoid the 5 user constraint. I don’t think you are a jerk (a cheerleader yes) having read you articles I know you are intelligent and because you are from the Foxpro community makes this even more frustrating. I think Visual Studio and .NET has a niche which is the larger enterprise-based applications and scenarios that you pointed out. The same niche companies are probably the ones that have Microsoft’s ear and driving the development process. Microsoft should have at least included enough core functionality, so moving from what you called a monolithic language to their new technology was not a step backwards which currently moving to .NET is in terms of generating an desktop base database application.


RE: Visual FoxPro: A Dynamic Language?
Thursday, December 18, 2008 2:41 AM by SiberCat

@MG I agree with you. Over the last year our team migrated 3 applications to VS. We encountered significant issues with VS/.NET including the lack luster VS class browser, c99 support, missing refactoring functionality and buggy C++ intellisense to name a few. Under the hood ".NET" is derieved from legacy code and creates a substantial amount of overhead. For example "Nativewindow" is the base class for the .NET controls and the edit control is derieved from the "EDIT" class released in early versions of the Windows SDK. IMHO VFP is far superior for middle tier data component development, the VS notion of only being able to treat data as an object is absurd. Since the 6.0 era of dev tools VS has been a disaster especially in terms of cross platform development.


RE: Visual FoxPro: A Dynamic Language?
Thursday, December 18, 2008 3:03 AM by Markus - megger@eps-software.com

I couldn't speak to C++ IntelliSense, since I never use it. The remark about derriving from native windows is true. In Windows, EVERY UI element has to be a window, whether one uses .NET WinForms, VFP, MFC, or even HTML. That is just how things work. The only system that isn't true for is DirectX, which works entirely different. This of course is also the WPF rendering engine. So the thinnest possible UI access for business applications is WPF in its native .NET implementation. So yes, there is overhead, but the overhead is no different in VFP than it is in .NET. Quite the contrary: VFP has to put a lot of its own UI rendering on top of the basics, which goes back to the VFP for Mac days, which made it impossible to use standard Windows UI without a layer in between. I do want to point out that I consider the statement that ".NET is derrived from legacy code" to be grossly misleading. Yes, if you use WinForms (for instance), you will get Win32 API calls. How else would it work? If you use other systems (WPF for instance), then you will not get that dependency. It really makes complete sense, when you think about it. And most of this is not specific to .NET. Anything that runs on Windows ultimately goes to the Windows API. You may consider that "legacy code", but there is no way to get around using it. I find it interesting (and difficult to reconcile) that you think VFP is a good middle-tier tool and at the same time, you do not like data in object form. How then, do you want to get data out of the middle tier? It is VFP's classic problem that there is no really fast way to write a middle tier and then pass that data on to the UI tier, other than making both VFP and couple those tiers tightly together. All the ways available to pass a cursor on to some other tier are hacks that perform very poorly. And we are only talking about multi-tier here, a technique that has been in the mainstream 15+ years, and has hit its limits, which are now being solved by the addition of SOA which has gained wide-spread adoption (especially relative to how long it has been around), which makes the problem even more difficult to handle for VFP... As for cross platform development: I am not aware of a good tool for cross-platform development. VFP sure ain't it at this point. Flash goes across platforms fine, but has pretty serious limitations in terms of business development. Silverlight (which is .NET) is better of there, but it is just a front-end tool. AIR is another effort along those lines. Kinda interesting, but slow as molasses. Java really has seriously disappointed for anything but the middle tier. And the list goes on and on. Cross-platform is a problem, but one is probably best of these days creating a SOA layer in the middle and various front ends. .NET can cover a lot, but not all of those. (iPhone, for instance). But one can write a front end component in just about any modern environment and get to SOA layers efficiently. The class browser was the VFP workhorse tool, true. Especially in the early days of .NET I have often wished I had it, especially since OO is and always has been so important to me. I even considered writing one. But in the end, I never wanted it badly enough to do it, and with modern systems, where composition tends to have gotten more important, I really haven't missed it so much anymore. Note: Based on your comments above, I assume you are doing all your .NET development in C++. Since you are talking about .NET, I assume you are in the small group of developers who use managed C++. I think it is really hard to look .NET from this angle and get a really good view. If you do .NET, then I would go as far as suggesting that going the managed C++ route is only of interest for those who have to move things forward. Otherwise, use C# (which should be easy to pick up for you) or VB. About the refactoring support: I have no idea how refactoring is handled in C++, but there is integrated refactoring support for C# and VB (which works quite well) and there are third party products that can be used very inexpensively. Personally, I use DevExpress' Refactor! Pro, which is an awesome tool. With that said, I am not sure what to make of your comment since you posted this to highlight VFP's qualities. VFP has a lot of great things, but there "ain't no refactoring" in VFP. At all. And based on how the language works, there is no safe way to do refactoring, really. In C# and VB, refactoring is guaranteed to work and have no side-effects, which is a crucial attribute of refactoring. (Note: refactoring in dynamic languages - which is what this post was about originally - on the other hand is a completely different can of worms...)


RE: Visual FoxPro: A Dynamic Language?
Thursday, December 18, 2008 3:11 AM by Markus - megger@eps-software.com

I forgot to address the c99 support: I am no expert in this field, but if you do managed C++, you have chosen a C++ dialect that is explicitly different from native C++. I am not sure that it even makes much sense to look for standards compliance there, since you specifically chose a purpose built dialect. Note: I assume we are not talking about native C++ here, since in that case, your entire post above would not make any sense at all.


 

 

 

 

 

 

 

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.