Nick Thieberger has a nice comic[1] which I think captures my sentiment about this.

I think techies like us severely underestimate how much of a turnoff it can be to begin someone's computer programming experience by making them schlep through an arduous installation and configuration process. You can promise them "really, we'll just get this right once, and it'll all be over", but that doesn't change the fact that this is their first encounter with programming, and that it will therefore have an incredibly disproportionate impact on how they conceive of the task and experience of programming.

On a first date, would you interrogate your date about their likes and dislikes, childhood trauma, and insecurities? It's probably not entirely wrong to claim that this would pay off in the long term, but there is a good chance that this would strike the wrong tone and prevent a second date.

A coarse metaphor perhaps, but there are some parallels. Imagine hearing someone tell you "You, too, can be a digital magician, and bend computers to your will", and then spending 1 hour bashing your head your keyboard trying to figure out how this Anaconda thing works (I thought I was using Python? What's Anaconda? Is it like Python but different?). If I were in that position again, I think I'd begin to wonder whether this is what programming is always like, and probably wonder if I want to do this after all.

Certainly, as we all know, programming does always involve a great deal of resilience in the face of unsexy unfamiliarity, but there are transcendental moments when you look at what you just brought into the terminal and marvel at how this ever came to be possible, and I think trying to give a taste of that to people in a first encounter with programming with a minimum of pain leading up to it is the best way to make them so excited about programming they'll be willing to continue learning, and yes, set up an IDE and Python installation.

[1]: http://www.nthieberger.net/phantom.jpg

I'm a high school computer science teacher (who has also taught middle and elementary school students) and would like to absolutely echo this.

As folks who are fairly proficient in programming, our scales for what constitutes as a "difficult task" can be wildly different from beginners to the field. They haven't built the knowledge, experience and mental representations to accurately determine whether something is hard or easy (case in point: my 9th graders will often propose final projects that would take a group of seasoned engineers months to complete).

After CS classes in college and working in the field, I kinda forgot about the initial setup barriers that I first encountered (and was much more patient to battle through); but after just teaching a single class of middle school students (a) not knowing how to properly install software and (b) as a result, getting into the state of "This is boring ... so I'm going to entertain myself by socializing, distracting my friends, or goofing around" I quickly realized how important it was for these kids' first experience with programming to be painless ... otherwise they would also make my life as a teacher a difficult one.

There's definitely a lot of benefit to ensuring that students are able to set up their own environment, but also a non-zero risk that front-loading this would put them off / distract them. Also, for short courses particularly, there's a danger that a significant proportion of time (especially for the instructor) is spent futzing around trying to fix broken environments.

In my mind, something like repl.it would be ideal for getting through enough material such that the course participants were motivated and knowledgable enough to setup their own environments at a later stage in the course.

It's not a distraction. Sadly it's a big part of Python development. :(

It's a distraction when you're learning. And even now, I do Python all the time and setting up any sort of environment is something I do _very_ infrequently.

For absolute beginners, I'd even prefer something like this:

1. Hit install on Python and accept the defaults.

2. Install a simple text editor with syntax highlighting.

3. Open a file right on your desktop and type two commands in it and press F5 or something to run it.

Anaconda and Jupyter are great tools, but even they add complexity you don't need when teaching absolute beginners how accessible this can be.

Here's Python. It's installed. Tell the computer what you want to do inside a file. You understand text files and how to store them where you want, use your own conventions for that. Shove it in documents or whatever. We'll learn about project management and version control later, when you're writing programs more than 20 lines long.

This is how I use Python. I'm not very proficient in Python, but it's amazing how quickly I can build simple services with it, despite it being a language I only use occasionally.

There's so much stuff included in the basic installation from python.org. And it all just works.

The only thing missing from the basic installation is psycopg2 for talking with PostgreSQL.

Yes, that might be what I would do if I did the workshop again. I still like Repl.it because I think the distinction between the REPL and the file/editor is much easier to grasp there than with IDLE and IDLE's REPL, but running code locally is necessarily going to be more reliable than running code on a remote platform.

Repl.it is a pretty neat solution too, don't get me wrong.

And IDLE has always left me unimpressed relative to the terminal... but using Unicode on Windows, suddenly code pages get involved, which no one should ever have to know. There is a long series of subtle, unpleasant tradeoffs.

Writing short Python scripts when I traveled with a Chromebook was messy, I leaned on repl.it as one option... It was super easy to dive in.