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:

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sor...

Mozart/Oz comes last in cpu score. I suspect that may be due to
unfamilarity or poor implementation of the test codes. Everybody 'knows'
that benchamrks are always wrong, but which score moves this language to
the top in your opinion?

What the "language shootout" can possibly have to do with this issue
entirely escapes me.  Quite apart from "benchmarks are always wrong", I
don't think they're even _remotely_ trying to benchmark "how much does
learning this language teach you about different approaches to
programming" -- it would seem to be a mighty tall order to even set up a
controlled experiment to measure _that_ quantitatively!

In some ways, the syntax of Python is closer to free format Fortran
than C.

It's not _conceptually impossible_ to measure the didactical values of
different endeavours in terms of enhancing skills at some given target
tasks; it _is_, however, prohibitively costly, in most cases, to perform
properly controlled double-blind experiments of this nature.  In this
case, as in most other similar ones in real life, we're not even given a
precise set of target tasks, just (as is perfectly reasonable) a generic
potential desire to _learn about different approaches to programming_.

I think it would be silly to try to stop people from desiring to learn
something even when they can't quantify the eventual success at such
learning endeavours.  It's not just a matter of _programming languages_:
I have argued in the past that studying Borges or Calvino, Korzibsky or
Wittgenstein, category theory or nonmodal logic, can all be very
effective ways to broaden your thinking towards different approaches to
reasoning about the world, and therefore to design programs.  Can I
quantify the benefits, from this POV, of studying Korzibski for a
semester, versus those of spending the same amount of time and energy
studying Borges?  No, and I believe it's silly to even try to.

....

I take this to mean that comparisons can be done some other way. If so a
  rationalist such as myself would want them used. Discussing
Wittgenstein will probably not assist me if logic/mathematics can't.
Human languages are also not comparable numerically, but that doesn't
stop linguists from comparing and classifying them. I suppose there must
be an equivalent dissection for the fundamental concepts of CS languages.

I'm going to investigate all of them as time allows.  I must say that
Eiffel would most certainly expand my mind.  My initial reaction, when
looking at a "Hello World!" program, was "No way!". I had just read
some of SICP and "Pascal is for building pyramids ­ imposing,
breathtaking, static structures built by armies pushing heavy blocks
into place. Lisp is for building organisms ­ imposing, breathtaking,
dynamic structures built by squads fitting fluctuating myriads of
simpler organisms into place." sprang to mind, with Eiffel replacing
Pascal in this quote.  Attempting to be fair, I surfed over to
eiffel.com.  Eiffel has a lot of "high-minded" concepts, and it's easy
for a rookie, such as myself, to become inundated.  Ironically, while
watching Eiffel.com's presentation of "Design by Contract", my Gnome
desk top's control-panel crashed with a segmentation fault error
(seconds before the spill about how reliable DBC made Eiffel).  Much I
could learn from Eiffel.

SICP was another invaluable suggestion!  MIT uses it as part of their
OpenCourse program, so now I have a complete and free course in addition
to this excellent text.  Thank you.

As an aside, if you want to study Eiffel, the book to buy is _Object
Oriented Software Construction_, second edition, by Bertrand
Meyer. Everybody doing OO software should read this book, as the
lessons about constructing inheritance hierarchies are invaluable,
even if the language won't enforce them for you.

Accordingly I should put in a vote here for Objective CAML.
Cf. http://caml.inria.fr/ .  (Note the separate documentation
for Camlp4, specifically the "revised syntax".  Objective CAML's
original syntax has some bad warts, but it's optional.)  It's
a modern functional programming language, so it's good for
knowing what you're missing when people talk about using Python
for FP.  There's also a rigorously typed OOP layer, which
introduces a few issue that Python sort of "ducks".  (I haven't
spent a lot of time in the OOP layer, but I believe in a way
it formalizes "duck typing", rather than the inheritance based
type system that some languages are saddled with.)  So for a
Python programmer it's all about learning different approaches
to programming, but this one is also a really competitive
language for software development.  Not a gem, but not a toy.

Someone who already has Objective CAML and Python on hand
might be interested in Felix, http://felix.sourceforge.net.
I haven't actually used it, and for all I know it fails my
utility test since it is not a very mature language, but
I mention in in case anyone is interested in what the author
of the "vyper" Python implementation is up to these days.