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

https://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html


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.

-Jim


--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to