source code size metric: Python and modern C++

[Duncan Grisby]

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

>I said that the documentation "...often does not...". Listing two
>examples does not provide any counter-evidence (unless there were only
>two routines in the standard library).

So you are permitted to use proof by blatant assertion, whereas I have
to do an exhaustive audit of the whole library documentation. That
sounds fair...

>I disagree. You must not consider the Python standard library robust
>because it almost never checks arguments (note once again that listing
>two counter-examples does not constitute proof of any kind).

With that attitude, there's no point in me looking to see how much
type checking goes on. Anyway, it's all irrelevant to the point in
hand, since most Python library functions are not the kinds of
functions that would be exported with an RPC system -- they are too
low level.

[...]
>> What if the types are significantly more complex?  For example, x is a
>> structure with members foo and bar; foo is a sequence of floating
>> point values; bar is either a string or a sequence of strings. 
>
>What happens if the strings have to begin with an uppercase letter, the
>floats must be 0 <= x < 1, etc. You are arguing for checking at exactly
>the level of granularity that your IDL has. I find that an interesting
>coincidence :-)

Actually, I would consider an IDL that permitted simple range checking
and that kind of thing a benefit. I never claimed CORBA's IDL was
perfect, just that it was useful.

>> How is an XML validation scheme different from an interface definition
>> language, except for being significantly harder to read and write?
>
>XML validation schemes can do more validation than IDL. Some of them are
>Turing complete so you can validate every aspect of the interface.

You seem to be arguing both that CORBA IDL is bad because it forces
static typing, and that it's bad because it doesn't allow you to
specify enough. Which side are you on?  I think it _would_ be good if
IDL could specify more.

[...]
>> Yes, I do think an IDL technique would get me to working code faster.
>
>OK, I'll send you a stub IDL. You will have 30 seconds to write a
>working Java/C++ program. You wanna try it?

You said you took 5 minutes and 30 seconds, including the time taken
to read the informal documentation. My claim is that if the
documentation had a more formal structure, it would take less time to
understand it. Writing code in C++ and Java is most definitely slower
than using Python. This discussion only started because someone used
XML-RPC as an example of why C++ is worse than Python; I think that's
unfair, since it's using a system specifically designed for
dynamically typed languages from a statically typed one. There are
plenty of good reasons for claiming that Python is better than C++,
without resorting to weak ones.

[...]
>How would you represent that structure in IDL where every possible
>combination of arguments is acceptable? Would you use a default value to
>indicate that the field is not in use? Then, in this case, I'd have to
>initialize 8 fields. Very annoying since my entire Python program was 1
>LOC. 

I'd use a sequence of unions. Here's a fragment of IDL

interface Meerkat {
  enum CriterionKind { ChannelKind, CategoryKind, ItemKind, SearchKind, ... };
  union Criterion switch (CriterionKind) {
    case ChannelKind:   short  channel;
    case CategoryKind:  long   category;
    case ItemKind:      long   item;
    case SearchKind:    string search;
    ...
  };
  typedef sequence<Criterion> Criteria;

  ResultSet getItems(in Criteria the_criteria);
};

Now the Python code would look like this:

  obj = orb.string_to_object("corbaloc::oreillynet.com/meerkat")
  meerkat = obj._narrow(Meerkat) # Make sure it's the object we thought
  result = meerkat.getItems([Meerkat.Criterion(search = '[Pp]ython')])

The only extra line of code is there to ensure the object has the
right type. That often isn't necessary, and you only have to do it
once, no matter how many calls you do to the object. Of course, the
C++ or Java code for this would be much longer, but that's the fault
of those languages, not CORBA.

Cheers,

Duncan.

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