anygui,anydb, any opinions?

[Skip Montanaro]

    >> Apparently, most Python people feel productive enough without such a
    >> tool.

    Thomas> As did many with Fortran. Or Cobol. Are we now so productive
    Thomas> that there is no longer an unmet need for new/better software?
    Thomas> Do we stop here?  Is Python a comfortable place for the Luddites
    Thomas> hang out.

There's a difference.  When I began programming, the only tools I had were
the IBM card punch machine (basically a typewriter to enter my program) and
the printout I got from the operator via my drop box (to show me compilation
or run-time errors or my program's output on those rare instances when the
PL/1 compiler didn't barf on my deck).  In that situation, switching to a
better set of tools (an ed(1)-like editor displayed on a CRT hooked up to
our school's CDC timesharing system) was a no-brainer.  It wasn't all that
big a jump to switch to PR1ME computer's full-screen editor (probably
something like vi, though it's been so long I can't remember anymore).
After leaving school and moving on to VAX/VMS I looked around for another
full-screen editor, farted around with EDT for a bit, but eventually
stumbled upon Gosling's Emacs (on a DECUS tape I think), then GNU Emacs
awhile later, then in the past three or four years settled on XEmacs.  (I no
longer remember how I edited BASIC code on the IMSAI 8080.)

About 25 years have elapsed since my first exposure to Gosmacs.  As you
might imagine, I now have a fair amount of cortical area devoted to
Emacs-fu.  Based on my inability to help my son with his geometry homework
this year I suspect most of the neurons that had previously been devoted to
Euclidean geometry have been taken over by Emacs.  Here's a quick summary of
(some of) the functionality available to me from within Emacs that relates
more-or-less directly to programming Python:

* I do all my basic text editing and software development in Emacs, both
  local and remote files, but I also read mail there, including this mailing
  list.  If I had more of a Usenet mindset I could read it in Emacs as well.

* Python mode (thanks Tim & Barry) gives me access to inline help for
  attributes of many builtin objects, it does a good job of colorizing my
  code, supporting block moves and block comments and alerts me to runaway
  strings.

* With pycomplete hooked up to Pymacs, it can do a pretty decent job
  completing partial expressions.

* Using Emacs' builtin compilation facility I run pychecker over my code and
  step through the messages it emits.  (I suppose with a little thought I
  could modify the compilation facility to define pychecker suppressions
  on-the-fly as I pick through pychecker's output.)

* Emacs' tags facility lets me effortlessly jump to class and function
  definitions in my code.

* I can get Python tracebacks when sitting at a gdb prompt using a little
  snippet of gdb's command language.  If I wanted to I could use pdb to set
  breakpoints and execute my code under control of the pdb debugger but I
  generally just insert print statements.

* I've also messed around a little with Bicycle Repair Man, a refactoring
  editor written in Python that integrates into Emacs via Pymacs.

* I can also edit C and C++ code in the same editing/compilation/debugging
  environment when the need arises.

* I can transparently use CVS or SCCS (and I suspect Clearcase and
  Subversion) from within Emacs, without being aware of the different
  packages' syntaxes.

* If I need to work from home I can ssh into my desktop computer at work and
  using gnuclient, connect up to a running Emacs session that's got all the
  state I built up while at work.

The learning curve for me to switch to something other than Emacs for
software development at this point just isn't worth it.  I'm sure the same
would be true of long-term vi users or people accustomed to other
full-featured editors.  (Both Emacs and vi have the advantage that they are
available on all major computing platforms.)

Maybe I'm arguing for a tight integration between an IDE and an external
editor and just don't realize it.  I suppose it can be done, but I suspect
it would be a major challenge.  If not, it would have been done well already
by other tools.  Instead, my limited experience in this area suggests that
most development environments just punt and use whatever feeble editing
widget is available in the author's chosen widget set.  They all seem feeble
and slow to me, mostly because they aren't optimized for editing fixed width
text.

OTOH, maybe I'm arguing for a better integration of other tools/packages
with Emacs and more complete documentation of what's already available.
Should anyone be interested in helping out, a good place to tackle that
would be in the python-mode project on SF
<http://sourceforge.net/projects/python-mode/>.  I do know from past
experience with other tools that "providing basic Emacs keybindings" just
doesn't cut it.  Where are the rectangle and register commands?  What about
macros?  (How would I live without macros?)  At this point it's not just
basic typing skills I would have to transfer to another tool to be able to
switch and be as productive as I am with Emacs today.  Sure, you can laugh
at the kitchen sink that Emacs has become over the years, but it supports a
lot of functionality.  Think of it as an IDE framework & tool chest if you
like.  I'm sure I've only scratched the surface.

In short, just because I still program in Emacs, don't assume I write my
code on stone with hammer and chisel.

Skip