case for open lang on win32 - fill in the table

[Mark Hammond]

nielsenjf at my-deja.com wrote in message <7r3fhd$oqb$1 at nnrp1.deja.com>...

>> IDispatch plus about 100 extra interfaces.  We can not use raw
>interfaces if
>> there is no C++ support, but many useful interfaces already have that
>> support (and it is trivial to add new ones).  From a marketting POV,
>this
>> should definately read "yes" :-)
>
>When you say C++ support, I assume you mean there is code written than
>allows vtable access for python for some interfaces?

Exactly.  Although we do have tools that generate the C++ code given the IDL
file (actually, the .h generated from the .idl).  SWIG also comes to our
rescue too.  Also PythonCOM supports "plug-ins" - there is no need for this
C++ support to live in the core COM implementation.

>Is there c++ support for ADSI or MTS or OLEDB (which look to be the big
>things for windows 2000)? Or can we only access it via Idispatch(I know
>perl can do some stuff w/ADSI via Idispatch).

AFAIK, all of these are supported by IDispatch.  Eg, MTS and OLEDB are all
fine from Python.  I dont know about ADSI, but if Perl can use it via
IDispatch I bet we can too.  However, it will definately be true that if
there are shortcomings there, they will be addressed.

As to go completely off tangent, COM+ is coming, and will make much if this
irrelevent (although exactly how and when Python will support this is
anyone's guess)

>OLDEDB access would be cool since ADO is so slow.
>Perl has dbi to fix that problem.

Python as its own DB interface defined too, including full ODBC support.
Many "serious" database programmers use these techniques instead of the MS
COM interfaces (although IMO the MS interfaces are infinitely easier to use)

>I guess that was ambigous. It should be broken up into 2 things.
>
>Maximum size of project you can use it with:
>It looks like python projects can get huge.

This is hard to quantify.  You can obviously have 100,000 LOC VB programs -
just dont ask me to help maintain it :-)  To be quite honest, I would
suggest VB supports huge, but poorly structured applications better than
Python, simply because of better compile time checking.  But almost any
language can support huge projects with the correct standards and
organization.

>Amount of code needed to solve a problem:
>(for example in the recent Practice of Programming book, perl, java,C,
>c++ and others were compared, with perl being the fastest except for
>raw C code, but it only needed a fraction of the code. Java was slowest
>and needed a lot of code).

Probably very hard to quantify too, and IMO is misleading.  For example,
there was a recent thread on slashdot about Python, and someone pointed to
one of Fredriks samples saying "you call that easy to read?" -
unfortunately, the sample was clearly marked as the "short version".

Basically, either way you lose here.  If you provide code samples showing
how few lines it takes to solve a problem, it will necessarily be more
complex - thus people will feel the language is not obvious.  If you make
the code obvious, then people will compare it with code written to be small,
and say Python is verbose.

The only thing I can suggest is that you provide code samples, but these
samples _must_ be along the lines of "the way the typical programmer would
write it with 6 months experience in the language".  Or you insist on having
the "shorted possible (and reasonable) solution" _and_ the "clearest
possible solution" for all problems.

Anyway, getting way off topic here...

Mark.