Re: GDB and scripting languages - which

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Feb 14, 2007 at 07:46:27PM +0200, Eli Zaretskii wrote:
> > But in any case those aren't the
> > ones I had in mind: I was thinking of things like XML, text
> > processing, and high-performance numerics.
> 
> More details would help make this discussion more constructive.  How
> ``high-performance'' should our numerics be, and why?  Do you have any
> quantitative criteria?
> 
> As for text processing, what features do you think we need,
> specifically?

I don't know the answers to these questions.  They are things which I
think will be useful.  We don't have the faintest idea what we will
make possible by doing this work, or what users will come up with.
That's my goal - enabling entirely new uses.

> > Based on this discussion, I think we probably won't convince you that
> > Python is the best choice.
> 
> Why do you think so?

Based solely on the tone of the discussion, and five years working
with this group of people on this mailing list through past
discussions with similar tone.  I'm looking for something that won't
make anyone furious; we rarely manage to make everyone happy, but we
routinely manage to find conclusions that no one is too upset with.

I apologize if that sounds overly cynical of me.

I said at the very top of this thread that I thought bikeshedding over
which programming language to use was the worst possible use of our
time, and asked followups not to do so.  I can't say that I'm
surprised by the portion of the followups that were specifically about
the choice of language.  I think a suitable language that
(conservatively) ten times as many people know is clearly more useful
than a suitable language that far fewer people know.

You mentioned in another message that you considered things like
networking and graphics support to be excessive and wasted weight.
They are modules completely separate from the interpreter, and would
not be part of GDB's "footprint" unless someone wrote scripts which
used them.  And Lua has similar modules.  I see both a socket library
and GTK+ bindings for GUI use.

Have you used either Lua or Python in other projects?  Do you have
impressions of them from the script writer's perspective?

> I certainly didn't dismiss anyone's arguments as
> easily as others dismiss mine.  The only real argument in favor of
> Python that I heard was that it's widely used and known.  That's not a
> lot to become convinced, since what I'm suggesting is not some unknown
> language either, or something invented just now.

Neither are any of the others we've considered.  I don't think I can
say this any differently than I already have: the order of magnitude
more people that work in Python make it more useful, and the existing
GDB contributors with Python experience make Python more feasible.

I am not dismissing your arguments, but personally I have not found
them compelling.  I have seen no language features in Lua that make it
a better choice than Python.  For instance, you made a comment about
"complete" programming languages requiring type declarations and memory
allocation -- certainly that is not the case in Python, which is a
typical scripting language in those respects.

(I'm not sure what you meant by "initialization before use".  You'll
get a catchable exception in Python if you use something before you
initialize it, instead of a default empty value as you would in shell
scripting.)

I do not have any evidence that the extra "weight" of a Python
interpreter would be a problem, and I believe (as I said above) that
it is a priceless feature.  Here is the subset of the Python modules
installed on my system which seem clearly useful from GDB.

  python-ctypes, for interaction with other C support libraries
  python-gdbm (and others), for managing program trace data stored
    in databases
  python-numeric, vector and matrix calculations, e.g. to record
    and analyze the results of computation in the debuggee.
  python-stats, similarly.
  python-xml, for translating data both to and from XML for
    interaction with other tools

And that's just off the top of my head - if we enable some sort of
threads or graphics, then custom data browsers might be an interesting
option for people who otherwise want to use a text-only debugger.  And
so forth.

-- 
Daniel Jacobowitz
CodeSourcery