Typed Python?

[Michael Sparks]

On 6 Jul 2004, Ville Vainio wrote:

> "Real" work is admittedly a bit careless choice of words. Non-academic
> work is often more concerned with delivering stuff, while academic
> work is more exploratory in nature

That's not really the best distinction IME. Non-academic work can be
exploratory in nature as well. For me the real difference is with academia
something not working/panning out is just as interesting/valid in many
respects as something suceeding - indeed in some cases more interesting.
In non-academia, something not suceeding normally means overhead to the
business, and increasing the costs to the company. In severe cases if this
continues companies involved and go bust.

ie the bottom line difference is that in the non-academic world whether
the solution is correct, pretty, ideal is less important than whether the
code actually does what's required or not.

There can be an intersection between ideals - and IME python is one of the
best intersections. It has a cleanliness to it that is more common in
"academic" languages - like SML, but a practicality about it that is more
like the Perl/C's of the world. Test first has become the practical answer
to formal specification. Clean imperative languages being able to glue
easily with systems, have become a practical alternative to conventional
functional languages like SML. (OCaml being an interesting convergence
from the other direction)

The reality of the situation in the non-academic world is that the
majority of programmers out there either code in C-like syntax languages
or have been weaned on languages like visual basic. For such programmers
picking up python is incredibly easy. I think this is heavily due to the
fact that if you ask many programmers to describe an algorithm in
pseudocode, they generally drop all the crappy syntactic decorators (such
as "{", "}" etc) and rely on indentation to convey meaning. ie they drop
all the syntactic cruft.

The resulting pseudocode is almost executable python. The upshot is that
many programmers speak python natively when asked to describe what they
want to do. A lisp/scheme-esque equivalent might be more like:

plus:
   times:
      1 2
   minus:
      10 2

However you don't see that. It's not the sort of thing that you see most
programmers writing - unless they're trying to figure out a parse tree.

Furthermore, depsite Scheme/lisp appearing less ambiguous, "everything has
the same construct", to many new programmers (I've taught introductory
programming to new users) the more punctuation you have, the more confused
they get. This is particularly true if you try teaching programming to
non-science (graduate level) students.

And whilst this might seem a trivial point, it's worth remembering that
new users generally don't interpret things you expect. For example:

if x is not None:
   print "hello"
else:
   print "Goodbye"

Looks pretty unamiguous to a programmer's eyes. The most interesting
description I've heard from a non-programmer looking at that is:
"If x is something, print 'hello' and if that fails print 'goodbye'"
ie something semantically more like:

if x is not None:
   try:
      print "hello"
   except:
      print "Goodbye"

Adding brackets to this gains a new programmer *nothing* and for the
majority of cases the extra syntax gets in the way.

To my mind, bringing these two halves back together, python is the
language of choice simply because it's inately programmer friendly and
*encourages* clean code(*), with these attributes working together to make
it easier to deliver code that works, and is maintainable.
     (*) Like functional languages

Finally the real killer point with python is the ability to use things
like Pyrex to be able to augment python code with types so that
compilation to C is trivial, and effective. This means you can explore
a half dozen potential implementations, pick the most effective or
maintainable and optimise using Pyrex should it become necessary.

And what benefit does that bring? It brings the academic and non-academic
worlds closer together - bringing cold hard shocks and benefits to both
sides.

Regards,


Michael.