Executive summary: This thread is about a "seven blind men and an
elephant" problem.
Jim J. Jewett writes:
> I think his point is that most of his students (economics or
> business, rather than comp sci) will never need to use Perl or C or
> Java. Python is friendly enough to be useful, but this is still a
> major pain point.
Not sure if "his" refers to me, but I don't know what they're going to
need to use. C/C++, maybe not, but there are a lot of Perl and
especially Java shops in Tokyo still. The largest group of my
students end up as what the Japanese call "SE" ("systems engineers"),
by which they mean a sales/requirements gathering/training/customer
relations role. Many of the rest end up in tech-adjacent roles. I
think all of them would benefit from a little command-line experience,
and a better understanding of how a group of programs cooperates to
become a system. As their teacher, I certainly would!
> The problem is made worse because it often hits at the beginning
> instead of 7 lessons in, when they would have some reason to think
> it is worth struggling through and will eventually work.
I think we're on the same page, but "7 lessons in" is still early in
my experience teaching Python. Languages where you have to explicitly
invoke a compiler and then run the executable, maybe you run into the
problem "at the beginning" (shades of Chapter 1 of _The C Programming
Language_!), but not with Python. Where my students run into problems
is when they *know* it was all worth it, because *now* they're ready
to use Python to do whatever it is they style "real work" -- and need
to install, maybe configure, and learn to use something that isn't an
included battery. Even in a well-curated framework like Anaconda,
"you can make a bottle adult-proof, but not child-proof".
So *my* point (I don't speak for anyone else) is pessimistic. I don't
think there's a one-size-fits-all solution to child-proofness. What
we need is children with better vocabularies.
>From my point of view, what I want is to talk to students (and
colleagues!) about problems that I can often solve or install a
workaround in a few minutes. But when simple questions like "what
distribution did you install?" gets the answer "I just downloaded the
package. What's a distribution?", and the followup is, "well, where
did you get it?", "I clicked on the top link in Google", which leads
to "well, is it this one?" and "I can't tell...", it's very
frustrating for all concerned -- and we haven't even started on the
new package that isn't working.
When to them, it's pure fsckin' magic, and to me, it's muscle memory,
problem-solving across the gap is hard. For my purpose, cross-
platform distributions like Anaconda seem to be the best solution
available now and for the near future. But for many developers, they
have enough problems without dealing with the idea that some other
application has different version or configuration requirements for
some components.
I just don't see a world where any of the points of view are without
merit. People with more space than apps can put them *all* in venvs,
people with relatively simple "external" requirements can just use a
single installation, and people with the necessary skills can mostly
use the single installation and put a few "problem children" into
venvs of their own. Each of those groups will want Python itself to
take a different approach to the "problem".
So the question in the subject is valid and should be raised once in a
while, but the answer is always going to disappoint a majority. :-)
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/COTOLXA4I76KMBPFQ2J5RQWNKKYCPRGE/
Code of Conduct: http://python.org/psf/codeofconduct/
