Terry:

> Yes - but it's not the full reason. IMO one major benefit of moving to Dot
> Net does not appear to have been mentioned in these threads - Rapid
> Application Development.

I'm not sure where you get that from. ".NET" is a platform. It's real
name is "CLI" which stands for Common Language Infrastructure. This
consists of the Common Language Runtime ("CLR"), the Framework class
libraries, and various tools and utilities.

..NET is simply a platform upon which you can build languages which
easily interoperate with each other. There is nothing in the CLI spec.
that dictates how any particular language should be implemented, nor is
there anything that addresses RAD, or anything even remotely related to
the development process.

The CLI is sufficiently flexible so that you can build languages as
diverse as C++, Cobol, RPG, Perl, etc. on top of it but it's totally up
to the language vendor what RAD features are in any particular language,
it really has nothing at all to do with the fact that any of those
languages might be implemented on the .NET platform as opposed to
generating native code.

> Dot Net puts a wrapper around our code which means various things - it means
> we can subject our code to the verifier at a fairly high level.

How do you see .NET putting a wrapper around your code? If by
"verifier" you're talking about PEVerify, that really isn't an end user
tool. With the exception of unverifiable things like pointers,
CLS-compliant compilers will always generate verifiable code. PEVerify
checks the IL code to see if it is valid and complies with the rules, it
isn't a tool to check end-user code for correctness.

> If we use all the tools/techniques offered by the Dot Net concept -
> simplified language constructs (LINQ), Interface constructs or indeed
> interface programming, Enumerations and so on we shall end up, fairly
> quickly, with a hopefully bug-free program. Of course the final quality of
> our programs still depends on our experience.

These are all interesting and useful language constructs, but I really
don't see any of them as a way to write code that is significantly more
bug-free.

> Another major benefit is the ability to mix languages - militating towards
> RAD and application integrity because we can "think" and write our solutions
> to sub-problems in the most appropriate way. (This, by the way, is where I
> feel Vulcan missed an opportunity to slant the language to a business way of
> thinking - we already have a language slanted to the software engineer's way
> of thinking and that is C#).

Please be more specific. What do you think we could do in this area?
xBase languages are in general slanted towards business applications
because of their built-in database capabilities.

--
Don