PEP 526 - var annotations and the spirit of python

Jim Lee jlee54 at
Sun Jul 1 23:51:42 EDT 2018

On 07/01/18 18:21, Steven D'Aprano wrote:
> Guido has been talking about this for a LONG time:

You keep bringing that up.  It's not an argument.

People have been talking about taxes for a long, long time.  Does it 
surprise you that they still do?  None of us has a time machine that 
will transport us back to the beginning to change the course of events.  
We can only read them as history (if we're lucky).  You enter the 
discussion whenever you get there.

> And for a perspective on why this is not only something desirable, but
> something which historically dynamic languages *used to have* but lost,
> see

I did get one epiphany out of that.  He's right - there are orders of 
magnitude more programmers today than there were a couple of decades ago 
- and they ARE almost all entry level, in that they are fluent in only 
one (maybe two) languages.

Back before the dot com boom, programmers (generally) knew at least 6, 
7, 8 languages.  They were intimately familiar with machine 
architecture, and knew how to pick the right language for any given task 
to exploit the features they wanted - speed, code size, I/O throughput, 
concurrency, interrupt latency, whatever.  In my case, the languages I 
became fluent in were C, Fortran, Assembly (several dialects and 
architectures), Forth, PL/M, Pascal, Modula-2, Oberon, Basic, Lisp, and 
Smalltalk.  Later on, Tcl, Hypertalk, Object Pascal, Prolog, and C++ 
were added.  Today, Python, Perl, Java and Lua round out the list.  And 
I have at least a working familiarity with several more.

The want ads used to be for positions like "systems programmer", 
"application programmer", "embedded engineer", "database designer", 
etc.  Today, the ads read "Java programmer", "Swift programmer", 
"Javascript programmer", ".NET architect".  The focus has shifted from 
the *domain* to the *language*.

And so, *most* of the new generation of programmers want to stick with 
one language for the long haul, and they'd like to cram every possible 
feature into it.  They look at the *language* the way we used to look at 
the *operating system*.

Languages that used to be small, lean, and exceptional at doing things 
really well in a given domain have morphed into large, monolithic, 
bloated language *systems* that do many things in many domains, and have 
many ways to do the *same* thing, but none of it particularly well.  
Throwing more processor horsepower and more GB of memory at the problem 
can only mask it for so long.


More information about the Python-list mailing list