The reason is that I often work with hardware, and hardware means C (since every
vendor I have ever dealt with provides a C API for their drivers).

It combines well with the CPython interpreter as that, as you may have guessed
from the name, is written in C and exports a direct C/API.

Cheers,
Nick.

For use *with* Python, C could be helpful. I end up writing a little bit
of C or C++ every once in a while to speed up my calculations or to use
some library written in C or C++.

If you do numeric calculations, learning just enough FORTRAN to do loops
and math can be quite useful. I find that F2PY makes writing FORTRAN
subroutines for numerical calculations over Numeric arrays much easier
than C.

If you develop on a Mac, some Objective-C could come in handy. I find
that it's object model and dynamism are quite close to Python's. The
lessons you learn in each should reinforce the other's. PyObjC makes
mixing the two languages dead easy and more convenient than indoor
plumbing. However, almost all Objective-C texts require knowledge of C
(which makes sense, since Objective-C is a true superset of C, unlike C++).

For didactic purposes, I suggest picking something distinctly *less*
like C/Java/Python. Learn something that's going to expand the way you
think about programming. And when you learn a new paradigm, implement it
in Python and share it with the rest of us.  :-)  For example, Phillip
J. Eby took the idea of "generic functions" from the Common Lisp Object
System and implemented it for us[1]. (BTW, thank you, Phillip.)

Common Lisp might be a good one to learn. It's even more
"multi-paradigm" than Python. You could very easily learn more
approaches to programming through Common Lisp than three other
languages. This book[2] looks promising.

Summary recommendation: Learn Python and a language that complements it
*pedagogically*. When you are fluent in Python and encounter a problem
where you want to, for example, use a library written in C, then learn
some C.

[1] http://dirtsimple.org/2004/11/generic-functions-have-landed.html

[2] http://www.gigamonkeys.com/book/

--
Robert Kern
rk...@ucsd.edu

Part of the Python philosphy is that there should be one obvious way
to do something. That's what makes it an attractive language to
me. Eiffel shares this philosphy, in that every feature of the
language was added to solve a specific problem that programmers
encounter. It does many other things the exact opposite of
Python. It's statically typed, with no loopholes allowed. For cases
where you're not sure that something is conformant with a variable
(meaning it's the same class as the variable or inherits from it in
some way), there's even a "work if you can" assignment operator. So
you see code that looks like:

       a ?= b
       if a /= Void then
          doSomethingWith(a)
       else
          doSomethingElseWith(b)
       end

As you can see, it keywords instead of :. It's pure OO, in that there
are no free-standing functions; every function is a method of a
class. Functions aren't first-class objects, so you can invoke
parameterless methods with just object.method. This allows subclasses
to change such a method to a variable without you having to change any
code anywhere else in the system. It has export rules to control what
features (shorthand for methods and instance/class variables) are
visible to what other classes. Exceptions are handled in a completely
different method as well, with a method having an optional "rescue"
clause that gets invoked when an exception is raised, should repair
things, and then retries the method.

The key feature is "Design by Contract". Each method can have a set of
boolean expressions that must be true when the method is invoked, or
an exception is raised. Likewise, each method has a set of boolean
expressions that must be true when the function exits, or an exception
is raised. Finally, there's a set of expressions that are always true
when an externally-invoked method exits. These are the contracts, and
they make debugging wonderful. You can disable all those checks for
production code.

There are tools to display the the method headers, header comment, and
contracts (short form). There is a tool to display all methods a class
has, including inherited methods (flat form), and of course there's a
tool that displays the shortflat form.

If you want to do GUI programming on Windows, Linux or FreeBSD 5.x,
EiffelStudio is probably your best bet. It comes with a standard GUI
library, an IDE built on that library, and a reasonably
standards-compliant compiler and library. It hasn't yet drifted into
the parts of the language that are undergoing experimental changes.

Probably C, but Pyrex is also a strong contender for _use_.  Problem is,
there are a zillion great books on C, none on Pyrex: thus, having to
choose one of them, C enjoys a huge advantage in _learning_.  Also,
while Pyrex is amazingly mature and solid, it no doubt still has some
little way to go -- for example, the pypy project had to introduce a
small extension to Pyrex (the ability to inject inline C code, namely
labels and goto statements) in order to use Pyrex as the target for code
generation -- while C's completeness and stability are indisputable.

C's key advantages: it has much the same _philosophy_ as Python --
simplicity, lack of redundancy, trust in the programmer -- while aiming
squarely at the LOW end of language levels, closer to the machine, as
much as Python aims squarely at the HIGH end, closer to application
programming needs.  This makes them a great complement for each other.

Pyrex is close to "C with Python syntax" and is designed for ease of
interfacing with Python, generating on your behalf all the boilerplate
code that you'd normally need to do the interfacing with the Python C
API directly.  Still, I've never taught Pyrex to anybody who didn't
already know at least _some_ C, so it feels risky to recommend as "the
one othe language besides Python"...

I haven't looked at D enough to judge whether it's fully portable, fully
stable, and just as easy to interface with Python as C; also, I don't
know how the material available for it compares to C's excellence.

Objective-C is cool... on the Mac; I'm not sure how well-supported it is
elsewhere, though.  In addition to C's advantages, it would let you make
Cocoa GUIs on the Mac easily (with PyObjC &c).  But then, the right way
to study Obj-C from scratch is no doubt to start with C, anyway.

OCAML and other modern functional languages are great, but not
particularly easy to use in cooperation with Python.  If you had to pick
one for purely cultural purposes, though, I'd suggest Haskell... simpler
and sharper... OCAML is relatively Big and Rich, which may be a
practical plus but for study purposes is rather a minus, I think.  Much
the same applies to (Common) Lisp and C++: huge languages, very rich,
which may be a plus for practical production uses but surely isn't for
study purposes.

You start with pure declarative programming (aka "functional" in many
circles), move on to concurrency in a purely declarative worldview
(easiest way to see concurrency), then enrich both sequential and
concurrent models as the book progresses, by message-passing, explicit
state ("procedural"), object-oriented, _shared_ state, and finally
relational.  GUI, distributed, and constraint-based programming round
out a grandiose conceptual tour.

"SICP for the 21st Century"...?  (SICP: google for it!).  I currently
think so, though, studying CTMCP (the Oz book) in my spare time, it will
take me a while before I've finished it and can fairly offer such a
lofty recommendation for it... still, I notice from the back-page blurbs
that Peter Norvig has no reservations drawing a parallel with SICP (aka
Abelson and Sussman), and Norvig's assessment must count for more than
mine!

Have you read SICP yet?  If not, that's your next task.  The full
text is online: