>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.

Hmm, I was aware of Singularity and that it is a research project. Maybe I was thinking of some other major MS product; I can't find any references.

There was the Sun JavaOS ( http://en.wikipedia.org/wiki/JavaOS ) some time ago, which was written mostly in Java. I suppose you have to think about what you call "managed code" and what you call an "OS" :)

>
>>- 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.

By "ongoing" I didn't mean to imply "incomplete, but working on it", I used it to mean "actively under development", in contrast to my later comment about VFP where development has ceased. Thanks for the update on Mono status - they seem to be a lot further along than I thought they were. I was under the impression that Miguel & co. had to reverse-engineer everything so they were way behind MS (e.g. maybe only supporting 1.1 when MS was solidly into 2.0). Do you know if Microsoft is helping/collaborating with Novell in furthering Mono development? That would be a good thing.

>
>>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.

Just out of interest - haven't seen you around here much, for a while. Can you give us some idea of your responsibilities in your new position with Microsoft?