RE: Re: VB vs C# is there a auto documenting feature in C#

That's a nifty idea, Richard, but for my money it misses on a three crucial
concepts.

The Common Language Runtime ensures that all managed languages have equal
access to the platform, but that's not the same as saying that all languages
surface the CLR in interchangeable ways. As I recall, the C# compiler never
produces a System.Delegate object; all delegates in C# are
System.MulticastDelegate whether they need multicast or not. That's a design
decision that should be up to the language writers. You can see the dilemma,
then, when trying to project IL onto C# if that IL contains a
System.Delegate object. 

While most of the language discussion here recently focused on the two most
popular managed languages, C# and VB.NET, if memory serves there are over 50
managed languages (maybe more by now). There are programmatic concepts that
are completely and radically different between languages. C# and VB.NET may
be too close conceptually for this to be apparent, so consider a managed
version of a language like ML or Haskell. These are languages where
functions are not allowed to have side effects. Clearly, I won't be able to
take arbitrary C# or VB.NET code and project it through IL onto a
side-effect free language.

That leads me to the illustrious Sapir-Whorf Hypothesis. ('Illustrious'
because that is how my college linguistics professor _always_ referred to
the illustrious Sapir-Whorf Hypothesis.) It says, about natural languages,
that a culture is shaped by the language it uses, and that, conversely, a
language is influenced by its culture. There is a reason that French is the
language of love, and that Eskimos numerous distinct terms for snow. It's
the same for computer languages: different languages should be free to be
designed to solve different problems. What is elegant and aesthetic in one
language is likely artificial and tortured in another. When a regular
expression or XSLT stylesheet is compiled in .NET, it gets compiled to an
in-memory assembly which can then be executed. Do I really want to see the
C# or COBOL.NET or Eiffel.NET representation of this IL? Gosh no, the
concepts, design elements and idioms are so far apart it would not be
pretty. It certainly wouldn't be code I'd want to maintain or extend in its
translated form.

In sum: languages don't surface the CLR in identical ways; languages don't
have the identical concepts; and there are compelling reasons for languages
to have different concepts.

What's the business case for trying to force VB.NET, C#, Comega, etc. to be
isomorphic, interchangeable and automatically translatable? What is the
benefit of this "next step" you are thinking of? I am not asking rhetorical
questions, I'm genuinely curious what you see as the benefit.

.NET already addresses this issue at the two extreme ends of the spectrum:
software integration in the CLR where all languages can interact (without
having to be identical); and software integration in Web services were the
only languages are the neutral languages of contract (WSDL) and messages
(SOAP). Why do you see the need for interchangeable languages on top of
that?

Instead, when converting a code base from one language to another we have to
do the same thing for computer languages that we do for natural languages.
We hire skilled linguists who are experts in both languages. Automated
translation doesn't cut it, and probably never will.

Time flies like an arrow.
Fruit flies like a banana.

Cheers,
Stuart

Stuart Celarier | Fern Creek | www.ferncrk.com