Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
.Net Versus VFP
Message
From
09/11/2007 23:53:29
 
 
To
09/11/2007 04:42:06
Al Doman (Online)
M3 Enterprises Inc.
North Vancouver, British Columbia, Canada
General information
Forum:
Politics
Category:
Other
Title:
Miscellaneous
Thread ID:
01267685
Message ID:
01268171
Views:
11
Hi, Al.

Great and well-balanced list. I like to make a few comments, though:

>- Perhaps surprisingly, in overall architecture .Net and VFP are similar. Both take source code and "compile" it to an intermediate form, then run that intermediate/tokenized code against a runtime, which provides an "application virtual machine" with automatic memory management, garbage collection etc.

This is almost true, but while VFP runs as an interpreter (p-code is parsed and run over the runtime every time), .NET languages compiles first to IL, and then the runtime compiles the IL in the first run (what's called Just-In-Time compilation) and the actual machine code is cached for subsequent runs (you can also force native compilation before running if you wish). While this could sound like a small difference, the effect on performance is very important, and even more important, this allows the same IL (same assemblies) to be deployed in different platforms (32bits, 64bits, mobile, etc) but always run as native code.

>- VFP is loosely typed (you can easily change a variable from one type to another, you don't have to pre-declare them etc.). By default .Net languages are strongly typed, which has pluses and minuses. I understand .Net is or is going to offer some dynamic/loose typing support with the so-called DLR.

The DLR (Dynamic Language Runtime) provides a common type system for dynamic languages, but they are not usually loosely typed, they are dynamically but strongly typed. This means that while you don't need to declare types up-front and you can even change types at runtime, type information and safety is provided at compile time in most cases. The safety level is not the same as in a static language, but it is stronger than in VFP, where types are not checked at all until rutime.

>- The scope of .Net is very broad, basically all of Windows. Unlike VFP it can be used for system-level and/or high-performance computing. IIRC Microsoft has, at least once, tried to write a complete version of Windows in .Net but couldn't get it to work (and/or perform adequately). This would be completely unthinkable with VFP.

You may be referring to singularity, which is a Microsoft Research project, not a product in development, and is oriented to build a whole kernel on managed code. The project is going quite well and has proven a lot of stuff, while it also surfaced a bunch of technical challenges that have to be solved. Truth is that no one wrote a full operating system in any sort of managed environment until now, and Singularity is probably the project that farther in this space.

>- There are efforts to make .Net run on platforms other than Windows - both by Microsoft, and others (e.g. Mono by Novell). These efforts are ongoing and a primary focus of development by both Microsoft and others. In contrast, VFP runs only on 32-bit Windows, although this environment can be provided by emulators on 64-bit Windows (i.e. WoW) and (technically) Win32 emulators on Linux (e.g. Wine), although the latter is legally prohibited by the VFP9 EULA.

Mono is quite more than an ongoing project. It is widely used by now, and it supports Winforms, Webforms, and most of .NET 2.0, plus a good deal of WCF. It doesn't support WPF which is something very complex and tied to Windows, but they are currently quite advanced in LINQ support and several other pieces of the .NET 3.5 framework.

>I'm sure I'm missing a bunch of other points, and may be outdated or plain wrong on some of the above but it should at least give you an overview.

As far as I know, you did an excellent job, and my comments are just clarifications. I hope this thread keep going as good talk like this one.

Best regards,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform