[Sussex] .NET and Linux - a contrarian view

[Mark Harrison]

I thought it might be worth posting an opposing viewpoint about the move
to .NET. I think it's easy for us who appreciate the advantages of
open-source systems to assume that the closed-source world will have
trouble overcoming its problems. However, there is much genuine
innovation going on in places like MS.

There are a number of very interesting things going on with .NET which
WILL be of interest to all of us.

For a start, .NET launches with an Integrated Development Language for
three languages - VB, C#, and C++.

However, the .NET framework works by compilers compiling into an
intermediate language. This IL is supported by a common runtime. There
are several advantages to the way this is implemented over the
historical way in which the MS development tools have worked:

1: It's the same common runtime for all three languages - no more
fishing about with different install sets

2: It's the same common runtime for ALL the third-party languages that
are being developed to use the .NET framework. That means that
application deployment is going to get a LOT easier

3: There are third-party groups developing the common runtime for Linux.
MS is not officially announcing support for these, but actually the
development VPs seem to be aware that support for Linux is critical if
the framework is going to be adopted.

4: It's a common runtime for fat-clients and (web) servers. The same IDE
can realistically be used to develop, traditional apps, ASP / SOAP / XML
/ WebServices apps with complex object architectures, and for that
matter, console apps.

5: The (Visual Studio) compilers have the ability to compile to IL +
Metadata. The purpose of the Metadata is to allow reverse engineering
from IL back to source code. Why is this an advantage? Because the IL +
Metadata is entirely abstracted, and therefore it's possible to compile
VB into IL+MD, and reverse back into C# all within the IDE.

The fifth point strikes me as very exciting. It raises a series of
interesting questions about the evolution of open-source software. It
creates an abstracted mechanism to allow open-source developers to
release their applications across multiple platforms more easily AND to
deliver the source code in several languages with a common semantic.


To turn to the question of the migration engine. The feedback from the
(VB) developers I've spoken to is that it rewards methodical programmers
and punishes sloppy ones. My wife is a VB programmer - many of the
things that the migration engine objects to are things that are regarded
as poor practice anyway - stuff like DIM AS NEW <datatype> - stuff that,
actually, she avoids, because it leads to hard-to-maintain source code
even in VB6.

The biggest bugbear is likely to be lazy typing. The default for an
untyped declaration is now an Object rather than a Variant. Again,
punishes lazy programmers. However, most "methodical" programmers have
been cautioned against this kind of thing for years.

Now, the free-wheeling,
source-code-for-myself-and-others-clever-enough-to-understand-it brigade
will be those hardest hit. However, we have to question whether they are
actually the bulk of "corporate" programmers anyway? If, as my wife did,
one works for a large programming shop, then one is probably already
following a lot of the programming conventions that lead to a relatively
easy migration to .NET anyway.


Finally, it's not at all clear whether developers are ACTUALLY going to
rely on the MS conversion engine anyway. There are already a series of
third-party tools from people like CAST released to automate rather more
of the codebase conversion. There is already a consultancy ecosystem
developing that is building common methodologies for candidate analysis
and migration prioritisation.

Don't believe that this migration is going to be that hard for the big
programming shops...

... It's the independent, one-man, code-to-the-wire developments that
are going to find it hard to move.

Regards,

Mark