Re: GDB and scripting languages - which

[Jim Blandy <jimb@codesourcery.com>]

I would prefer that GDB use a single extension language, and that that
language be Python.  Python has more momentum than Guile in almost any
way one might measure it:

- number of users who are familiar with it
- body of large programs written in it
- number of modules available for reuse
- number of programs embedding it
- number of books available for learning it

(I was the maintainer of Guile for several years, and I say this with
much kind regard for the people who have invested their time and
talents in Guile.  But Guile has had more than enough time to attract
uses and users on its own merits, and compared to Python, it hasn't
worked out.  It's time to cut our losses.)

It takes a lot of effort to pull together a useful interface for an
application.  Sustaining that effort for several different extension
languages would be a substantial burden.  I understand that it's a
quick weekend's work to implement a Guile or Python function that
passes MI requests and responses back and forth between Guile and GDB.
But this is just a bare stub of an interface.  An extension language
interface needs to provide higher-level functions:

- create and delete breakpoints, with callbacks when hit
- look up symbols
- enumerate object files, compilation units, functions, local variables
- pattern-match and construct types
- map between source locations and machine code locations
- represent container types like C++ map<> and vector<> in terms of
  their interface, not their implementation: a map<> is a key/value
  mapping, not a red-black tree; a vector<> is an ordered series of
  elements, not a length, size, and content pointer, or however it's
  done

All these things can be done via MI (perhaps with some extensions),
but it would be silly to have everyone writing their own functions to
send MI back and forth; there should be a library of functions to do
all this for you, so script authors can concentrate on what they
actually want GDB to do, instead of managing the details of MI.

Maintaining such libraries for multiple extension languages would be
wasted work, and python is good enough.