[Mono-list] Re: Is Objective-C support possible?

[Fergus Henderson]

On 15-Feb-2002, Miguel de Icaza <miguel@ximian.com> wrote:
> [someone wrote:]
> > This article suggests it would be impossible to write an Objective-C or TOM
> > compiler for .NET or any .NET clones. Can anybody clarify this issue?
...
> Writing an Objective-C compiler is just a matter of time.  There is no
> technological barrier.

Miguel is right that there is no technological obstacle to writing an
Objective-C compiler for the .NET CLR.  However, it would be wrong to
assume that the resulting system could be used to seamlessly interoperate
with other languages on the .NET CLR.  It would also be dangerous to assume
that the resulting system would perform with efficiency comparable
to a native-code Objective-C compiler.

The article in question <http://www.javalobby.org/clr.html> says

 |    The CLR is supposed to be equally
 |    friendly to any language you throw at it, and this is being sold as a
 |    huge advantage of the .NET platform: free choice of programming
 |    language. The CLR would not only support multiple languages, but also
 |    make easy to mix them: a single program could match classes written in
 |    different languages.

and I think this is a reasonable summary of the message coming from
Microsoft marketing.  But the author of the article, Doederlein,
is right to critique this message.  While there are definitely
some grains of truth in such claims, there are also some important
caveats to them which people should be aware of.

Some points in the article, e.g. the following, are quite reasonable.

 |    Unfortunately, this whole debate acknowledges .NET to be
 |    language-neutral in the first place, which is simply not true,
 |    certainly not in the extent advertised by Microsoft.

But some points in the article are overblown.
In particular,

 |    We follow with a partial list of limitations of the CLR/CTS/CLS.
 |      * Implementation Inheritance. The CLS only supports single, static
 |        inheritance.
 ...
 |    The result: Dialects that cripple the original languages to become
 |    CLR-compatible. Examples are Managed C++ and Eiffel#, both not
 |    supporting implementation MI.

Here the blame should be put on the implementors of Managed C++
and Eiffel#, not on the CLR design.  The Eiffel# implementors have
certainly said that they plan to implement full Eiffel in the future.
AFAIK the main reasons full Eiffel was not supported initially are just
the usual ones -- limited time and manpower.

 |      * Generic Types. There is currently zero support for generic
 |        programming in the CLS.
 ...
 |    The Result: Half-baked generic type support without cross-language
 |    capability. Crippling important details of some implementations, like
 |    covariance (gone from Eiffel#).

Here the lack of cross-language interoperability for generic types
is definitely due to the CLR design.  But language implementations
which only have "half-baked" generic type support are just half-baked
implementations, and don't prove anything about whether full generic
support is possible.  For the Mercury implementation, we do support all
the features of Mercury's generic type system, including multi-parameter
type classes, constrained genericity, and existential types.  Certainly
implementing some features, such as covariance, may be harder than others.
But the right conclusion to draw here is just that implementing a
compiler for .NET may be harder than it first appears, not that
the CLR's design prevents these features from being implemented.

 |      * Static Typing.
 ...
 |    This is not good for languages that use completely dynamic typing to
 |    avoid the complexity of static type systems.

The article does not make it clear here that dynamically typed languages can
just use the `System.Object' type, so this is just a performance issue.

 |      * Performance Issues. [...]
 | 
 |    Once support for many languages becomes available for the CLR, people
 |    will start writing the same microbenchmarks in multiple languages and
 |    run them all on the CLR. Of course C# will look faster than everything
 |    else, but people will incorrectly assume that C# is intrinsically
 |    more efficient than all other languages,

I think this is unlikely, since people will also compare the CLR's
performance with the same microbenchmarks compiled directly to native code.

 |    More recently, Halcyon's Instant Net (http://www.halcyonsoft.com/)
 |    adds spice to the debate: this product translates .NET executables
 |    (MSIL code) into Java!  [...] It's still early to tell 
 |    or if the new layers of frameworks will have big tradeoffs in
 |    performance and other concerns,

It's too early to tell for sure, but a priori it seems very likely that
languages whose compilers which make significant use of .NET CLR features
which are not present in Java, such as value types and by-reference
arguments, will run significantly less efficiently if the .NET CLR code
is then converted to Java.

 |    and I doubt iNet will support
 |    unmanaged code (the only kind of .NET code that cannot be easily
 |    translated to JVM-compatible bytecode).

I think the author meant "unverifiable code", rather than "unmanaged code".
"Unmanaged code" is not .NET CLR code at all, it's just native code.
And there would certainly be significant difficulties translating
unverifiable code to JVM-compatible bytecode.

 | Conclusion
 | 
 |    The Common Language Runtime is being sold as a libertarian technology
 |    that levels the playing field for minority languages. The CLR would
 |    offer to all languages a neutral typesystem, a state-of-the-art
 |    back-end compiler, runtime and set of enterprise-class frameworks.
 |    VisualStudio.NET makes this complete with a first-rate IDE that can be
 |    extended to support any language. It would almost zero the barrier to
 |    entry for new languages.
 |    
 |    The reality looks much darker instead. The CLR is not truly
 |    language-neutral, and it will ostensibly favor languages that look a
 |    lot like C#.

The conclusions are valid up to here...
 
 |    Those not in this group will be severely bastardized,
 |    producing dialects which are really "C# with another syntax"; look at
 |    ISE's Eiffel# (or even Microsoft's own VB.NET and J#) for great
 |    examples. Programmers' choice will be limited to superficial features:
 |    whether to delimit their blocks with curly braces, Begin/End or
 |    parentheses.

... but here they are not.  Languages such as Haskell and Mercury,
which are very different from C#, will be available on .NET.
Whether the languages used are bastardized dialects or not
will depend on how much people really care about it.
It is certainly possible to produce fully-baked implementations
of languages such as Eiffel, it's just more effort.

 |    This scenario will severely block innovation in the programming
 |    language field because a whole generation of programmers may be
 |    educated by CLR-compatible languages, and what they will learn is that
 |    all languages are identical.

This conclusion is overly pessimistic.  Only the CLS-compliant subsets
will exhibit such sameness.  Component interfaces will be strongly
encouraged to stick to this subset, but programmers can use the full
features of their language of choice in the component implementation.

 |    A very significant part of the problem is the closed nature of the
 |    CLR. Microsoft brags loudly about the ECMA C#/CLS standard, but will
 |    keep absolute control of all frameworks and implementations.

This of course is false -- Microsoft has almost no control over
the Mono and Portable.Net implementations.

 |    Vendors
 |    of minor languages cannot customize any part of the CLR to better
 |    support something that's not C# in disguise.

This is false too; vendors of minor languages can 
 
 |    Even if CLR's level of language neutrality becomes
 |    important, this can be patched into the JVM without major effort.

I find that claim hard to believe.  Stack-local allocation, by-ref
arguments, and the Win32 model of resumable exception handling do not
look to me like minor patches.

 |    Unmanaged code is the only radical departure from the current JVM,
 |    but we're not likely to want the big tradeoff in robustness and security.

I think the author meant "unverifiable code" again.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.