[offtopic] marshalling

Tyson Dowd trd@cs.mu.OZ.AU
Wed, 3 Jan 2001 19:32:41 +1100


On 02-Jan-2001, linas@linas.org <linas@linas.org> wrote:
> This is way off-topic, but ...
> 
> It's been rumoured that Tyson Dowd said:
> >
> > (Actually M$ has a lot more in the whole language infrastructure thing,
> > since their VM supports multiple language interoperation at the data
> > level on the same machine -- no marshalling required.  
> 
> Well, that's kind-of what we do with g-wrap, and its kind-of what's
> behind one of the original early claims of gnome's ORBit: that with
> orbit, a call on the same machine would be roughly as fast as an
> ordinary subroutine call. (I don't know if they kept that promise).
> 
> Here's the question: if one writes a soap dtd/schema in the M$
> framework, it will then auto-generate language bindings for several 
> languages? (i.e. they treat the  soap dtd/schema as an IDL for 
> all practical purposes? OR did they invent some new IDL language?)

This one is answered by Chris Browne and followed up by myself in a
sub-thread. 

> ------------------
> I also gather that microsoft's strategic direction with .net is to
> control the VM: they have thier one standard true VM, while the rest
> of the world has to live with multiple incompatible VM's (i.e. the 
> Java vm, the perl VM, the guile VM, ...)  

You'd think that, but given that they have submitted the whole thing to
ECMA for standardization clearly either 
	- they think that they can control it despite the standard
	- they have some other motives.
ECMA typically requires 2 implementations from separate vendors before
standardization so I would say that a second, non-Windows implementation
will become available at some point.  MS has an option to make Corel
develop .NET for Linux (although if Corel is selling their Linux
business, I'm not sure where that option goes).

Possible other motives:

	- Want to puncture the JVM balloon.
	- Want to become an ASP and need a platform for it.
	- Want to control the web services market (how are you going to
	  find that web service... and how much will you pay?).
	- Don't want to be hurt again by next groovy new language on
	  the block
	- Preparing to jettison windows platform in breakup -- apps
	  division can continue on .NET, windows division can burn in
	  flames.
	- Tired of bickering in their tools division, want a unified
	  platform to speed their own development
	- Last ditch lashing out before inevitable death spiral

Personally I tend to think they are becoming an ASP, and they want to be
the gatekeeper of all the cool services people will pay $14.95 a month to
access.

> And, of course, the corrolary question: should I feel bad about this? 
> Other than integrated tools, and backwards compatibility with visual
> basic and java, what, exactly, does .net offer that I can't get
> today?

I hate to do Microsoft's marketing for them, but...

- Deep data-level interoperability.
- Relatively universal runtime system.
- Full interoperability with native code and COM.
- VM embedded in useful places.
- Better support for non-Java languages.
- Toolset supports all these languages.

------

Each of these explained in detail below...

There's one technical feature of .NET that tends to get lost in the
spin.  This might give you an idea of the level of interoperability
you can get.  It's possible (indeed, it's simple) for a class written in
one language to inherit from a class written in another language. 
Since there a single root class (Object) this happens all the time.
This is full object orientation, virtual methods, implementation
inheritance, you name it.  Accessing a field or calling a method of a
type written in another language is as easy as if it were one written in
your language.  Everyone uses the same garbage collector so there are no
more problems with interoperability of memory management (well, unless
you go to native code).  Marshalling only happens when going to native
code, or calling remote methods.

There are around 15 languages that currently target the runtime.
VC++, C#, VB and JScript are provided by MS.
Eiffel, COBOL, Smalltalk, Perl, Python, Haskell, Scheme, Mercury, 
Component Pascal, Oberon, ML and Oz have been provided by third parties.
Others are happening.  Languages with advanced implementations will show
interfaces from other languages as if you had written them in your own.
For example, if I only know VB, that doesn't stop me using a class that
COBOL provides -- I don't have to know any COBOL, it just looks like a
VB interface to me (perhaps with a lot of capital letters).

The runtime allows full interop with native code -- there are
(unverifiable) bytecode instructions that allow raw pointer access.  You
can write device drivers in C# (if you really want to).

The VM has been put in places like IIS (their webserver) and will
end up in SQL server too.  This means you can write queries in any
language you like -- they will be jit compiled and run inside the
database.  IIS is setup to allow any .NET targetting language to be used
as a scripting language for web pages.  The web page code will be jit
compiled and will run as native code after the first hit.

You can get most of this stuff with JVM today, but you have to write all
your code in Java.  And if you want to interop with other languages, you
have to do it through SOAP or through native methods.  Although it's
true there are compilers that generate Java, most of them are pretty 
sub-optimal.  For example, Java doesn't support tailcall, so languages
that rely on recursion (scheme is one) are pretty much screwed.  Java
doesn't support call-by-reference, so languages with output parameters
(Pascal is one) have to jump through hoops.  All this means that your
interoperability is more fragile, harder to use, and tools have no hope
in hell of understanding what you program is really doing.

The toolset supports all these languages.  Target .NET and you
automatically get a debugger (with source linked debugging) and a profiler. 
The standard demo is to show COBOL, C# and VB methods calling each other
and you can step line by line through each language.  Also, many
languages are involved in the Visual Studio Integration Program, which
basically means they can integrate right into the GUI, providing syntax
highlighting, tooltips (e.g. pop up [char *fmtstring, ...] if the developer
types printf), wizards, and all those bits and pieces that seem to be
popular among some developers.

------

But there is no Java compatibility.  Microsoft no longer does Java.  I
believe there is a court order to that effect (or at least, that's how
they'd like to interpret the court order at the moment).

And there's no backward compatibility with VB 6.  VB 7 is going to be a
new language, basically.  Reports are that almost no lines of VB 6 can
be used unchanged.  Of course there will be translators.

I won't bother discussing the cons.  I'm sure everyone can think of
their own, and besides, my brain is starting to hurt from writing email
today.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd@cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #