source code size metric: Python and modern C++

[Duncan Grisby]

In article <mailman.1039059246.30953.python-list at python.org>,
Ian Bicking  <ianb at colorstudy.com> wrote:

>But the IDL doesn't describe the service either -- because it's so
>formal, it's not tremendously helpful for documenting the interface in a
>way that's useful for the programmer.

I don't understand that statement. How is unambiguously specifying the
operations available and the types involved not helpful?  I agree that
it's not _all_ you need, but given that you need to specify types, you
might as well specify them in a way that's understandable to the
system, so it can write some checking code for you.

[...]
>All the hard and important and subtle parts of specifying an interface
>aren't part of the IDL.  Just like static typing at compile time only
>catches easy bugs, I think static typing over a network interface will
>mostly catch easy bugs.

I agree, but they're the kind of easy bug that requires code to check
for, if you're not certain that your caller is correct. If the system
can write that code for you, then surely you've benefitted. Most
Python code doesn't have to check its argument types, since it's a
simple debugging issue to make sure the caller is getting it right. In
most distributed systems, you can't be certain your callers are
getting it right.

>That said, I don't think an XMLRPC example is really fair -- XMLRPC was
>designed for languages like Python, not languages like C++.  It may very
>well be superior than CORBA in many domains -- very possibly because
>it's designed for languages like Python -- but even if it wasn't it
>would still be easier to use in Python than C++.

Yes, but systems like CORBA are easier to use from Python than systems
like XML-RPC are. Non trivial Python XML-RPC programs will in general
have to do more argument checking than the equivalent Python CORBA
programs. That's not to say that with CORBA you do no checking at all,
just that you have to do less.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --