source code size metric: Python and modern C++

[Duncan Grisby]

In article <mailman.1038954486.29692.python-list at python.org>,
Brian Quinlan  <brian at sweetapp.com> wrote:

>If you have to write/use IDL code then you've already lost the coding
>convenience war.

I disagree. You are going to have to tell people writing clients to
your services what their interfaces are, otherwise they won't be able
to understand how to use them. Given that you've got to do that, and
you've got to make sure you are unambiguous in your descriptions, a
formal interface definition language is a huge benefit.

[...]
>> More
>> significantly for Python, we don't have to check that the add method
>> really does return an integer (like we do with Python XML-RPC), since
>> the RPC runtime does it for us.
>
>And maybe that helps us and maybe not. In the add example that I gave,
>the add function will happily add floats, strings, ints, lists, etc.
>Types that cannot be added will generate an exception. As a Python
>developer, this is exactly what I expect.

I'm not convinced that that kind of ability is so useful when you
think about real functions in real applications, of the level suitable
for use in an RPC system. I think it's useful for low-level functions
like adding things, and generic algorithms like sorting, but much less
useful for higher level things.

>Also, it presumes that type checking is an important part of data
>validation, which it might not be. It may be more important, for
>example, to ensure that the arguments are < 100. 

But in that example, you'd still need to ensure the value being
checked was numeric before doing the test, or be prepared to deal with
the exception if it wasn't. Having the RPC runtime guarantee that
something is numeric reduces the amount of checking code you have to
write. This issue is easily obscured when you're talking about toy
examples, since there are usually few side effects to an unexpected
exception happening. In a function like this, who cares if there's an
exception on the test...

  def simple(value):
      if value < 100:
          return 100 - value
      else:
          return 0

but in a function that does more work...

  def complex(name, a, b, c, value):
      x = doSomethingWithName(name)
      y = addItUp(x, a, b)
      z = doAnotherThing(name, c, y)
      if value < z:
          r = z - value
      else:
          r = 0
      return doTheLastThing(x, y, z, r)

Imagine some of the functions that are called have side effects --
they modify some state somewhere. Now we're in trouble if the < check
throws an exception. To be safe, we'd have to do an explicit numeric
check as the first thing in the function. We'd also have to explicitly
check the types of all the other arguments.

Of course, the same issue is there in normal Python programs. In that
case, making sure functions are called with the right argument types
is purely a debugging issue, and it's usually easy to look at a
function to see what it's expecting. In a distributed environment, you
don't have so much control over the clients, and clients may be
actively malicious. Any help the environment can provide in protecting
you from unexpected inputs is a good thing.

Cheers,

Duncan.

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