PEP 526 - var annotations and the spirit of python

[Dan Stromberg]

On Mon, Jul 2, 2018 at 6:10 PM, Jim Lee <jlee54 at gmail.com> wrote:

> On 07/02/18 17:34, Dan Stromberg wrote:
>
> The fact of the matter is the economics have changed a lot since then.
> Machine time used to be really expensive compared to developer time.
> Today, it's the opposite: developer time is really expensive compared to
> machine time.
>
>
> If you go back far enough, yes.  But for the majority of the past, the
> tradeoff was developer time vs time to market.  That's why we had an
> explosion of RAD tools in the '90s.  It became more important to develop an
> application *quickly* rather than *correctly*.  And that philosophy
> continues to this day.  Python is a descendant of the RAD philosophy.
>
> (By correctly, I mean using the resources available in an efficient and
> non-wasteful manner.)
>
Nod.  It's really common for a startup to slap something together in a
hurry, cutting corners all over, to secure funding.

Then after they get the funding, they go back and fix the mess they created.

This isn't shoddy craftsmanship.  It's the reality of investment and first
mover advantage.

> It doesn't make much sense anymore to wring one's hands about "throwing"
> more computer power at a problem.
>
> We've already hit a wall performance-wise.  Physics only allows so many
> electrons to flow through a nm-sized pipe.  Now, the "solution" is to keep
> adding more cores. But that doesn't help if an application doesn't lend
> itself to a multi-threaded design.  So, software efficiency will once again
> become the bottleneck.
>

I'm inclined to agree that we've hit a bit of a wall in singlecore
performance.  We'll almost certainly blast past it at some point, but new
physics may have to be explored first. However, singlecore performance is
fast enough now that we don't have to obsess about minutia.

I think soon a language like Haskell, OCaml, Scala, Clojure, etcetera will
autoparallelize well.   I'd love to see that be a Python implementation,
but I'm not that confident it will be - Python has too many side effects
for that to be likely.

Fortunately, multithreading isn't the only way to take advantage of many
cores.