Microsoft's C# (Sharp) & .NET -- A Heads Up

[Alex Martelli]

<piet at cs.uu.nl> wrote in message news:uhfa7qn9c.fsf at cs.uu.nl...
> >>>>> "Alex Martelli" <alex at magenta.com> (AM) writes:
>
> AM> Don Tuttle <tuttledon at hotmail.com> wrote in message
> AM> news:qJ165.8938$nZ5.153196 at typhoon.southeast.rr.com...
> >> Consider this a heads up NOT a promotion!!
>
> AM> Why would the Python community care about a Microsoft-proprietary
> AM> quasi-Java-clone...?
>
> It is not proprietary. They will put the language definition in the public
> domain. Maybe not the implementation.

OK, let's assume they do.  And so...?  It's a Java dialect
in anything but name, and not a very interesting one either
("Pizza" added much more significant enhancements a LONG
time ago, for example).

I believe the only relevant issue for the Python community
is: C#, like every other Microsoft offering in recent times,
will be *STRONGLY* oriented to COM.  Every C# object will be
a COM object (just like every Java object was one when run
under Microsoft's Java VM), etc, etc.

So, C#'s possible (unlikely...) emergence as a major language
is just the N-plus-1-th motivation for Windows versions of
Python to support COM *very, VERY* well.  There are many
other reasons which apply *right now*, of course.  Python's
COM support is good, but I think it could be better.  Type
libraries are no doubt (at some point in the future) going
to be obsoleted in favour of other, fuller meta-information,
but until that happens I think any enhancement in support
for them is going to be a very significant plus for Python,
for example.  Custom (non-dual) interfaces may be in decline,
but, again, there is very substantial need for support for
them *today* -- Python supports a lot of them, but, again,
I'd like to see more -- more ease in interfacing a given set
of interfaces to Python (maybe by autobuilding a .PYD for
them?), more ease in generating 'stub' implementations for
them to which Python substance can be added, ...

Yeah, I know, I should put my coding efforts where my mouth
is -- and, having expended substantial efforts doing just
this sort of thing for a proprietary scripting language
(which I'm pushing _hard_ to be "stabilized" in the future
in favour of much better languages such as Python!), I do
have the skills and experience... on the COM side of things,
at least; haven't really looked at Python's internals yet,
and it's been so long since I last programmed in C (as
opposed to C++) that I wonder if I still can...:-).

But anyway, that's my personal take on the C# "impact"
(comparable to that of a goosedown pillow) on Python.

Re .NET -- I dunno, and I wish I did!  Any relevant URLs
will be GRATEFULLY received - I could post a dozen, but
I'll do y'all a favour and summarize them into basically
two stances:
    "It's Microsoft and thus evil, vapourware, immoral,
        and/or fattening"
    "It's Microsoft and thus good, splendid, progressive,
        and/or sexy"

Nothing REAL, TECHNICAL, DETAILED, nothing one could sink
one's teeth into, sigh.  Well, apart from XML, and SOAP
in particular, but those we already knew as today's silver
bullets (and, seriously, they do have real technical
substance, of course; the more Microsoft's architectures
get "open" by such means, the better -- but Python is
already moving fast towards excellent support of XML and
even SOAP, so there's no course-change in sight because
of those, is there?  Just, once again, extra motivation
to do what's already being done).

I do wonder what other items that have technical reality
are in .NET besides C#, XML, and SOAP.  If any, that is.


Alex