Typing system vs. Java

[Alex Martelli]

"Jonathan Hogg" <jonathan at onegoodidea.com> wrote in message
news:jonathan-D4822F.08343331072001 at news.easynet.co.uk...
> In article <mailman.996524288.7635.python-list at python.org>,
>  <brueckd at tbye.com> wrote:
>
> > Others on here have pointed out that using C++/Java as an example of a
> > strongly-typed language is a mistake, so maybe my opinion is closer to
> > "the typing systems in C++ and Java tend to cause me more work and
> > problems" and not strong, static typing.
>
> Bingo. This is Java's fault for not having parametric polymorphism
> rather than a problem with strong static typing per se. In my opinion
> it's unfair to lump C++ in with Java since C++ at least has templates to
> do this sort of thing.

True.  On the other hand, C++ has really no way to let
you specify "a sequence of things of ANY types at all", which
IS sometimes useful (e.g., Python's lists:-) and you get in
Java with Vector (almost everything in Java descends from
Object, and you can easily wrap into Object-derived equivalents
those few fundamental types that don't, such as integer).

Even for "a sequence of *pointers* to things of any types",
vector<void*> doesn't really work as well as Java's Vector,
since you get NO *runtime* checks of type correctness as
you pull pointers out and cast them back as needed (C++
does have dynamic_cast for runtime checking, but it does
not apply to types that have no virtual-table -- only
classes with virtual methods get effective use of the
dynamic_cast and its runtime checking).

So, summarizing: the (relative) strengths and weaknesses of
the ways in which Java and C++ let you escape (some of) the
constraints of strong typing present trade-offs (Java PLUS
generics, as in good old Pizza, or, I'm told, some future
forthcoming Java enhanced version, will definitely be a big
step forward, though).


> Maybe I just haven't been writing large enough programs in Python, but I
> don't feel that I hit many errors where I think "damn! I wish the
> compiler had picked this up for me". I'd be interested in other people's
> opinion on this. (And I've programmed plenty in Haskell so I know a
> strong static typing system when I see one.)

I've often wished I could use Haskell typeclasses in a
Python program, but haven't been bitten particularly hard
by lack of compile-time checking in Python.  Such a lack
does mean that many errors are caught a BIT later than
they should be -- a delay of between about one and about
ten minutes in most cases (when I'm being good and coding
test-first -- when I'm *NOT*, I have far worse problems
in my code than the typo-level errors a compiler could
catch:-).

The single kind of issue where I've found the highest
cost for lack of type declarations in Python, in my
experience so far, is with documentation of library
modules.  When a docstring says or implies argument f
must be a file, I know that's probably not true, it just
needs to be a file-like object, but, HOW file-like does
it need to be?  Does it have to implement, e.g., .read(N)
for an integer N, or will just .read() without arguments
suffice?  (and so on, and so forth).  When a docstring
says or implies argument L must be a list, I know that's
likely not true, it may well suffice for L to be some
kind of sequence, BUT, how closely does it have to mimic
list interface?  Ditto for "a function" (it can probably
be any callable, but ...) and so on.

That's why I'm SO keen for the PEPs that propose that
Python add interfaces and protocol-adaptation concepts
to the language.  They won't be *compile-time* checked
and I don't really care -- but they *WILL* formalize
the polymorphism kind and amount required and supplied
by library modules.  That will save me lots of code
reading or experimentation that I now need to make best
use of some library modules...!-).


> I can though, think of plenty of places where strong static typing would
> defeat intentional exploitation of the dynamic typing. Maybe this is

Sure, and that's what happens when some [expletive deleted]
module author codes
    assert type(a)==type(b)
and other similar cases of type-testing -- they break my
beautiful signature-based polymorphism into smithereens.
I tend to think VERY unkind thoughts each time I see such
a typetest (or even the slightly less-hateful isinstance).

> poor programming on my part, but I can't even think how one would type a
> function like say:
>
>    def f(zs): return reduce( lambda x, y: x + y, zs )

I'd type it
    def f(zs): return reduce(operator.add, zs)
as I *particularly* despise using lambda where any halfway
decent alternative presents itself, but that's quite
tangential to your issue, of course:-).

> Python's dynamic typing has the most optimal type for this function:
>
>    "A function that takes something looking like a sequence of
>     things that you can call "+" on, and returns something that
>     you might get back by "+"ing a bunch of such things together."

It's somewhat subtler (each application of '+' must produce an
object such that you can again '+' it with the NEXT item of zs),
but that's more a problem in theory than in practice.

> else. If you find Java/C++ too horrific, then I'd seriously recommend
> O'Caml - though this is just from a cursory look, I did most of my FP in
> Haskell but I don't think I could recommend it unless you're willing to
> become a serious FP-head and want to get to grips with Monads ;-)

For some reason O'Caml keeps feeling to me like a modern-day
C++ -- a grabbag of every interesting concept the authors can
possibly think of, with peculiar quirky syntax to tie it all
together, and a lot of emphasis on run-time efficiency.  Any
comparison with the sheer elegance of Haskell (its whitespace-
using clean syntax, its lazy-semantics default, its beautiful
typeclass concept...) seems to be out of place... although I
do understand that O'Caml can make much-faster code than
Haskell, and I do confess that monads always did stretch the
limits of my conceptualization abilities...


Alex