PEP 526 - var annotations and the spirit of python
jlee54 at gmail.com
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,
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",
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