PEP 526 - var annotations and the spirit of python

[Ian Kelly]

On Sun, Jul 1, 2018 at 10:53 PM Jim Lee <jlee54 at gmail.com> wrote:
> 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.

There are much better yardsticks for measuring seniority than number
of languages known. Just because somebody knows a dozen languages
doesn't mean that they can come up with the correct algorithm, or
design an entire system, for a hill of beans. I'll take somebody at a
senior level who can do the latter well, but only codes in Smalltalk,
any day of the week.

> 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*.

I still see plenty of the former, but there's also good reason for the
latter. If your production system is built out of a dozen languages,
you may have a well-tuned system where each language was chosen for a
solid, specific reason; but you've also got a maintenance nightmare on
the day that the one programmer who actually understands all of it
decides to leave. Companies don't want the best possible language for
the job; they want code that they can continue to maintain into the
future. This is why, e.g., a large company like Google only has four
languages that are approved for general usage. It's not that they
wouldn't be useful; it's that the overhead of engineering complexity
(and therefore cost) goes up with the more that you use.

> 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.

Actually, the thinking is that as processors get ever faster and
cheaper, and as memory gets ever larger and cheaper, the cost of
software execution continues to drop, while the cost of software
development and maintenance remain the same. The latter is, therefore,
the component that is more important to address. General-purpose
languages haven't arisen because the programmers are lazy; it's
because the special-purpose languages are simply no longer necessary
for the majority of tasks, and in many cases are no longer worth the
costs of additional development overhead.