Since I wrote the linked to article (I came in to
work and everyone just said "read slashdot!").
I thought I might elaborate a little on what
information has surfaced since I wrote the Mercury and.NET page.
www2.hursley.ibm.com/tc39/mins-28sep00.html has some minutes of a ECMA meeting that
talks about the standardization of the CLI and C#.
Obviously we don't know what they mean by open-source and it isn't clear whether they want
to release their non-Windows implementation, but
I think there's nothing in the platform itself
that is Windows specific. The apps written on it
might be a different matter.
I think the important thing to do when trying to
guess Microsoft's motives here is try to understand how they are trying to improve on
Sun's offering. And remember that Microsoft
might not care too much about giving away a
platform that runs on all OSs (after all, Windows
earnings aren't the cash cow they used to be)
if it means they can make money on the platform.
Of course this is looking on the bright side,
perhaps their plan is much more nefarious and
evil in intent. My point is simply that because
Sun has been a bit closed and static with Java
and the JVM, perhaps Microsoft has something to
gain by being open with the CLR.
ASP is basically it's own programming language (albeit a small one), and ASP+ works by generating
interfaces on the fly into your language. You need to implement a code-generation API to do this.
BUT this code only gets run once -- to generate
the interfacing code. A few methods get generated
on the fly, then they get JITed and run as native
code from then on.
So you need to implement an API to plugin to the
ASP+, but that's just to interface ASP stuff to
your backend, once the code is actually running it
all runs as native and that API is no longer used.
I hope that explains it better. There is no per-call interface to go through (although you are doing stuff over the web so of course things have
to be turned into representations suitable for sending over the network).
For web services you don't even need to do any of
this, you just mark the service as a web service
and edit some configuration files.
For embedded languages you just edit some config files to tell it where to find your compiler.
This is a pretty much correct analysis of the
situation.
You can always implement any feature on the
JVM, but it might not be very efficient, and
it might not be very interoperable (that is,
other languages and tools can't use it because
they don't understand your implementation fully).
While the CLR doesn't support every language feature yet, it supports more than the JVM, and
has a view to changing in future versions.
Microsoft is differentiating themselves from Sun by providing a multi-language product that changes, instead of a single language product that is very rigid (or solid -- depending on your
preferences). Both had pros and cons, but for
3rd party language folks and researchers CLR is much more attractive in theory (but of course
success of it as a product when launched is a factor).
Yes, Perl and Python are there. ActiveState
was at the MS PDC. There's even a mailing list
about it at ActiveState (though I've seen no
traffic on it).
Yes, Haskell is definitely involved. So is an
ML group, Scheme (via some guys at Northwestern),
Oz, Component Pascal, Oberon, and other groups.
The mail about the NDA should still be in the
archives (if it isn't, it's a technical, not a
political problem). The issue on the mailing
list was that everyone thought
we were selling our technology out (we didn't,
it's still all open source), but we couldn't say that really we were being given a grant to do a
port.
If you check out the mercury-developers mailing
list you can even see the.NET backend being
reviewed.
With respect to attributes, these are mainly used for interoperation
with other programming languages. If you want to interoperate well with
C++, for example, you can put an attribute on a parameter that says that
C++ should consider this "int" to be a "long". The C++ compiler/tool
can then read the attribute from the metadata in the compiler C#
program, and generate the appropriate code or header file. In this way
you can provide "extra information" about language features. There are
two sorts of attribute -- a sort you can ignore (this is a "long", but if
you don't know what a long is, don't worry about it, just treat it as
an "int"), and the sort you can't ignore (this parameter is really
int[4..8] -- if you don't know what that means, don't even think about
calling this method). C# is used for writing a lot of class libraries
so it needs good support for attributes. I dare say it was also
Microsoft's testbed for the.NET architecture, so of course almost
everything that is in the architecture is in C#.
You can also use attributes to embed documentation, contracts, etc.
People who compile from a high-level language to C# (already happening)
will no doubt have many uses for attributes. Attributes are more of a
tool feature than a language feature -- as a programmer you probably
won't use many of them, but if you are systems programmer you might use
them (or generate them) a lot.
Generics are not the same as templates. There are literally hundreds of
languages out there that don't use templates for generics. In the.NET
runtime it looks like the approach will be to use a sort of dynamic
template expansion technique (you expand the templates as you JIT --
although this is a gross simplification). There are several languages
that already have generics on the.NET platform -- Eiffel, Mercury,
Haskell, ML (although I think ML uses whole-program compilation to
eliminate real genericity).
Finally, AFAIK nothing in.NET relies on COM. There is certainly full COM
interoperability built into the system libraries and tools -- basically
there is a tool that takes a COM type library and turns it into a.NET
component by creating forwarding stubs. There is an interop library
that does marshalling and so on. But if your code doesn't rely on a COM
component, you don't need this stuff.
Of course as a platform at the moment, most of the interesting
components you would want to use are COM components. But if people write
100%.NET code, you can run it anywhere. Obviously some people will not
do this -- it makes a lot more sense to just script COM components in.NET, at least until there are enough.NET components to replace them.
But given that deployment of.NET components is a lot more controlled
that COM, there is certainly some incentive to replace them.
Of course there are still platform specific APIs to contend with, but
they are always going to be an issue.
So AFAIK there's no reason why you couldn't write a.NET framework, and a C#
compiler that works under Linux (or whatever your favourite platform is).
This will be really quite possible if Microsoft does what they say they
will and standardizes them. You could also hook in support for CORBA
interoperability. You could put in support for SOAP. You could allow
it to run under Apache and do something like ASP+ and web methods.
They already have this in Japan. Singles looking
to meet other singles have some sort of gizmo
that lets them set their interests (romantic
dinners, long walks on the beach, that kind of
thing) and then if they are near someone who has
the same interests it tells them.
But obviously this would be a real computer on
your wrist, and you could load it up with any
software you like. So it's a lot more flexible
than any specialized equipment.
Of course people are just going to put Tamagotchi
and Tetris on it...
This is a very easy assumption to make.
But Australia has a very similar land mass to
the USA, and only 20 million people.
However, there is 100% coverage for mobile
phones across the entire country. Anywhere
that people actually live has GSM, and usually
multiple carriers (all using the same technical
standard) are available.
Phones are cheap (free phone, US $10 per month plans are common). Usage rates are very close
to the hot-spots in Europe. People who called
mobile users "yuppies" 10 years ago are now
swearing by the latest phones.
Rail has never worked in Australia very well.
But wireless communications has worked fine,
in fact it's an enormous industry, and
a completely accepted fact of life. I've been to
the USA several times recently and the difference in lifestyle as a result is quite incredible.
Australia has about the same size as the USA
(and only has about 20 million people).
But Australia has very good wireless communications systems, one of the highest uptake
rates of mobile phones in the world.
We use GSM and all the major
European telecos have offices here, do research and development here, and get their products onto
the market as soon as possible here.
Having a single technical standard for digital telecommunications helps enormously. And you wouldn't believe how powerful the whole system becomes when you are focused on a single standard.
When Australia recently engaged in some military
and aid action in East Timor, one of the telecos
simply extended their national network into East
Timor. My friend could talk to his girlfriend
(who was doing aid work) from Melbourne to East
Timor, and often it was free (standard evening
free calls promotion).
Look on the map and see how far this is. Distances are not really the problem. Population
density is not the problem. Existing landlines
are not the problem (Australia has had untimed cheap local calls for decades).
In America the problems seem to be too many
standards, too many players in the market,
poor billing ideas (charging someone for
receiving a call is just stupid), and perhaps
some cultural differences. It's hard to
say for sure. But mere geography alone is not
enough to explain it.
Shit, there was a kangaroo in inner Melbourne the other day. Melbourne has a population of close to 3 million. Someone must be giving them lifts into town.
Slashdot Mirror
www2.hursley.ibm.com/tc39/mins-28sep00.html has some minutes of a ECMA meeting that talks about the standardization of the CLI and C#. Obviously we don't know what they mean by open-source and it isn't clear whether they want to release their non-Windows implementation, but I think there's nothing in the platform itself that is Windows specific. The apps written on it might be a different matter.
I think the important thing to do when trying to guess Microsoft's motives here is try to understand how they are trying to improve on Sun's offering. And remember that Microsoft might not care too much about giving away a platform that runs on all OSs (after all, Windows earnings aren't the cash cow they used to be) if it means they can make money on the platform.
Of course this is looking on the bright side, perhaps their plan is much more nefarious and evil in intent. My point is simply that because Sun has been a bit closed and static with Java and the JVM, perhaps Microsoft has something to gain by being open with the CLR.
He's now retired from Microsoft. Hopefully Microsoft will soon put up a web site detailing what Project 7 was all about.
BUT this code only gets run once -- to generate the interfacing code. A few methods get generated on the fly, then they get JITed and run as native code from then on.
So you need to implement an API to plugin to the ASP+, but that's just to interface ASP stuff to your backend, once the code is actually running it all runs as native and that API is no longer used.
I hope that explains it better. There is no per-call interface to go through (although you are doing stuff over the web so of course things have to be turned into representations suitable for sending over the network).
For web services you don't even need to do any of this, you just mark the service as a web service and edit some configuration files.
For embedded languages you just edit some config files to tell it where to find your compiler.
Only ASP+ needs "real" work to be done.
You can always implement any feature on the JVM, but it might not be very efficient, and it might not be very interoperable (that is, other languages and tools can't use it because they don't understand your implementation fully).
While the CLR doesn't support every language feature yet, it supports more than the JVM, and has a view to changing in future versions.
Microsoft is differentiating themselves from Sun by providing a multi-language product that changes, instead of a single language product that is very rigid (or solid -- depending on your preferences). Both had pros and cons, but for 3rd party language folks and researchers CLR is much more attractive in theory (but of course success of it as a product when launched is a factor).
Yes, Perl and Python are there. ActiveState was at the MS PDC. There's even a mailing list about it at ActiveState (though I've seen no traffic on it).
Yes, Haskell is definitely involved. So is an
ML group, Scheme (via some guys at Northwestern),
Oz, Component Pascal, Oberon, and other groups.
The mail about the NDA should still be in the
archives (if it isn't, it's a technical, not a
political problem). The issue on the mailing
list was that everyone thought
we were selling our technology out (we didn't,
it's still all open source), but we couldn't say that really we were being given a grant to do a
port.
If you check out the mercury-developers mailing
list you can even see the
reviewed.
You can also use attributes to embed documentation, contracts, etc. People who compile from a high-level language to C# (already happening) will no doubt have many uses for attributes. Attributes are more of a tool feature than a language feature -- as a programmer you probably won't use many of them, but if you are systems programmer you might use them (or generate them) a lot.
Generics are not the same as templates. There are literally hundreds of languages out there that don't use templates for generics. In the .NET
runtime it looks like the approach will be to use a sort of dynamic
template expansion technique (you expand the templates as you JIT --
although this is a gross simplification). There are several languages
that already have generics on the .NET platform -- Eiffel, Mercury,
Haskell, ML (although I think ML uses whole-program compilation to
eliminate real genericity).
Finally, AFAIK nothing in .NET relies on COM. There is certainly full COM
interoperability built into the system libraries and tools -- basically
there is a tool that takes a COM type library and turns it into a .NET
component by creating forwarding stubs. There is an interop library
that does marshalling and so on. But if your code doesn't rely on a COM
component, you don't need this stuff.
Of course as a platform at the moment, most of the interesting components you would want to use are COM components. But if people write 100% .NET code, you can run it anywhere. Obviously some people will not
do this -- it makes a lot more sense to just script COM components in .NET, at least until there are enough .NET components to replace them.
But given that deployment of .NET components is a lot more controlled
that COM, there is certainly some incentive to replace them.
Of course there are still platform specific APIs to contend with, but
they are always going to be an issue.
So AFAIK there's no reason why you couldn't write a .NET framework, and a C#
compiler that works under Linux (or whatever your favourite platform is).
This will be really quite possible if Microsoft does what they say they
will and standardizes them. You could also hook in support for CORBA
interoperability. You could put in support for SOAP. You could allow
it to run under Apache and do something like ASP+ and web methods.
But obviously this would be a real computer on your wrist, and you could load it up with any software you like. So it's a lot more flexible than any specialized equipment.
Of course people are just going to put Tamagotchi and Tetris on it...
However, there is 100% coverage for mobile phones across the entire country. Anywhere that people actually live has GSM, and usually multiple carriers (all using the same technical standard) are available.
Phones are cheap (free phone, US $10 per month plans are common). Usage rates are very close to the hot-spots in Europe. People who called mobile users "yuppies" 10 years ago are now swearing by the latest phones.
Rail has never worked in Australia very well. But wireless communications has worked fine, in fact it's an enormous industry, and a completely accepted fact of life. I've been to the USA several times recently and the difference in lifestyle as a result is quite incredible.
But Australia has very good wireless communications systems, one of the highest uptake rates of mobile phones in the world. We use GSM and all the major European telecos have offices here, do research and development here, and get their products onto the market as soon as possible here.
Having a single technical standard for digital telecommunications helps enormously. And you wouldn't believe how powerful the whole system becomes when you are focused on a single standard. When Australia recently engaged in some military and aid action in East Timor, one of the telecos simply extended their national network into East Timor. My friend could talk to his girlfriend (who was doing aid work) from Melbourne to East Timor, and often it was free (standard evening free calls promotion).
Look on the map and see how far this is. Distances are not really the problem. Population density is not the problem. Existing landlines are not the problem (Australia has had untimed cheap local calls for decades).
In America the problems seem to be too many standards, too many players in the market, poor billing ideas (charging someone for receiving a call is just stupid), and perhaps some cultural differences. It's hard to say for sure. But mere geography alone is not enough to explain it.
Shit, there was a kangaroo in inner Melbourne
the other day. Melbourne has a population
of close to 3 million. Someone must be giving
them lifts into town.
I saw it in Seattle, and when the Space Needle
came one, everyone fell apart laughing.