Python is DOOMED! Again!

[Paul Rubin]

Sturla Molden <sturla.molden at gmail.com> writes:
> Type hinting will be mandatory because of bad managers.

That's a pretty weird concept: I've worked for good managers and bad
ones, but so far never one who imposed any low-level code style
decisions without also being involved in writing the code.  That was
always left to project leads.  Upper management (i.e. the CTO) sometimes
made high level decisions like "the production apps will be in Java not
Python" but that's different.

> But then someone is going to ask what benefit Python has to offer:
>
> Readabiliy? No ... down the drain.

The type hints don't impair readability as far as I can tell.  Rather,
they help it, since they indicate concisely what the function does.

> Dynamic typing? No ... down the drain.

It's still dynamic in the sense of having a universal type, and the
hints can also let the compiler specialize.

> Speed? No ... still 200x slower than Swift.

I don't think it's anything like 200x now, especially with pypy.  The
type hints will allow more optimization though the language semantics
will always keep it a slower than C/C++ (dunno about Swift).  

> Why go for Python? There is no benefit to it any longer.

The type hints look like an improvement to me.  I'd use them if they
were available.  I wouldn't have any problem with a project lead
mandating them, just like they currently mandate use of specific unit
test packages, etc.  I could imagine mandating them in a project that I
was leading.  The "bad management" thing only applies when someone
mandates coding practices that they themselves don't have to follow.

I think you're imagining some terrible scenario that's not close to
reality.  Erlang has a similar feature that I've already mentioned a few
times in this thread.  I've used it and it's a good feature.  It helps
keep the code organized and it doesn't get in the way too much.  You
don't have to put a signature on every function: it's optional so you
can put them in just the important places and let the tool figure out
the rest.

If you use a seriously typeful language like Haskell, you have to design
your whole program around the static types.  But with Erlang you can
code pretty much the same way you would in Python, add a few signatures
here and there, and that's enough for the analysis tool to do some quite
useful checks.

I remember in one of the endless static-vs-dynamic debates on
comp.lang.lisp, someone mentioned a code instrumentation experiment that
found that even in dynamic languages, most functions were monomorphic in
practice.  I think that's mostly because experienced programmers
unconsciously follow an ML-like type discipline most of the time, even
when the compiler isn't enforcing it.  So having some compile-time
checking will mostly do good.